본문 바로가기

내비게이션 시스템을 통한 기본 AI 이동

NavMesh Bounds Volume을 설정하고 AI Move To로 목표까지 경로를 탐색하며 이동 실패를 시각적으로 진단합니다.

비헤이비어 트리로 "플레이어를 쫓아간다"를 정하고 EQS로 숨을 위치까지 골랐는데, 막상 플레이해 보면 AI가 그 자리에 가만히 서 있을 때가 있습니다. 목표 위치를 아는 것과 그 위치까지 벽과 장애물을 피해 걸어가는 것은 다른 문제이기 때문입니다. AI가 어디를 걸을 수 있는지, 그리고 지금 위치에서 목표까지 어떤 길로 가야 하는지를 알려 주는 것이 언리얼 엔진의 내비게이션 시스템(Navigation System)입니다.

이 글에서는 내비게이션 시스템의 중심인 내비메시(NavMesh)가 무엇인지 살펴보고, 레벨에 내비메시를 만들어 크기와 이동 능력에 맞게 설정합니다. 그리고 비헤이비어 트리의 Move To 태스크로 AI를 이동시키고, 이동이 끝나거나 실패했을 때 트리가 무엇을 하는지, 움직이지 않는 AI의 원인을 어떻게 찾는지 정리합니다.


AI가 걸을 수 있는 바닥, 내비메시

내비게이션 시스템은 AI가 게임 세계에서 장애물을 피해 목표 지점까지 경로를 찾아 이동하도록 돕는 기능들의 묶음이며, 그 중심에는 내비메시(Navigation Mesh)가 있습니다. 언리얼 엔진은 레벨에 배치된 바닥, 벽, 오브젝트 같은 지오메트리를 분석해 AI가 걸어 다닐 수 있는 영역을 계산하고, 그 영역을 에디터에서 녹색으로 표시되는 메시로 만듭니다.

기본으로 쓰는 Recast 내비메시는 에이전트가 걸을 수 있는 표면을 폴리곤으로 나타냅니다. 하늘을 나는 AI가 쓸 3차원 공간 전체를 표현하는 체적 메시가 아니라는 점에 주의합니다. 이 글의 지상 경로 탐색은 내비메시를 쓰지만, 직접 이동이나 비행, 직접 만든 경로 탐색까지 모두 이 제약을 받는다는 뜻은 아닙니다.

내비메시가 있으면 AI가 복잡한 환경에서도 장애물을 피해 목표까지 효율적인 경로를 계산할 수 있습니다. 이동할 수 있는 영역을 미리 계산해 두므로, 실행 중에 매번 복잡한 지오메트리를 분석하지 않고도 빠르게 경로를 찾습니다. 높이와 경사의 제한을 설정할 수 있고, 떨어져 있는 두 바닥 사이는 내비게이션 링크(Navigation Link)와 그에 맞는 이동 동작을 구현해 연결할 수 있습니다. 다만 내비메시는 갈 수 있는 경로를 알려 줄 뿐이며, 벽에 부딪히지 않고 실제로 움직이려면 폰의 충돌과 Movement 설정도 함께 맞아야 합니다.


내비메시 만들고 설정하기

프로젝트에서 내비게이션 시스템이 켜져 있다면, 내비메시는 범위를 지정하는 볼륨을 놓는 것만으로 만들어집니다.

먼저 Edit > Project Settings에서 Engine 아래의 Navigation System 항목을 열어, 내비게이션 시스템과 필요한 Supported Agents 설정을 확인합니다. 에디터에서 내비게이션 데이터를 자동으로 다시 만드는 설정을 꺼 두었다면, 레벨을 바꾼 뒤 내비게이션 데이터를 따로 빌드해야 합니다.

다음으로 Place Actors 패널에서 NavMeshBoundsVolume을 찾아 레벨로 끌어다 놓습니다. 볼륨의 크기를 조절해 AI가 이동할 영역을 모두 감싸면, 그 안에서 내비메시가 계산되어 녹색으로 표시됩니다. 뷰포트에서 P 키를 누르면 내비메시 표시를 켜고 끌 수 있습니다.

에이전트의 크기와 이동 능력 맞추기

Bounds Volume은 내비메시를 만들 범위를 정할 뿐이고, 어떤 크기의 AI가 어떤 지형을 지날 수 있는지는 따로 설정합니다. 이 값들은 Project Settings의 Navigation Mesh와 Navigation System 항목, 그리고 레벨의 RecastNavMesh 액터 설정에서 확인합니다.

