How to create Modular and Scalable UI systems in Unreal Engine

[ 모듈화 및 확장성 ]

1. Iterate on UI Design Faster – UI 디자인을 더 빠르게 반복하기

💡 Base Reusable Widgets(재사용 가능한 위젯) 생성하기

공통적으로 쓰이는 위젯 생성

WBP_BaseBorder / WBP_BaseButton / WBP_BasePanel / WBP_BaseText 등

Instance Editable, Pre-Construct 연동

• Instance Editable : 에디터에서 개별 객체마다 변수 값을 다르게 설정할 수 있는 옵션
• Pre Construct에서 “초기 비주얼 상태”를 인스턴스별 파라미터로 세팅
  • 디자인 타임: 위젯 뷰포트 미리보기·디테일 변경 시 여러 번 호출됨
    → 에디터에서 실제처럼 미리보는 용도
  • 런타임: 위젯 생성 직후, Construct 전에 1회 호출
    → 애니메이션/레이아웃 초기값 세팅
    

⇒ 전체 프로젝트 색상 변경 등을 단일 클릭으로 처리 가능

2. Avoid Duplicating Widgets – 위젯 중복 생성을 피하는 방법

💡템플릿화를 위한 Named Slots 사용하기

Named Slot

• 부모 위젯이 자식 위젯이 들어올 자리를 이름으로 지정해주는 구조 → 이 위젯의 특정 위치에 나중에 다른 위젯을 꽂을 수 있게 하는 슬롯
  → 템플릿 위젯에 “이 부분은 나중에 다른 콘텐츠로 교체할 자리” 표시
  
• 부모 위젯 (공통 레이아웃, 카드, 버튼 등 재사용 위젯)에서 사용

NameSlot vs UserWidget 상속 차이

비교 항목	Named Slot	상속
구조	슬롯으로 채워넣기	부모 자식 클래스 관계
목적	UI 조립/조합	기능 확장
런타임 변경	가능 (SetContent 등)	불가능 (클래스 변경 필요)
재사용성	높음	낮음
코드 영향	거의 없음	부모 함수 구조 영향 받음

런타임 중에 슬롯 안의 내용 바꾸고 싶으면?

MyNamedSlot->SetContent(MyWidgetInstance);

또는

BP에서 `Set Content` 노드 사용해 새로운 자식 위젯으로 교체 가능

3. Manage UI Panels and Popups – 패널과 팝업 관리

💡화면 및 패널 관리를 위한 다른 레이어 사용하기

→ 인벤토리 화면 나오고 퀘스트 화면 나타나게 하고 싶으면 위젯을 숨기고 나타나게 해야 함

Layer는 위젯의 스택, 위젯을 스택에 Pop / Push 가능

레이어 종류

• Game Layer : HUD, 항상 보이는 위젯
• Game Menu Layer : 인벤토리, 퀘스트 등 게임 플레이 메뉴
• Menu Layer : 일시중지, 설정 등 게임 플레이와 무관한 메뉴
• Modal Layer : 팝업, 대화 상자

UI Manager가 레이어를 캡슐화하고 기능 노출

Monolithic (단일형) 마스터 위젯 방지, 위젯 간 상호 참조 제거

• 위젯이 서로 알지 못해도 위젯을 생성 / 제거 가능
• 새 레이어를 추가해도 아무런 영향이 없음
  
  

4. Decouple Gameplay and UI Communication – 게임로직과 UI 통신 분리

💡데이터를 별도의 Objects에 넣기 → 데이터 객체 분리 (View Models)

함수로 바인딩하면 간단하지만,

1. 매 프레임 마다 필요없어도 호출됨
2. 무기 컴포넌트를 조금씩 조정할 때 무기 컴포넌트에 계속 연결된다

UMG Viewmodel 플러그인

