1. 만족한 점
노드 간 유기적인 연결
상태 업데이트(FSM 구조)를 기반으로 행동들이 유기적으로 연결되어 자연스러운 흐름을 보여줬다. 예를 들어, 캐릭터가 Stunned 상태에 진입하면 자동으로 Grab을 해제하거나, Idle 상태에서만 특정 입력을 받도록 제한하여, 불필요한 상태 전이와 입력 처리를 줄일 수 있었다. Service 노드와 Task 노드를 명확히 분리함으로써 각 로직의 역할이 명확해졌고, 관리도 쉬워졌다.
블랙보드 및 상태 연동 구조
Blackboard를 통해 AILevel, TargetActor, 위험 회피 위치 등 주요 데이터를 공유하며, Service와 Task 간의 의사소통이 원활하게 이루어졌다. DFAIController에서는 BeginPlay 시점에 AILevel을 설정하여 일관된 AI 동작을 유도했다. 각 Task 노드에서 Blackboard 값만으로 판단이 가능하도록 구조를 잡아 확장성과 유지보수성을 확보했다.자연스러운 동작 흐름
상태(State)에 따라 가능한 행동을 제한함으로써, 비정상적인 상황을 미연에 방지하고 게임의 리얼리즘을 높였다. 예를 들어 Recover 상태에서는 공격/이동 입력을 무시하도록 하여 시각적·논리적 충돌을 피했다. 또한 물리 애니메이션과 상태가 연동되어 있어서 캐릭터의 피격, 회복 등의 행동이 매끄럽게 이어졌다.
2. 불편했던 점
과도한 Tick 사용
Tick 기반 구조가 많아지면서 프레임당 처리량이 과도하게 늘어나는 문제가 발생했다. 특히 캐릭터 클래스, Service 노드 등에서의 Tick 사용은 전체 퍼포먼스를 떨어뜨리고, 디버깅 시에도 언제 어떤 값이 바뀌었는지 추적이 어려웠다.
전환의 부자연스러움
RInterpTo로 회전 속도를 고정값(5.0f)으로 처리하다 보니, 상황에 따라 회전이 너무 빠르거나 느리게 느껴지는 문제가 있었다. 결과적으로 AI의 이동 방향 전환이 부자연스럽게 보일 때가 있었다.
블랙보드 값 초기화 타이밍 이슈
Service에서 값을 세팅하기 전에 Task에서 조건을 검사하면서 Task가 실행되지 않거나 실패하는 경우가 있었다. 특히 GrabTargetActor와 같은 Key 값이 제대로 설정되기 전에 Grab Task가 실행되어 조건을 통과하지 못하는 문제가 발생했다.
3. 해결 방안 및 개선 방향
캐싱 구조 도입
Tick을 사용하지 않고 BeginPlay 또는 OnPossess 시점에서 필요한 Actor, Component 등을 미리 캐싱하도록 구조를 변경
예: CachedPawn, CachedBlackboard, CachedCharacter 등
DFAIController 내부의 BeginAI에서 캐싱 처리 및 블랙보드 초기값 설정으로 통합
서비스 / Task 간 역할 명확화
Service는 항상 값을 평가하고, Task는 실행만 하도록 분리
예: Service에서 GrabTargetActor, bCanGrab, IsInAttackRange 등을 설정하고, Task는 블랙보드 조건만 검사하여 실행 여부 결정
이렇게 하면 순서 보장이 쉬워지고, 디버깅 시 로직 분리가 명확해진다타이머 기반 반복 처리로 전환
Tick을 사용하지 않고 FTimerHandle 기반의 반복 처리 구조로 리팩토링
예: 공격 반복(Punch 6회), 공격 쿨타임, 스턴 회복 타이머 등
예측 가능한 처리 흐름을 제공하며, 서버/클라이언트 간 동기화도 쉽게 유지할 수 있다BeginPlay 최적화
캐릭터(DFCharacter)와 AIController(DFAIController) 모두 BeginPlay 시점에 필요한 참조 캐싱 및 초기화 수행
상태(StateManager), 애니메이션 설정, AbilityManager 초기화 등 한 번만 처리되도록 구조 개선
4. 난이도 기반 분기 구조에 대한 적용
AI 난이도는 Rookie / Basic / Expert 세 단계로 나누어져 있으며, DFAIController에서 BeginPlay 시점에 CurrentAILevel을 블랙보드에 설정한다. 이후 각 노드에서는 GetAILevel() 함수를 통해 현재 AI의 난이도를 가져와 분기처리하게 되어 있다.
이 구조는 단일 BT로 난이도별 행동 분기까지 가능하게 해주며, 난이도에 따른 기능 제한이나 공격 빈도 조절이 용이하다.
마무리
Tick 기반 구조는 프로토타이핑이나 빠른 테스트에는 유리하지만, 유지보수와 최적화에는 적합하지 않다. 실제 운영 가능한 구조로 전환하려면 캐싱과 타이머 기반 처리 방식으로의 리팩토링이 필수적이다. 다음 단계에서는 현재의 구조를 기반으로 하여 더욱 세분화된 행동 트리 구성과 난이도별 AI 전략 확장을 진행할 예정이다.