설정뜻
Agent RadiusAI 캐릭터에 필요한 수평 여유를 정하는 반지름
Agent HeightAI 캐릭터의 높이. 이보다 낮은 천장 아래는 내비메시에서 빠짐
Agent Max SlopeAI가 오를 수 있는 최대 경사각. 이보다 가파른 경사는 빠짐
Agent Max Step HeightAI가 오를 수 있는 최대 턱 높이. 이보다 높은 턱은 점프 같은 특별한 이동 없이는 지날 수 없는 것으로 봄

Agent Radius는 반지름이므로 통로의 전체 너비와 같은 값으로 읽지 않습니다. 실제로 지날 수 있는 영역은 에이전트의 크기뿐 아니라 내비메시를 만드는 해상도와 콜리전 설정에 따라서도 달라지므로, 좁은 통로가 끊겨 보이면 이 세 가지를 함께 확인합니다. 이 값들은 AI 캐릭터의 실제 크기와 이동 능력에 맞게 정하며, 설정을 바꾸면 내비메시가 다시 계산됩니다.


Move To로 AI 이동시키기

비헤이비어 트리에서 AI를 이동시키는 가장 기본적인 태스크는 Move To입니다. 이 태스크는 내비메시를 써서 목표 지점까지의 경로를 찾고, 그 경로를 따라 AI를 이동시킵니다.

BT_EnemyAI를 열고, 태스크를 놓을 위치(예: 시퀀스의 자식)에 Move To를 배치합니다. Move To를 선택해 디테일 패널에서 Blackboard Key를 지정하는데, 이 키는 AI가 이동할 목표를 담은 블랙보드 키여야 합니다. 특정 월드 좌표로 가려면 TargetLocation 같은 Vector 타입 키를, 플레이어 같은 액터에게 가려면 TargetActor 같은 Object 타입 키를 씁니다. 액터를 지정하면 AI는 그 액터의 위치로 이동합니다.

디테일 패널에서는 이동 방식도 조정할 수 있습니다. Acceptable Radius는 목표에 얼마나 가까이 가야 도착으로 볼지를 정하며, 이 반경 안에 들어오면 태스크가 성공합니다. Reach Test Includes Agent Radius와 Reach Test Includes Goal Radius는 이 도착 판정에 AI 자신과 목표의 반지름을 더할지를 정합니다. 블루프린트의 AI Move To 노드에 있는 Stop On Overlap도 이름과 달리 단순히 멈춤을 켜고 끄는 옵션이 아니라, 도착 판정에 반지름을 포함할지와 관련된 옵션입니다.

Allow Partial Path는 목표까지 완전한 경로를 찾지 못했을 때 갈 수 있는 데까지라도 이동할지를 정합니다. Observe Blackboard Value를 켜면 Blackboard Key의 값이 바뀔 때 이동을 새 목표로 다시 시작하므로, 서비스가 주기적으로 갱신하는 Vector 키로 움직이는 목표를 쫓을 때 씁니다. 목표가 TargetActor 같은 액터 키라면 플레이어가 움직여도 키의 값은 같은 액터로 남으므로, 이동 중에 그 액터의 현재 위치를 따라가게 하는 설정은 Track Moving Goal입니다. 설정을 마쳤으면 저장합니다.

플레이어 추적과 순찰 트리

다음은 Move To를 쓰는 간단한 트리입니다. 플레이어가 감지되면 쫓아가 공격하고, 아니면 무작위 지점을 순찰합니다.

Root
  |
  Selector (플레이어가 보이는가? -> 공격 / 아니면 순찰)
    |
    +--- Sequence (플레이어 추적 및 공격)
    |      |
    |      +--- Decorator: Blackboard Based Condition (플레이어가 보이는가?)
    |      |      (블랙보드 키: TargetActor, Key Query: Is Set)
    |      +--- Service: Update Player Location (커스텀 서비스, 현재 유효한 플레이어 Actor 참조를 TargetActor에 저장)
    |      |
    |      +--- Task: Move To (Blackboard Key: TargetActor, Acceptable Radius: 150)
    |      |      (도착 반경 150; Agent/Goal Radius 포함 설정도 함께 확인)
    |      +--- Task: Attack Player (커스텀 태스크)
    |
    +--- Sequence (순찰)
           |
           +--- Task: Find Random Location (커스텀 태스크, 블랙보드에 RandomLocation 저장)
           +--- Task: Move To (Blackboard Key: RandomLocation)
           +--- Task: Wait (5초 대기)

