📘TIL-RTS 멀티플레이 UI 관련 공부 및 설계

문제

RTS 멀티플레이 프로젝트에서 UI를 전담하게 되면서 단순히 화면을 만드는 작업이 아니라
다음과 같은 구조적인 고민이 필요했다.

• UI는 어디까지 책임져야 하는가
• 서버 권한 구조에서 UI는 어떻게 동작해야 하는가
• 데이터 기반 구조를 어떻게 설계해야 하는가
• Command Panel, Selection UI, 단축키를 어떻게 연결해야 하는가
• 입력 딜레이를 UX적으로 어떻게 해결해야 하는가

특히 RTS는
선택 → 명령 → 상태 변화 → UI 갱신
이 흐름이 반복되기 때문에, 구조를 잘못 잡으면 유지보수가 매우 어려워진다.

---

분석

이번 정리에서 가장 중요하게 느낀 점은
UI를 단순한 “표현 계층”이 아니라 상태 표현 시스템으로 봐야 한다는 점이었다.

---

1. UI의 책임 범위

UI는 다음과 같은 역할을 수행한다.

구분	역할
입력	사용자 입력을 전달
표시	상태를 화면에 표현
반응	상태 변화에 따라 갱신

반대로 UI가 하면 안 되는 것은 다음과 같다.

금지 역할	이유
서버 데이터 수정	권한 문제 (Server Authority)
게임 로직 실행	책임 분리 위반
상태 원본 저장	동기화 깨짐

정리하면

UI는 상태를 바꾸지 않는다.
UI는 상태를 보여준다.

---

2. 멀티플레이 기준 데이터 흐름

멀티플레이 환경에서 UI는 항상 간접적으로 동작해야 한다.

[UI]
 → PlayerController
 → Server RPC
 → GameState / PlayerState
 → Replication
 → UI 갱신

이 구조에서 중요한 포인트는 다음과 같다.

• UI는 서버를 직접 호출하지 않는다
• PlayerController를 통해 요청을 전달한다
• 상태 변경은 서버에서만 일어난다
• UI는 복제된 결과를 기반으로 갱신된다

---

3. 데이터 구조 설계 (3계층)

RTS UI는 반드시 데이터 기반으로 설계해야 한다.
구조는 아래처럼 3계층으로 나누는 것이 가장 안정적이다.

구조 개요

Gameplay Data → UI Meta Data → ViewModel → UI

---

1) Gameplay Data (원본 데이터)

항목	설명
UnitId	유닛 식별
CommandId	명령 식별
Cost	실제 비용
Cooldown	실제 쿨다운
Condition	실행 조건

→ 게임의 실제 규칙이 담긴 데이터

---

2) UI Meta Data (표시 데이터)

항목	설명
Icon	아이콘
DisplayName	표시 이름
Tooltip	설명
SlotIndex	슬롯 위치
HotkeyLabel	단축키 표시

→ UI 표현을 위한 데이터

---

3) ViewModel (UI 전달 데이터)

항목	설명
SlotIndex	슬롯 위치
Icon	표시 아이콘
bEnabled	활성 여부
CooldownRatio	쿨다운 상태
bPending	예측 상태

→ UI에 실제로 전달되는 최종 데이터

---

4. Command Panel 설계

RTS UI의 핵심은 CommandId 기반 구조다.

흐름

입력(버튼/키)
 → CommandId 생성
 → 서버 요청
 → 상태 변경
 → UI 갱신

특징

• 버튼 클릭과 키 입력은 동일한 CommandId로 처리
• UI는 CommandId를 기반으로 표시만 수행
• 실행은 서버에서 담당

---

5. 단축키 처리 구조

단축키는 UI가 아니라 입력 시스템이 담당한다.

구조

Input System → CommandId → Server → UI 표시

역할 분리

영역	역할
Input	키 입력 감지
Command System	실행 처리
UI	단축키 표시

UI는 단순히

• 단축키 텍스트 표시
• 활성/비활성 상태 반영

만 수행한다.

---

6. Client Prediction (입력 지연 처리)

멀티플레이에서는 입력과 결과 사이에 지연이 발생한다.
이를 해결하기 위해 UI는 “예측 상태”를 먼저 보여준다.

상태 흐름

Predicted → Confirmed → Rejected

예시 (생산 버튼)

단계	UI 상태
클릭	임시 큐 추가
대기	Pending 상태
승인	확정 상태
실패	롤백 + 알림

---

상태 표현 정리

상태	의미	UI 표현
Predicted	입력 직후	즉시 반응
Pending	서버 대기	반투명/대기 표시
Confirmed	승인	정상 상태
Rejected	실패	롤백 + 경고

핵심은
“지연을 없애는 것이 아니라 지연을 느끼지 않게 만드는 것”이다.

---

7. Delegate 기반 UI 갱신

UI는 매 프레임 갱신이 아니라 이벤트 기반으로 갱신해야 한다.

이벤트 구조

OnResourceChanged
OnSelectionChanged
OnCommandChanged
OnNotification

비교

방식	특징
Tick 기반	비효율, 상태 꼬임
이벤트 기반	정확, 성능 안정

---

8. 공용 UI 구조

RTS UI는 유닛별 UI가 아니라 공용 패널 구조다.

구성

TopBar
SelectionPanel
CommandPanel
NotificationPanel
MinimapPanel

특징

• UI는 고정
• 데이터만 변경
• 재사용성 확보

---

9. 스켈레톤 프로젝트 전략

이번 작업에서 중요한 접근 방식은 다음과 같다.

단계

1. 에셋 없이 구조 구현
2. Mock 데이터로 테스트
3. 데이터 흐름 검증
4. 메인 프로젝트 이식

목적

• 구조 안정화
• 의존성 제거
• 빠른 반복 테스트

---

10. UI 구조 vs 스타일 분리

UI는 반드시 구조와 스타일을 분리해야 한다.

구조 레이어

• 위젯 구성
• 데이터 처리
• 상태 전환

스타일 레이어

• 배경
• 아이콘
• 색상
• 폰트

구조

UI Widget
 → ApplyStyle()
 → Style Data 주입

---

11. 미니맵 구조

미니맵은 UI가 직접 그리지 않는다.

구조

RenderTarget / Texture
 → UMG Image
 → Overlay (아이콘, 카메라)

역할 분리

담당	역할
미니맵 시스템	지도 생성
UI	표시 + 입력

---

12. 현업 개발 흐름

실제 개발 흐름은 다음과 같다.

전체 프로세스

기획 → 기능 정의
UI/클라 → 구조 설계
UI 개발 → 시스템 구현
디자인 → 비주얼 적용

역할 분리

역할	책임
기획	기능 정의
UI 개발	구조 설계 + 구현
클라	데이터 제공
UI 디자이너	시각 디자인

UI 개발자는 단순 구현자가 아니라
구조를 설계하는 역할에 가깝다.

---

오늘의 정리

RTS UI는 데이터 흐름, 상태 표현, 입력 연결을 담당하는 시스템이다.
UI는 서버 로직을 건드리지 않고
UI 메타 ID 기반으로 입력을 전달하며,
ViewModel을 통해 상태를 표현하고,
Client Prediction으로 입력 지연을 완화하는 구조로 설계할 필요가 있다.