https://youtu.be/U8CkmOJg93M?si=1Oxo20TWFPYnyXOe
영상(Unreal Fest Gold Coast 2024의 "Exploring the New State Tree for AI")은 오히려 "복잡하고 깊은 사고를 하는 단일 개체 AI(예: 보스 몬스터, 전술 FPS AI)"에 StateTree가 얼마나 강력한지를 역설하고 있습니다.
영상의 핵심 내용과 기존 Behavior Tree(BT)와의 차이점을 우리 프로젝트에 대입해서 분석해 드리겠습니다.
1. Behavior Tree(BT)의 치명적인 단점 (영상 분석)
영상에서 발표자(Amus 게임 개발자)는 다수의 FPS/RTS 하이브리드 AI를 만들며 겪은 BT의 한계를 명확히 지적합니다.
상태(State) 관리의 끔찍함: BT는 본질적으로 '상태 머신'이 아닙니다. 하지만 실제 게임 AI는 '대기 상태', '교전 상태', '엄폐 상태' 등 명확한 상태를 가지게 되는데, 이를 BT 억지로 구현하려다 보니 트리가 기형적으로 거대해지고 꼬인다는 것입니다.
전환(Transition) 로직의 한계: BT에서는 Decorator(조건문)가 언제든 로직을 끊어버릴 수 있어서, "A 임무를 실패하면 B를 해라" 같은 명확한 후속 조치를 짜기가 매우 까다롭습니다.
블랙보드(Blackboard) 데이터 세팅의 피로도: BT는 데이터를 가져오고 설정할 때마다 Getter/Setter 노드를 주렁주렁 달아야 해서 작업이 번거롭습니다.
2. StateTree가 소수 정예 AI에게도 좋은 이유
MassEntity가 아니더라도 StateTree를 써야 하는 강력한 이유들이 소개되었습니다.
계층형 상태 머신 (Hierarchical State Machine): FSM(유한 상태 머신)의 직관성과 BT의 실행 능력을 합쳤습니다. 상태 안에 또 다른 하위 상태(Child State)를 둘 수 있어, 트리가 훨씬 깔끔하고 가독성이 뛰어납니다.
어디에나 붙일 수 있는 유연성: BT는 오직 'AI Controller'에만 종속되지만, StateTree는 일반 Actor, 무기, 포탑, 심지어 UI 위젯에도 달 수 있습니다. (영상에서는 거점 점령 시 작동하는 포탑에 StateTree를 달았습니다.)
혁신적인 데이터 바인딩 (Data Binding): 블루프린트 UI 변수를 연결하듯, Input/Output 변수를 드래그해서 직관적으로 묶어버릴 수 있어 블랙보드 스파게티를 방지합니다.
게임플레이 이벤트 (Gameplay Tags) 연동: "체력이 20% 이하로 떨어짐" 같은 이벤트를 Gameplay Tag로 쏘면, StateTree가 이를 감지하고 즉시 '기어가는 상태(Crawling State)'로 전환하는 등 이벤트 드리븐(Event-driven) 로직이 매우 강력합니다.
기존에 구상하신 훌륭한 레벨 디자인 기조를 그대로 유지하셔도 됩니다. 그 이유와, StateTree로 넘어갔을 때 실무적으로 '무엇이 그대로이고, 무엇이 달라지는지' 명확히 짚어드릴게요.
1. 왜 안 바뀌나요? (역할의 완벽한 분리)
AI 시스템을 인체의 장기에 비유하자면 역할이 완전히 다릅니다.
EQS (환경 쿼리 시스템): AI의 '눈과 계산기'입니다. "지금 내 주변 반경 20m 내에 가장 안전한 엄폐물 노드가 어디지?"를 수학적으로 계산해 좌표를 뱉어냅니다.
전술 노드 (Tactical Nodes): AI가 읽을 '지도 데이터'입니다. 레벨 디자이너가 맵에 깔아둔 장기말과 같죠.
StateTree (상태 트리): AI의 '뇌(의사결정)'입니다. EQS가 계산해준 좌표로 "지금 뛰어갈지, 나중에 갈지, 멈출지"를 결정합니다.
즉, 뇌(BT → StateTree)를 더 똑똑하고 최신형으로 교체할 뿐, 눈(EQS)과 지도(전술 노드)는 기존 방식을 그대로 사용하는 것이 언리얼 엔진의 정석입니다.
2. 구체적으로 무엇이 그대로 유지되나요?
레벨 디자이너의 작업 방식: 맵 구석구석에
Cover,Peek,Transit등의 태그가 달린 투명한 웨이포인트 액터를 수작업으로 배치하는 작업은 그대로 진행합니다.EQS의 평가 기준 (Scoring): 목적지와의 거리, 적 시야로부터의 은폐 여부 등을 채점하여 0~1점 사이의 가중치를 매기는 로직도 100% 동일하게 사용합니다.
3. StateTree로 변형 시, 실무 구현은 어떻게 달라지나요?
가장 크게 체감되는 것은 프로그래머와 기획자가 로직을 연결할 때의 '쾌적함(데이터 바인딩)'입니다.
변경 전 (BT 방식): BT의 Task 노드에서 EQS를 실행합니다. → 결과물(가장 점수가 높은 전술 노드 액터)을 Blackboard의
TargetNode라는 변수에 우겨넣습니다. → 이동 Task가 Blackboard에서 그 값을 다시 꺼내와서 이동합니다. (변수 셋팅이 매우 번거로움)변경 후 (StateTree 방식): StateTree의 특정 상태(예:
Phase 3: 진입) 안에 진입하면, 곧바로 StateTree Task로 EQS를 실행합니다. 그리고 영상에서 보셨던 '데이터 바인딩(Data Binding)' 기능을 통해 EQS 결과값을 곧바로 이동 Task의 '목표 지점' 핀에 선 긋듯이 묶어버립니다. 블랙보드를 거치는 스파게티 로직이 완전히 사라집니다.
https://youtu.be/XKQfMZOXFv0?si=tui9THFXGDTCViu4
'StateTree와 Behavior Tree(BT)를 어떻게 혼합(Hybrid)하여 사용하는가'에 대한 아주 훌륭한 실무 레퍼런스입니다! AAA 게임(Lords of the Fallen)에서 복잡한 전투 AI를 다루기 위해 두 시스템을 어떻게 엮었는지 명확하게 보여주고 있습니다.
분석 결과, "BT와 StateTree를 같이 쓰는 것이 맞습니다." 영상을 바탕으로 우리 프로젝트에 적용할 수 있는 핵심 하이브리드 아키텍처를 요약해 드리겠습니다.
1. 왜 두 개를 같이 써야 할까? (영상의 핵심 교훈)
영상에서 발표자는 BT 하나만으로 모든 것을 처리하려다(Master Enemy Tree) 거대한 스파게티 트리가 되어 관리가 불가능해졌다고 고백합니다.
그래서 역할 분담을 했습니다.
StateTree의 역할 (거시적 판단 & 반응): AI의 현재 '핵심 상태(Idle, Combat 등)'를 결정하고, '갑작스러운 외부 반응(회피, 패리, 유저 개입 등)'을 감지하여 실행 흐름을 통제하는 '관리자' 역할을 합니다.
Behavior Tree의 역할 (미시적 행동 패턴): 'A사이트로 이동하며 경계하기', '연막탄 던지고 진입하기'와 같은 '구체적이고 일련의 행동 시퀀스'를 실행하는 '실무자' 역할을 합니다.
2. 우리 매니징 게임에 적용할 하이브리드 구조 제안
영상의 구조를 우리의 발로란트 룰 기반 FPS 매니징 게임에 대입하면 아주 깔끔한 설계가 나옵니다.
A. StateTree (최상위 제어기)
AI가 어떤 '페이즈(Phase)'에 있는지 결정하고, 유저의 실시간 개입을 감지합니다.
상태 1:
Prep(준비) -> BT_Prep 실행상태 2:
Default(탐색) -> BT_Explore 실행상태 3:
Execute(진입) -> BT_Execute 실행상태 4:
RunReaction(유저 지시/특수 반응) -> 영상에 나온 핵심 구조입니다. 유저가 '연막 투척'이나 '강제 후퇴' 카드를 쓰면, StateTree가 즉각 이를 감지하여 현재 진행 중인 BT를 중단시키고, 유저가 지시한 행동(Reaction)용 BT를 덮어씌워 실행합니다.
B. Behavior Tree (하위 행동 시퀀스)
StateTree가 "이제 진입(Execute)해!"라고 명령하며 BT_Execute를 실행하면, BT는 다음과 같은 디테일한 로직을 수행합니다.
Task: EQS를 돌려 가장 안전한 웨이포인트(전술 노드) 찾기.
Task: 해당 웨이포인트로 이동 (이동 중 에임 유지).
Decorator: 이동 중 적 발견 시 이동 멈추고 사격.
3. 기술적 주의사항 (메모리 복원 로직)
영상 후반부에 아주 중요한 기술적 팁이 나옵니다. StateTree가 유저의 개입(RunReaction)을 처리하기 위해 기존에 돌던 BT(예: 탐색 BT)를 멈췄다가 다시 켤 때, "기존에 돌던 BT의 메모리(지금 어디까지 탐색했고, 어느 지점을 가려고 했는지)가 날아가는 문제"가 발생합니다. 발표자는 C++를 통해 BT가 정지될 때(Stop) 메모리를 백업하고, 다시 실행될 때(PushInstance) 복원하는 커스텀 로직을 짰다고 합니다. 우리도 유저 개입 후 AI가 "내가 뭐 하던 중이었지?"라며 멍청해지는 현상을 막으려면 이 '메모리 백업 로직'을 반드시 구현해야 합니다.
1. 언리얼 AI 기술 1:1 매핑 비교 (BT ➡️ ST)
가장 핵심적인 변화는 '데이터를 다루는 방식(Blackboard)'과 '흐름을 끊는 방식(Decorator)'이 완전히 현대적으로 개편되었다는 점입니다.
2. 기술 패러다임 변화의 핵심 요약
단순히 이름만 바뀐 것이 아니라, 시스템이 돌아가는 '사고방식'이 진화했습니다.
⛔ Blackboard 안녕, 🟢 Data Binding 환영
BT (과거): 유저가 지정한 목표 좌표를 AI에게 주려면,
Set Blackboard Value as Vector노드를 써서 Blackboard에 억지로 구겨 넣고, BT Task에서 다시Get Blackboard Value로 꺼내 써야 했습니다. 변수 이름에 오타가 나면 버그 잡기가 지옥이었습니다.ST (현재): UI 위젯에서 변수 바인딩하듯, EQS의 결과물 핀을 이동 Task의 목표 핀에 직접 '드래그 앤 드롭'으로 연결(Binding)합니다. 직관적이고 스파게티 로직이 안 생깁니다.
⛔ 예측 불가 Abort 안녕, 🟢 명시적 Transition 환영
BT (과거): Decorator의
Observer Aborts (Both)설정은 강력하지만, 트리가 복잡해지면 "대체 어디서 이 행동을 끊어먹은 거야?" 하고 추적하기가 매우 까다로웠습니다.ST (현재): 각 상태(State)마다
On State Succeeded,On State Failed,On Event등 어떤 조건에서 다음 상태로 넘어갈지(Transition)를 우측 패널에 명시적으로 적어둡니다. 흐름이 눈에 확 들어옵니다.
3. 변하지 않는 기술 (유지되는 에셋)
엔진의 뇌(BT/ST)만 교체될 뿐, AI의 눈과 다리 역할을 하는 기술들은 100% 동일하게 재사용됩니다. ST를 배우더라도 이 기술들은 어차피 새로 짜야 하니 매몰 비용이 발생하지 않습니다.
EQS (Environment Query System): 웨이포인트(전술 노드) 가중치 평가
AIPerception: 적 시야 스팟, 발소리 청각 감지
NavMesh / Pathfinding: 물리적인 지형 이동 경로 탐색
Gameplay Ability System (GAS): (사용하신다면) 캐릭터의 스킬 발동 체계
정리하자면, ST의 학습은 '완전히 새로운 언어'를 배우는 것이 아니라, 'BT의 불편했던 UI/UX를 개선한 최신 버전 툴'의 사용법을 익히는 것에 가깝습니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.