글자로 그린 트리라서 데코레이터와 서비스가 자식처럼 보이지만, 실제로는 실행 순서에 들어가는 자식 태스크가 아니라 추적 시퀀스 노드에 붙이는 요소입니다. 데코레이터의 Is Set 조건은 TargetActor에 참조가 들어 있는지만 확인할 뿐, 지금 플레이어가 보이는지를 보장하지는 않습니다. 실제 감지는 다음 글의 AI Perception과 연결하고, 진행 중인 행동을 바꿔야 한다면 데코레이터의 Observer Aborts를 설정합니다. 이 트리에서 Move To는 추적 가지에서는 TargetActor, 즉 플레이어에게, 순찰 가지에서는 RandomLocation으로 AI를 이동시킵니다.

이 예제에서 유효한 내비메시 경로가 없으면 Move To가 실패하므로 그 경우의 처리를 함께 만들어야 합니다. 도착 판정이나 부분 경로 허용, 직접 이동 같은 설정을 바꾸면 결과가 달라질 수 있다는 점도 기억해 둡니다.


이동 결과가 다음 행동을 정한다

Move To는 시간이 걸리는 태스크이므로, 요청한 순간과 결과가 나오는 순간 사이에 트리가 무엇을 하는지 알아 두어야 합니다.

이동 완료 결과가 다음 Task 실행을 결정합니다

이동 전제→Move To 진행 중 대기→성공 뒤 다음 Task 또는 실패 종료의 실제 Task 상태이다. 거리 150 cm 검사만으로 성공/피해 권한을 확정하지 않는다.

MOVE REQUEST · RUNNING · RESULT

이동 완료 결과가 다음 Task 실행을 결정합니다

두 결과는 대안 분기입니다. 진행 중인 Task가 성공·실패 두 경로를 모두 실행하는 것이 아닙니다. 별도의 Abort는 정상 완료와 구분합니다.

이동 Task의 완료 결과와 다음 행동이동 전제를 만족하고 Move To를 요청한 뒤에는 진행 중 결과를 기다린다. 성공하면 Sequence의 다음 Task를 실행하고 실패하면 같은 Sequence의 다음 Task를 실행하지 않는다. 성공이 피해 적용 허가를 뜻하지 않는다.이동 전제Controller · MovementNavMesh · 유효한 목표Move To · 진행 중완료 결과를 기다림다음 Task 아직 미실행성공다음 Task 실행공격 시점 조건은 다시 검사실패Sequence 실패같은 Sequence 공격 미실행
이동 Task의 완료 결과와 다음 행동이동 전제를 만족하고 Move To를 요청한 뒤에는 진행 중 결과를 기다린다. 성공하면 Sequence의 다음 Task를 실행하고 실패하면 같은 Sequence의 다음 Task를 실행하지 않는다. 성공이 피해 적용 허가를 뜻하지 않는다.이동 전제Controller · MovementNavMesh · 유효한 목표Move To · 진행 중완료 결과를 기다림다음 Task 아직 미실행성공다음 Task 실행공격 시점 조건은다시 검사실패Sequence 실패같은 Sequence공격 미실행

거리 조건과 실제 Task 완료는 별도로 확인합니다. 이동 성공 후 공격 대상·사거리·공격 가능 조건을 다시 검증합니다.

이 예의 조건

  • 본문과 원 도표에 제시된 사례의 입력·조건을 사용합니다. 설명용 수치나 독립 비교 경로는 각 단계에 표시합니다.
  • 현재 상태·값과 전환 근거의 위치는 모든 단계에서 같습니다. 조건이 맞지 않거나 실행되지 않은 경로를 성공한 동작으로 해석하지 않습니다.
예의 값과 변화
관찰·상황값·보충 정보변화·이유
이동 전제

Move To 요청에 필요한 상태를 확인한다.

  • 현재: 요청 전 검사
  • 거리 150 cm: 성공 자체 아님
  • 거리만으로 도착·피해 권한을 확정하지 않는다.
진행 대기

이동 Task가 Running 상태인 동안 결과를 기다린다.

  • Task: Running
  • 다음 Task: 미시작
  • 요청 시작과 이동 완료는 다른 이벤트다.
결과 분기

