📘TIL - PlayerController, 유닛 서브시스템 UI와 연동

문제

이전 단계에서는

Selection → CommandContext → UI 표시

까지는 정상적으로 동작하는 상태였다.

하지만 실제 게임 로직까지 연결하려는 순간 문제가 발생했다.

UI에서 발생한 명령이 실제 유닛 동작으로 이어지지 않음

대표적으로 드러난 증상:

우클릭 시 유닛이 회전만 하고 이동하지 않음

즉 문제는 단순 UI가 아니라

UI → PlayerController → Mass → StateTree → Movement

이 전체 흐름 어딘가에서 끊기고 있었다.

---

구조적 문제

구분	문제
명령 전달	전달은 되는 것처럼 보이나 실제 동작으로 이어지지 않음
StateTree	상태가 유지되지 않고 계속 재진입
Movement	PathFollow가 즉시 종료됨
Command 구조	상태 기반으로 설계되어 재진입 루프 발생
Subsystem	UI와 직접 연결되어 있었던 구조
UI 데이터	클라이언트에서 신뢰할 수 없는 경로로 접근

---

기존 구조

문제 발생 당시 흐름은 다음과 같았다.

우클릭
→ PlayerController
→ Command Fragment 설정
→ StateTree 진입
→ MoveToLocation
→ NavMesh PathFollow

겉보기에는 정상 구조지만 실제 동작은

Enter → Tick → Exit → Enter 반복

즉

상태 유지 실패 + 이동 즉시 종료

였다.

---

분석

핵심은 두 가지였다.

1. 명령 전달은 정상
2. 상태 유지와 이동 실행이 문제

로그 기준으로 확인된 사실:

TargetLocation 정상 전달

즉

PlayerController → StateTree 진입까지는 정상

문제는 이후였다.

---

원인 1. StateTree 상태 재진입 구조

현재 조건:

CurrentCommand == MoveToLocation

이 구조의 문제:

값이 유지되는 동안 조건이 계속 true
→ 상태 계속 재진입

결과:

Move 상태가 매 프레임 초기화됨

---

원인 2. Command를 상태로 사용한 설계

기존:

CommandType = Move

문제:

상태값이라서 계속 유지됨
→ 이벤트가 아니라 "지속 조건"이 됨

---

원인 3. PathFollow 즉시 종료

확인된 가능성:

EndDistanceThreshold가 큼
→ 목표 도달로 즉시 판정

즉

이동 시작 → 바로 완료 → 상태 종료 → 재진입

---

핵심 해결 방향

오늘 정리된 가장 중요한 개념:

Command는 상태가 아니라 이벤트다

즉 구조는 이렇게 바뀌어야 한다.

CommandType (무엇을 할지)
+
CommandIssued (이번 프레임에 발생했는지)

그리고

EnterState 시점에 Command 소비

---

PlayerController 역할 재정리

기존:

명령 해석 + 실행까지 담당

변경:

명령 "라우팅" 역할만 담당

입력
→ PlayerController
→ CommandId 전달
→ 실제 처리 대상(유닛/건물)로 전달

즉 Controller는

"의미를 아는 주체" → "전달자"

로 역할이 축소된다.

---

Subsystem ↔ UI 구조 문제

기존 구조:

UI → UnitSubsystem 직접 접근

문제:

Subsystem은 replication 안됨
→ 클라이언트 UI에서 신뢰 불가

---

해결 구조

핵심 전환:

UI는 PlayerState만 본다

전체 흐름:

[Server]

UnitSubsystem
→ 유닛 상태 관리
→ 집계값 계산
→ PlayerState 업데이트

-------------------------

[Replication]

PlayerState → 클라이언트 전달

-------------------------

[Client]

PlayerState OnRep
→ Delegate

UIBridge
→ ViewModel 갱신

HUDCoordinator
→ UI 반영

---

핵심 설계 포인트

1. 유닛 목록은 복제하지 않는다

❌ 전체 유닛 리스트 replication
✔ 집계값만 replication

---

2. PlayerState는 UI 전용 계층

데이터 저장 + replication + 이벤트 발생

예:

OnRep_CurrentPopulation()
→ Delegate Broadcast

---

3. Subsystem은 서버 로직 전용

UI를 모름
→ PlayerState만 갱신

---

4. UI는 계산하지 않는다

UI는 표현만 담당
데이터는 PlayerState에서 제공

---

전체 흐름 정리

입력 발생
→ PlayerController (라우팅)
→ Command Fragment 설정

StateTree
→ Move 상태 진입
→ 이동 수행

(문제)
→ PathFollow 즉시 종료
→ 상태 Exit
→ 조건으로 재진입

(해결 방향)
→ Command 이벤트화
→ 상태 소비 구조

---

유닛 상태 변화
→ UnitSubsystem

→ PlayerState 집계값 갱신
→ Replication

→ Client PlayerState OnRep
→ UIBridge

→ HUDCoordinator
→ UI 반영

---

Before / After

항목	이전	이후
Command 구조	상태 기반	이벤트 기반
StateTree	반복 진입	단발 소비 구조
PlayerController	해석 + 실행	라우터
UI 데이터	Subsystem 직접 접근	PlayerState 기반
네트워크 안정성	낮음	안정
디버깅	불명확	단계별 분리

---

오늘의 정리

1. UI 연결 이후 문제는 “명령 전달”이 아니라 “실행 구조”였다
2. StateTree는 조건 기반 설계 시 쉽게 무한 재진입이 발생한다
3. Command는 반드시 이벤트로 소비되어야 한다
4. Subsystem은 서버 전용, UI는 PlayerState 기반으로 분리해야 한다