1. View Model 자식 클래스 생성 및 데이터 추가
2. 코드에서 변경 사항이 발생 → 데이터를 업데이트
3. UI는 뷰 모델의 변경 사항을 수신 → 위젯을 업데이트함

→ 코드를 변경하거나 UI를 변경해도 아무것도 손상되지 않음

[ UI 최적화 ]

5. Reduce UI Draw Calls – Draw Call 최소화하기

💡UI 무효화 하기

1. Function / Property Binding 대신 이벤트 사용하기
2. 매 프레임마다 변경되지 않는 위젯을 캐싱
   → 매 프레임마다 레이아웃을 다시 계산하는 대신 캐싱된 레이아웃을 사용

   (예) Health Bar는 매 프레임마다 변경되거나 다시 그려질 필요가 없음 
   
   → 플레이어가 피해를 입을 때만 업데이트

3. 캐싱하기 위해 Invalidation Box로 감싸기 → 위젯 속성이 변경될 때만 레이아웃을 캐싱하고 업데이트

→ 투명도·머티리얼·중첩 최소화로 렌더링 효율 개선

6. Best Way for UI Animations – 가장 효율적인 UI 애니메이션 방식

💡머티리얼을 사용한 애니메이션 사용하기

호버 시 애니메이션이 필요

→ 일반적으로 시퀀서를 통해 애니메이션 만듦

→ 매우 제한적이고 CPU에서 실행됨

Sequencer 대신 Material Instances 사용

1. GPU에서 실행 → 복잡한 계산 처리
2. 고급 애니메이션 가능 (위젯이나 텍스쳐 추가하지 않아도 애니메이션 반복(loop), 파티클, 글로우)
3. Invalidation Box의 레이아웃 무효화 예외 적용
   1. 머티리얼 없이 애니메이션된 위젯 → 무효화 ⭕
   2. 머티리얼을 사용하여 애니메이션된 위젯 → 무효화 ❌
   
   

7. Create & Remove Widgets vs Hide & Show

– 생성/제거 vs 숨김/표시

💡구성(Construction) 단계에서 위젯들을 카테고리별로 나누기

→ 상황에 맞는 메모리 관리 전략 선택하기

• Create / Remove
• Hide / Show

1. 빠른 응답이 필요한 위젯 (인벤토리) : 백그라운드에서 로드된 상태 유지하지만 숨김 처리
2. 오래 표시되지 않고 빠른 응답 불필요 : 런타임에 동적으로 로드하고 해제할 때 제거
3. WidgetSwithcer로 여러 위젯(인벤토리, 퀘스트 등)을 하나의 위젯에 때려넣기
   
   
   

8. Collapsed vs Hidden – Collapsed와 Hidden의 차이

💡Hidden 대신 Collapsed 사용하기

→ 완전히 무시하는 유일한 옵션

Visibility 값	화면 표시	입력	레이아웃	설명
Hidden	안 보임	불가능	공간 차지	안 보이지만 자리 유지
Collapsed	안 보임	불가능	공간 제거	존재하지만 완전히 숨김 처리

**Hidden** → 눈에는 안 보이지만, 그 자리에 빈 공간이 남음 (투명 망토)
[ Button A ]
[          ] ← 공간 유지
[ Button C ]

**Collapsed** → 그 자리 자체가 사라짐 (C가 위로 붙음)
[ Button A ]
[ Button C ]

9. Not Hit Testable vs Visible – 히트테스트 비활성 vs 표시 상태

→ 클릭 감지·인터랙션 제어 구분하기

💡Visible 대신 Not Hit Testable 사용하기

Visibility 값	화면 표시	클릭	레이아웃	설명
Visible	보임	가능	포함	보이고 상호작용 가능
Not Hit Testable	보임	불가	포함	보이지만 입력 무시

서로 상호작용이 필요하지 않은 위젯에 Not Hit Testable 적용

Not Hit Testable