성공은 다음 Task, 실패는 해당 경로 종료다.

  • 성공: 다음 Task
  • 실패: 종료/정책
  • 실패한 이동을 공격 성공으로 연결하지 않는다.

이동 완료 결과가 다음 Task 실행을 결정합니다

이동 전제→Move To 진행 중 대기→성공 뒤 다음 Task 또는 실패 종료의 실제 Task 상태이다. 거리 150 cm 검사만으로 성공/피해 권한을 확정하지 않는다.

MOVE REQUEST · RUNNING · RESULT

이동 완료 결과가 다음 Task 실행을 결정합니다

두 결과는 대안 분기입니다. 진행 중인 Task가 성공·실패 두 경로를 모두 실행하는 것이 아닙니다. 별도의 Abort는 정상 완료와 구분합니다.

이동 Task의 완료 결과와 다음 행동이동 전제를 만족하고 Move To를 요청한 뒤에는 진행 중 결과를 기다린다. 성공하면 Sequence의 다음 Task를 실행하고 실패하면 같은 Sequence의 다음 Task를 실행하지 않는다. 성공이 피해 적용 허가를 뜻하지 않는다.이동 전제Controller · MovementNavMesh · 유효한 목표Move To · 진행 중완료 결과를 기다림다음 Task 아직 미실행성공다음 Task 실행공격 시점 조건은 다시 검사실패Sequence 실패같은 Sequence 공격 미실행
이동 Task의 완료 결과와 다음 행동이동 전제를 만족하고 Move To를 요청한 뒤에는 진행 중 결과를 기다린다. 성공하면 Sequence의 다음 Task를 실행하고 실패하면 같은 Sequence의 다음 Task를 실행하지 않는다. 성공이 피해 적용 허가를 뜻하지 않는다.이동 전제Controller · MovementNavMesh · 유효한 목표Move To · 진행 중완료 결과를 기다림다음 Task 아직 미실행성공다음 Task 실행공격 시점 조건은다시 검사실패Sequence 실패같은 Sequence공격 미실행

거리 조건과 실제 Task 완료는 별도로 확인합니다. 이동 성공 후 공격 대상·사거리·공격 가능 조건을 다시 검증합니다.

이 예의 조건

  • 본문과 원 도표에 제시된 사례의 입력·조건을 사용합니다. 설명용 수치나 독립 비교 경로는 각 단계에 표시합니다.
  • 현재 상태·값과 전환 근거의 위치는 모든 단계에서 같습니다. 조건이 맞지 않거나 실행되지 않은 경로를 성공한 동작으로 해석하지 않습니다.
예의 값과 변화
관찰·상황값·보충 정보변화·이유
이동 전제

Move To 요청에 필요한 상태를 확인한다.

  • 현재: 요청 전 검사
  • 거리 150 cm: 성공 자체 아님
  • 거리만으로 도착·피해 권한을 확정하지 않는다.
진행 대기

이동 Task가 Running 상태인 동안 결과를 기다린다.

  • Task: Running
  • 다음 Task: 미시작
  • 요청 시작과 이동 완료는 다른 이벤트다.
결과 분기

성공은 다음 Task, 실패는 해당 경로 종료다.

  • 성공: 다음 Task
  • 실패: 종료/정책
  • 실패한 이동을 공격 성공으로 연결하지 않는다.

위 그림은 Move To 하나가 요청되고 끝나기까지의 흐름입니다. 왼쪽의 이동 전제는 이동을 요청하기 전에 갖춰져야 할 것으로, 폰을 조종하는 컨트롤러와 Movement Component, 그리고 내비메시와 유효한 목표입니다. 이 전제를 만족해 Move To를 요청하면 태스크는 진행 중 상태가 되어 완료 결과를 기다리고, 그동안 시퀀스의 다음 태스크는 아직 실행되지 않습니다.

결과는 두 갈래의 대안입니다. 성공하면 시퀀스가 다음 태스크를 실행하고, 실패하면 시퀀스가 실패로 끝나 같은 시퀀스의 공격은 실행되지 않습니다. 그림의 설명처럼 진행 중인 태스크가 두 경로를 모두 실행하는 것이 아니며, 바깥 조건에 따른 중단(Abort)은 이 정상 완료와 따로 다룹니다. 또 이동이 성공했다고 피해를 줘도 된다는 허가가 생기는 것은 아니므로, 공격할 때의 대상과 사거리, 공격 가능 조건은 그 시점에 다시 검사합니다.

단계 그림은 같은 흐름을 세 단계로 나눕니다. 첫 단계에서 Move To 요청에 필요한 상태를 확인하고, 둘째 단계에서 이동 태스크가 진행 중인 동안 결과를 기다리며, 셋째 단계에서 성공이면 다음 태스크로, 실패면 해당 경로의 종료로 갈라집니다.


더 넓게 쓰는 내비게이션 기능

내비게이션 시스템에는 기본 이동 외에도 쓸 만한 기능이 있습니다. 내비게이션 링크는 점프나 사다리 오르기처럼 걸어서는 갈 수 없는 경로를 직접 지정할 때 씁니다. 절벽 사이를 뛰어넘거나 사다리를 오르는 경로를 링크로 잇고, 그 구간에서 실제로 뛰거나 오르는 동작은 따로 구현합니다.

문이 열리거나 상자가 옮겨지는 것처럼 레벨이 실행 중에 바뀐다면 RecastNavMesh의 Runtime Generation 설정을 환경에 맞게 고릅니다. 지오메트리가 바뀔 때 내비메시를 다시 만드는 Dynamic과, 내비게이션 수정자(modifier)의 변화만 반영하는 Dynamic Modifiers Only는 반영하는 범위가 다르므로, Recast 내비메시를 쓴다고 모든 변화가 저절로 반영되지는 않습니다.

경로 탐색 외에 특정 위치로 갈 수 있는지, 가장 가까운 이동 가능 지점이 어디인지를 묻는 내비게이션 쿼리도 할 수 있습니다. 또 비헤이비어 트리가 아닌 일반 블루프린트에서 AI를 이동시킬 때는 AI Move To 노드를 씁니다. 공식 문서의 예제는 이 노드의 Pawn에 자기 자신을, Destination에 무작위 위치를 넣고, 성공과 실패 출력 뒤에 각각 다음 이동을 이어 붙입니다.


움직이지 않는 AI 진단하기

Move To가 실패하거나 AI가 멈춰 보이면, 내비메시, 블랙보드 값, 도착 반경을 차례로 나누어 확인해야 원인을 빨리 좁힐 수 있습니다.