• Hit Test 계산을 생략해!
• 보이긴 하지만 클릭 감지 영역에 포함되지 않음 → 커서 감지/클릭 체크 연산이 완전히 생략됨 → 성능 이득 발생
  
• 장식용 UI, Text, Border, Icon, Overlay 등에 사용하면 좋음

히트 테스트 (Hit Test)

마우스 커서(터치)가 어떤 위젯 위에 있는가?

매 프레임마다 모든 Visible 위젯들의 사각 영역을 검사하고
어떤 위젯이 클릭/호버를 받아야 할지 Hit Test Grid라는 데이터 구조로 관리함

→ 버튼 같은 클릭이 필요한 위젯에만 필요

→ 장식용 이미지나 텍스트까지 전부 검사하면 불필요한 연산 낭비 생김

Visibility

Visibility 옵션	화면 표시	입력 감지	설명
Visible	보임	감지	클릭, 호버 등 상호작용 가능
Self Hit Test Invisible	보임	❌ 감지 (본인만)	자식 위젯은 입력 가능
Hit Test Invisible	보임	❌ 감지 (자기+자식)	전체 입력 무시
Hidden / Collapsed	❌ 안 보임	❌ 감지	렌더링 및 입력 둘 다 없음

10. Use Canvas Panels Sparingly – Canvas Panel을 아껴서 사용하기

💡Canvas Panel 및 Overlays 조금만 사용하기

Canvas Panel

• 사용하기 쉽고 원하는 방식으로 위젯 배치
• 절대 좌표로 배치하는 자유형 UI (HUD, Overlay, Layer)
• 위젯들을 겹치면 더 많은 Draw Call 사용

Grid Panel

• 자식 위젯마다 Anchors (앵커), Offsets (위치/크기) 값으로 위치를 지정

• UI 위치를 픽셀 단위로 정확히 제어할 수 있음

• 중첩 패널이나 Layer 관리에 자주 사용

• 버튼이나 HUD 아이콘 등을 좌표로 배치할 때 가장 유용

• 행과 열로 정돈된 구조형 UI (인벤토리, 설정, 목록)

• 그리드 셀 안에서 픽셀 단위로 위치를 살짝 조정해야할 때 Nudge 사용
  → 별도의 Draw Call 없이 랜더 트랜스폼만 적용됨
  → 성능 문제 없음

  

  항목	Canvas Panel	Grid Panel
  배치 방식	절대 위치 기반 (좌표 + 앵커)	행(row) / 열(column) 기반
  좌표 기준	Pixel 단위 (X, Y)	셀 단위 (Row, Column)
  크기 조정	수동 (Anchors, Offsets)	자동 (셀 크기에 따라)
  정렬 / 자동배치	없음 (직접 배치)	있음 (그리드 정렬 자동)
  주 용도	HUD, 절대위치 UI, 레이어 배치	표 형식 UI, 인벤토리, 설정 메뉴
  반응형 UI	직접 앵커 계산 필요	그리드 비율로 비교적 용이
  성능	매우 가볍고 단순	셀 계산이 약간 더 복잡
  Anchor 지원	있음	없음 (대신 자동정렬)

  
  

11. Space Widgets Efficiently – 위젯 공간 효율적으로 배치하기

💡Size Boxes 대신 Spacers 사용하기

Size Boxes

• 자식의 크기를 강제로 변경하거나 제한
• 부모 레이아웃 계산과 자식 위젯의 실제 크기 계산을 두 번 이상 수행해야 함
  • 부모 → 자식 → 부모 재계산
• 여러 Layout Pass가 발생 → CPU 비용 증가

Spacers

• 자식 없음
• 별도의 레이아웃 재계산 없음
• 랜더링(그리기)도 없음 → Draw Call 0
• 레이아웃 계산 중 가장 싸다 👍🏻
  
  

12. Avoid Hard References – 하드 레퍼런스 피하기

💡Soft References 사용하기

(예시) 캐릭터 선택 화면