먼저 뷰포트에서 P 키를 눌러 내비메시가 제대로 만들어졌는지 봅니다. AI가 서 있는 곳과 가야 할 곳이 모두 녹색이어야 하며, 그사이가 끊겨 있다면 경로가 없는 것입니다. 다음으로 플레이 중에 게임플레이 디버거(Gameplay Debugger)를 켜서 AI와 내비메시 정보를 확인합니다. 기본 키는 작은따옴표(') 키이며, 콘솔 명령 show navigation으로 내비메시를 표시할 수도 있습니다. 디버거를 쓸 수 있는지는 키 설정과 빌드 설정에 따라 달라질 수 있습니다.

마지막으로 비헤이비어 트리 에디터의 디버그 드롭다운에서 지금 실행 중인 AI를 고르면, 블랙보드의 값 변화와 트리의 실행 흐름을 실시간으로 볼 수 있습니다. 목표 키가 비어 있는지, Move To에서 멈춰 있는지, 이미 실패해 다른 가지로 넘어갔는지를 여기서 확인합니다.

내비게이션 시스템은 AI가 내린 이동 판단을 실제 경로로 바꾸는 기반입니다. AI가 기대대로 움직이지 않을 때는 비헤이비어 트리의 흐름, EQS가 고른 위치, 내비메시의 상태를 함께 확인합니다.


정리

  • 내비메시는 AI가 걸을 수 있는 표면을 폴리곤으로 나타낸 것으로, NavMeshBoundsVolume으로 범위를 정하면 만들어지고 P 키로 표시를 켜고 끕니다.
  • Agent Radius, Agent Height, Agent Max Slope, Agent Max Step Height를 AI의 실제 크기와 이동 능력에 맞춥니다.
  • Move To는 블랙보드 키의 위치나 액터로 이동하며, Acceptable Radius와 반지름 포함 옵션이 도착 판정을 정합니다. 움직이는 목표는 액터 키라면 Track Moving Goal이, 갱신되는 Vector 키라면 Observe Blackboard Value가 따라가게 합니다.
  • Move To가 진행 중인 동안 시퀀스의 다음 태스크는 실행되지 않고, 실패하면 같은 시퀀스의 나머지도 실행되지 않습니다.
  • 움직이지 않는 AI는 내비메시 표시, 게임플레이 디버거, 비헤이비어 트리의 디버그 화면 순서로 원인을 좁힙니다.

연습 문제

1. 도착 거리와 다음 행동

평평한 바닥에서 움직이지 않는 유효한 목표로 이동하고, Allow Partial Path는 끕니다. Acceptable Radius는 예시 트리처럼 150cm이고, 에이전트와 목표의 반지름을 포함하는 두 옵션은 모두 끕니다. 이 문제는 수평 거리 조건만 비교합니다. 목표와의 거리가 140cm일 때와 160cm일 때 각각 150cm 안에 드는가요? Move To가 아직 진행 중일 때 뒤의 Attack Player가 실행될까요? 이동이 성공했다는 것만으로 피해를 줘도 될까요?

해설 보기

150cm는 1.5m입니다. 140cm는 거리 조건 안에 들고, 160cm는 밖에 있습니다. 다만 이것은 거리 조건의 계산일 뿐이며, 실제로 태스크가 성공했는지는 따로 확인해야 합니다.

Move To가 진행 중인 동안 뒤의 Attack Player는 실행되지 않고, 성공 결과가 나온 뒤에야 시퀀스가 다음 태스크로 넘어갑니다. 이동이 실패하면 같은 시퀀스의 공격은 실행되지 않습니다. 이동이 성공한 뒤에도 공격하는 순간의 유효한 대상, 사거리, 공격 가능 조건을 다시 확인합니다. 높이 차이나 부분 경로, 반지름 포함 옵션을 바꾸면 이 문제의 단순한 조건을 그대로 적용할 수 없습니다.

2. 제자리에 서 있는 순찰병

순찰 시퀀스의 Find Random Location은 블랙보드에 좌표를 제대로 저장하는데, AI가 이동하지 않고 곧바로 Wait도 건너뛴 채 같은 행동을 반복합니다. 무엇부터 확인해야 할까요?

해설 보기

Wait까지 건너뛴다는 것은 Move To가 진행 중으로 머물지 않고 곧바로 실패해, 순찰 시퀀스가 실패로 끝나고 있다는 뜻으로 볼 수 있습니다. 시퀀스는 자식 하나가 실패하면 나머지를 실행하지 않기 때문입니다.

그래서 이동이 실패하는 원인부터 찾습니다. P 키로 AI가 서 있는 곳과 저장된 좌표가 모두 녹색 내비메시 위에 있고 서로 이어져 있는지 확인하고, AI 컨트롤러가 폰을 조종하고 있는지와 폰에 Movement Component가 있는지 봅니다. 무작위 좌표를 고를 때 내비메시 위의 도달 가능한 지점만 고르도록 만들면 이런 실패를 줄일 수 있습니다.

3. 도망가는 플레이어 쫓기

추적 가지의 Move To가 플레이어를 쫓는데, 플레이어가 움직여도 AI가 처음 목표로 삼은 곳까지만 갔다가 멈춘 뒤 다시 출발합니다. 이 끊기는 추적을 줄이려면 어떤 설정을 확인해야 할까요?

해설 보기

먼저 목표를 어떤 키로 넘기는지 확인합니다. 목표가 TargetActor 같은 액터 키라면, 플레이어가 움직여도 키에 든 값은 같은 액터이므로 값이 바뀌지 않습니다. 이때는 Move To의 Track Moving Goal이 켜져 있어야 이동 중에도 그 액터의 현재 위치를 따라갑니다.

목표가 서비스가 주기적으로 갱신하는 Vector 키라면 Observe Blackboard Value를 확인합니다. 이 옵션을 켜면 키의 값이 바뀔 때 이동을 새 목표로 다시 시작하므로, AI가 갱신된 위치를 따라갑니다. 서비스의 갱신 주기가 너무 길면 옵션을 켜도 추적이 늦어 보일 수 있으므로 주기도 함께 조정합니다.

내비메시를 배치하고 AI Move To로 이동시키는 기본 예제는 언리얼 엔진 공식 문서의 기본 내비게이션에서 확인할 수 있습니다.

다음 글 기본 센서 시스템 구현 (시각, 청각)에서는 이 글의 트리가 기대는 "플레이어가 보이는가"를 실제로 판단하도록, AI Perception의 시각과 청각 감각을 설정하고 감지 결과를 블랙보드에 반영합니다.