캐릭터 10명

캐릭터
- 메시
- 텍스쳐
- 머티리얼
- 사운드
- 애니메이션
같은 리소스를 가지고 있음

• Hard Reference로 이 캐릭터들을 저장
  → 게임 시작 시 10명 전부 한꺼번에 메모리에 로드됨 (선택 안 해도)
  → 로딩 느려지고 메모리 낭비 발생

Soft References

• 리소스 자체를 들고 있지 않고 리소스의 경로(주소)만 기억함
• 그 객체가 필요할 때만 메모리에 불러오는 참조 방식
  
  

13. Custom Icon Fonts – 커스텀 아이콘 폰트 사용법

💡Texture 대신 폰트로 아이콘 관리하기

→ 메모리와 Draw Call 절약

일반적으로 UI 아이콘은 Texture 이미지로 만들어져 있어서 아이콘이 많아질수록

머티리얼 수 ↑ / Draw Call ↑ / GPU 메모리(텍스처 메모리) 낭비

아이콘을 폰트로 관리하자!

• 이미지 대신 폰트로 아이콘 표시

• FontForge / Fontello 툴 이용

  • 각 아이콘 이미지를 글리프(glyph)로 변환
  • 유니코드 값을 부여
  • 하나의 커스텀 폰트 파일(.ttf)로 묶기

• UI 위젯에 이미지 대신 텍스트 블록 추가해서 해당 아이콘의 유니코드 값 또는 글리프 문자 입력

• 문제점
  - 일부 블루프린트에서는 유니코드 값을 직접 입력할 때 인식되지 않음
  - 아이콘 글리프(문자 자체)를 복붙하면 괜찮음!
  

  항목	기존 방식 (이미지 아이콘)	폰트 방식 (아이콘 폰트)
  아이콘 수	200개 이상	200개 이상
  리소스 구조	PNG + 머티리얼 200개	단일 2048×2048 폰트 텍스처
  텍스처 메모리	매우 높음	훨씬 적음
  Draw Call 수	많음	적음
  유지보수	개별 이미지 관리 필요	폰트 하나로 관리

  
  

14. MeshWidget – 메시 기반 UI 위젯 사용법

→ 3D Mesh와 Slate 결합으로 고급 시각효과 구현

💡동일 다수 위젯 인스턴스에 MeshWidget 고려하기

적 체력바, 미니맵 아이콘, 월드 내 POI처럼 똑같은 UI가 엄청 많이 필요함

보통 Widget Component를 쓰는데 문제 있음

1. Slate(UI)를 먼저 CPU에서 그린 후
2. 그걸 Render Target 텍스처로 변환
3. 그 텍스처를 다시 3D 공간에 표시

위젯 하나하나마다 이 과정을 반복 → 엄청 무거움 (Draw Call ↑, CPU/GPU 비용 ↑)

Mesh Widget

여러 UI 인스턴스를 한 번에(=단일 Draw Call) 그릴 수 있는 방식 (UI용 Foliage System)

작동 방법

1. 기본 설정
   • Slate Vector Art Data를 통해 스태틱 메시 바인딩
   • 메시 위젯 안에서 Draw Mesh 기능과 Instance 활성화 기능 사용
2. 인스턴스 제어 방법
   • 각 인스턴스 (개별 UI)는 4D 벡터 하나로 제어됨
   • X, Y : 화면 위치, Z : 스케일, W : 기본 주소
3. 랜더링
   • UI Material을 만들어서 메시 위젯에 할당 (Slate Vector Art Data)
   • 이 머티리얼에서 위의 4D 벡터 값들을 받아 각 인스턴스의 위치, 크기, 색상, 표시 여부 등을 제어

일반 위젯 컴포넌트로 체력바 100개 그리면 100번의 랜더링이 필요하지만,

메시 위젯은 딱 한 번의 Draw Call로 100개를 다 그려버림