AI의 행동 트리 : 작동 방식

Behaviour Tree의 대한 소개로, 예제와 심층적인 설명과 강력한 트리를 만드는 데 필요한 몇가지의 팁도 포함되어 있다.

---

---

📌 Introduction (소개)

인터넷에는 Behaviour Tree 튜토리얼과 가이드가 많이 있지만 Behaviour Tree 의 실제 코드 구현에 중점을 두거나, 다음과 같은 다이어그램을 사용하여 실제 적용 가능한 예 없이 일반 문맥이 없는 노드의 흐름에만 순수하게 초점이 맞춰저있다.

Behaviour Tree의 핵심 원리를 이해하는 데 매우 큰 도움이 되지만, Behaviour Tree가 어떻게 작동하는지 알고 있음에도 불구하고 어떠 종류의 노드가 되어야 하는지에 대한 실제 문맥이 전혀 없는 상황이었다.
이 글을 통해 게임을 위해 생성하거나 실제로 완전히 개발된 Behaviour Tree가 어떤 모습일지 등을 알 수 있을 것이다.

이 글은 JBT - Java Behaviour Trees(http://sourceforge.net/projects/jbt/)를 사용하고 있으며 데코레이터 노드 유형 중 일부는 실제로 일반적인 Behaviour Tree가 아닌 JBT에 고유한 것일 수 있지만 PZ Behaviour Tree가 작동하는 방식으로 통합되어 있으므로 구현을 고혀래 볼 가치가 있다. 귀하의 특정 Behaviour Tree는 이를 지원하지 않을 수도 있다.

Project Zomboid NPC의 개발을 통해 꽤 확실한 결과를 얻었으므로 적어도 Behaviour Tree로 무엇을 성취할 수 있는지에 대해 알 수 있을 것이다. 구현에 대해 자세히 설명하지는 않고 Project Zomboid에서 사용된 몇 가지 추상적인 예만 제공할 것이다.

---

📌 Basic (기초)

유한 상태 머신(Finite State Machine)이나 AI 프로그래밍에서 사용되는 기타 시스템과 달리 Behaviour Tree는 AI entity의 의사 결정 흐름을 제어하는 계층적 노드 트리이다.
Tree 범위에서 Leaf(잎)은 AI 개체를 제어하는 실제 명령이고, 가지를 형성하는 것은 상황에 가장 접합한 명령 Sequence(시퀀스)에 도달하기 위해 AI가 나무를 따라 내려가는 것을 제어하는 다양한 유형의 유틸리티 노드이다.

트리는 특정 기능을 수행하는 하위 트리를 호출하는 노드로 매우 깊어질 수 있으므로 개발자는 매우 설득력 있는 AI 동작을 제공하기 위해 서로 연결될 수 있는 동작 라이브러리를 마들 수 있다.
개발은 반복 가능성이 매우 높다.
기본 동작을 형성하여 시작한 다음 목표 달성을 위한 대체 방법을 처리하기 위한 새 분기를 생성하고 상황에 따라 붕기를 정렬하여 특정 동작이 실패할 경우 AI가 대체 전술을 사용할 수 있도록 한다.

---

📌 Data Driven vs Code Driven (데이터 중심 vs 코드 중심)

이러한 구별은 이 가이드와 거의 관련이 없지만 Behaviour Tree에는 다양한 구현이 가능하는 점에 유의해야 한다. 주요 차이점은 트리가 코드베이스 외부에서 (예 : XML 또는 독점 형식으로 정의되어 외부 편집기로 조작되는지) 또는 트리 구조가 중첩된 클래스 인스턴스를 통해 코드에서 직접 정의되는지 여부이다.

JBT는 이 두가지의 혼합을 사용한다. 여기에서 Behaviour Tree를 시각적으로 구성할 수 있도록 편집기가 제공되지만 내고내기 명령줄 도구는 실제로 코드 기반의 Behaviour Tree를 나타내기 위해 Java코드를 생성한다.

어떤 구현을 하든 실재로 게임 특정 업무를 수행하고 캐릭터를 제어하거나 캐릭터의 상황이나 주변 환경을 확인하는 노드인 Leaf Node(리프 노드)는 코드에서 직접 정의해야 하는 항목이다. 그런 다음 트리에서 이를 활용하여 복잡한 동작을 제공할 수 있다. 이러한 노드가 얼마나 표현력이 뛰어난지, 때로는 단순한 문자 명령이 아니라 트리 자체 내에서 데이터를 조작하는 표준 라이브러리로 더 많이 작동하는 경우도 있어 Behaviour Tree를 흥미롭게 만든다.

---

📌 Tree Traversal (트리 순회)

Behaviour Tree의 핵심 측면은 코드베이스 내의 방법과 달리 트리의 특정 노드나 분기를 완료하는 데 게임의 맣은 틱이 필요할 수 있다는 것이다. Behaviour Tree의 기본 구현에서 시스템은 매 프레임마다 트리의 루트에서 아래로 이동하여 트리 아래의 각 노드를 테스트하여 어느 노드가 활성화 상태인지 확인하고 현재 환성 노드에 도달할 때 까지의 모든 모드를 다시 확인한다. (항상 다시 한번 검토,체크 해야한다)

이는 작업을 수행하는데 매우 효율적인 방법은 아니다. 특히 개발중에 Behaviour Tree가 개발되고 확장됨에 따라 Behaviour Tree가 더 깊어질 수록 그렇다. 구현하는 모든 Behaviour Tree는 현재 처리 중인 노드를 저장하여 전체 트리를 틱 단위로 순회나는 대신 Behaviour Tree 엔진 내에서 직접 틱할 수 있도록 해야한다. (JBT는 이 범주에 속한다.)

➔ 틱 이란?

"틱"이라는 용어는 게임 프로그래밍이나 인공 지능 (AI) 분야에서 주로 사용되는 용어이다. 여러 동작이나 처리가 주기적으로 반복되는 것을 나타낸다. 이는 게임 루프나 AI엔진에서 매 프레임이나 주기마다 수행되는 작업을 의미한다.

여기서 말하는 "틱"은 엔진이나 시스템이 특정 간격으로 주기적으로 실행되는 것을 의미한다. 게임 루프에서는 일반적으로 초당 몇 번의 업데이트가 발생하는지를 타나내는 단위로 사용된다.

또한, Behaviour Tree(동작 트리)의 "틱"은 트리의 각 노드가 실행되는 주기를 나타낸다. Behaviour Tree(동작 트리)는 게임 엔진이나 AI시스템에서 주어진 주기에 따라 노드를 실행하여 원하는 동작을 수행한다.

---

📌 Flow (흐름)

Behaviour Tree는 여러 유형의 노드로 구성되지만 일부 핵심 기능은 Behaviour Tree의 모든 노드 유형에 공통된다. 이는 세 가지 상태 중 하나를 반환할 수 있다는 것이다. (Behaviour Tree의 구현에 따라 세 가지 이상의 반환상태가 있을 수도 있다.)

세 가지 일반적인 상태는 다음과 같다.

• Success (성공)
• Failure (실패)
• Running (실행중)

이름에서 알 수 있듯이 처음 두 개는 부모에게 자신의 작업이 성공했거나 실패했음을 알린다. 세 번째는 성공이나 실패가 아직 결정되지 않았으며, 노드가 계속 실행 중이라는 의미이다. 다음에 트리가 틱 될 때 노드가 다시 틱 되며, 이 시점에서 다시 성공, 실패 또는 계속 실행될 기회를 갖게 된다.

이 기능은 게임의 여러 틱 동안 노드의 처리가 지속되도록 하기 때문에 Behaviour Tree의 강력한 핵심이다. 예를 들어 Walk 노드는 경로 계산을 시도하는 동안뿐만 아니라 캐릭터가 지정된 위치까지 걷는 데 걸리는 시간 동안 Running 상태를 제공한다. 어떤 이유로든 경로 찾기가 실패했거나 캐릭터가 대산 위치에 도달하는 것을 막기 위해 걷는 동안 다른 합병증이 발생한 경우 노드는 실패를 부모에게 반환한다. 어느 시점에서든 캐릭터의 현재 위치가 대산 위치와 같으면 Walk 명령이 성공적으로 실행되었음을 나타내는 성공(Success)를 반환한다.

즉, 이 노드는 성공과 실패에 대해 정의된 주철 계약을 갖고 있으며, 이 노드를 활용하는 모든 트리는 이 노드에서 받은 결과를 확신할 수 있다. 그런 다음 이러한 상태는 트리의 흐름을 전파하고 정의하여 AI가 원하는 대로 작동하도록 트리 아래로 일련의 이벤트와 다양한 실행 경로를 제공한다.

이 공유 기능을 공통적으로 사용하면 동작 트리 노드의 세 가지 주요 원형이 있다.

• 복합 (Comoisite)
• 데코레이터 (Decorator)
• 리프 (Leaf)

➔ Composite (복합)

복합 노드(Composite Node)는 하나 이상의 자식을 가질 수 있는 노드이다. 이들은 특정한 복합 노드에 따라 첫 번째 부터 마지막까지의 순서 또는 무작위 순서로 이러한 자식 항목 중 하나 이상을 처리하며, 어떤 단계에서는 처리가 완료된 것으로 간주하고 성공 또는 실패를 상위 항목에 전달한다. (자식 노드의 성공 또는 실패에 따라 결정되는 경우가 많다.) 자식 항목을 처리하는 동안 계속해서 Running을 상위 항목으로 반환한다.

가장 일반적으로 사용되는 복합 노드(Composite Node)는 시퀀스(Sequence)이다. 이는 단순히 각 자식 항목을 순서대로 실행하고, 자식 항목 중 하나다라도 실패할 때 실패를 반환하고, 모든 자식 항목이 성공 상태를 반환하면 성공을 반환한다.

➔ Decorator (데코레이터)

복합 노드(Composite Node)와 마찬가지로 데코레이터 노드(Decorator Node)에는 자식 노드가 있을 수 있다. 복합 노드와 달리 구체적으로 자식 노드는 하나만 가질 수 있다. 그들의 기능은 데코레이터 노드의 유형에 따라 자식 노드의 상태에서 받은 결과를 변환하거나 자식을 종료하거나 자식 처리를 반복하는 것이다.

데코레이터의 일반적으로 사용되는 예는 단순히 하위 항목의 결과를 반전시키는 Inverter이다. 자식이 실패하면 부모에게 성공을 돌려주거나, 자식이 성공하면 실패를 부모에게 돌려준다.

➔ Leaf (잎)

가장 낮은 수준의 노드 유형이며 자식을 가질 수 없다.

그러나 Leaf(잎)는 가장 강력한 노드 유형이다. 이는 트리가 실제로 유용한 작업을 수행하는 데 필요한 게임별 또는 캐릭터별 테스트나 작업을 수행하기 위해 게임에서 정의하고 구현하기 때문이다.

위에서 사용한 예는 Walk이다. Walk Leaf Node는 캐릭터가 지도의 특정 지점으로 걸어가도록 하고 결과에 따라 성공 또는 실패를 반환한다.

Leaf Node가 무엇인지 직접 정의할 수 있기 때문에(종종 아주 최소한의 코드로)복합(Comosite) 및 데코레이터 위에 계측화할 때 매우 표현력이 뛰어나며 매우 복잡한 계층화되고 지능적으로 우선 순위가 지정된 동작을 수행할 수 있는 매우 강력한 동작 트리를 만들 수 있다.

게임 코드의 비유로 설명하면, Composite, Decorator를 함수라고 생각하고, if문 , while 루프 및 기타 언어 구조를 코드의 흐름을 정의하는 데 사용되는 것으로 생각할 수 있다. 반면 Leaf Node는 실제로 AI 캐릭터에 대한 작업을 수행하거나 상태 또는 상황을 테스트하는 게임 특정 함수 호출로 생각할 수 있다.

이러한 노드는 매개변수를 사용하여 정의할 수 있다. 예를 들어 Walk 리프 노드에는 캐릭터가 이동할 좌표를 가질 수 있다.

이러한 매개변수는 트리를 처리하는 AI 캐릭터의 컨텍스트(문맥) 내에 저장된 변수에서 가져올 수 있다. 예를 들어 이동할 위치는 'GetSafeLocation' 노드에서 결정되어 변수에 저장되고, 그럼 다음 'Walk' 노드는 컨텍스트(문맥)에 저장된 해당 변수를 사용하여 목적지를 정의할 수 있다. 트리 처리 중에 임의의 지속 데이터를 저장하고 변경하기 위해 노드 간에 공유된 컨텍스트(문맥)를 사용하는 것이 Behaviour Tree를 강력하게 만드는 부분이다.

또 다른 중요한 종류의 리프 노드는 다른 Behaviour Tree를 호출하며, 호출된 트리로 기존 트리의 데이터 컨텍스트(문맥)를 전달한다.

이러한 노드들은 Behaviour Tree를 모듈화하여 Behaviour Tree를 무수히 많은 장소에서 재사용할 수 있게 해준다. 아마도 컨텍스트 내에서 특정 변수 이름을 사용하여 작동할 수 있다. 예를 들어 'Break into Building' 행동은 'targetBuilding' 변수가 필요할 수 있으며, 따라서 부모 트리는 이 변수를 컨텍스트에서 설정한 다음 하위 트리 Leaf 노드를 통해 하위 트리를 호출할 수 있다.

---

📌 Composite Nodes (복합 노드)

여기에서는 Behaviour Tree내에서 가장 일반적인 구성 노드에 대해 이야기한다. 다른 유형도 있지만, 여기에서는 기본적인 내용을 다루어 본질적으로 복잡한 행동트리를 작성하는 데 도움이 될 것이다.

➔ Sequences (시퀀스)

Behaviour Tree 내에서 찾을 수 있는 가장 간단한 구성 노드 중 하나는 '시퀀스'이다. 그 이름이 모든 것을 말해준다. 시퀀스는 각 자식을 순서대로 방문하며 처음부터 시작하여 첫 번째를 호출하고, 그것이 성공하면 두 번째를 호출하고 이어서 게속된다. 자식 중 하나라도 실패하면 즉시 부모에게 실패를 반환한다. 시퀀스의 마지막 자식이 성공하면 시퀀스느 부모에게 성공을 반환한다.

Behaviour Tree의 노드 유형이 다양한 응용 프로그램을 가지고 있다는 것을 명확히 해야 한다. 시퀀스의 가장 명백한 사용법은 완전히 완료해야 하는 일련의 작업을 정의하고, 그 중 하나가 실패하면 해당 작업 시퀀스의 추가 처리가 불필요해진 경우이다. 예를 들어 :

이 시퀀스는 아마도 명확하게 드러나듯이 주어진 캐릭터가 문을 통과하고 뒤로 문을 닫게 만들 것이다. 사실, 실제로는 이러한 노드들이 프로덕션 환경에서 더 추상화되고 매개변수를 사용할 것이다. Walk(위치), Open(열 수 있는 대상), Walk(위치), Close(열 수 있는 대상)

따라서 처리 순서는 다음과 같다 :

시퀀스 ➔ 문까지 걷기(성공) ➔ 시퀀스(실행중) ➔ 문 열기(성공) ➔ 시퀀스(실행중) ➔ 문 통과하기(성공) ➔ 시퀀스(실행중) ➔ 문 닫기(성공) ➔ 시퀀스(성공) ➔ 이 시점에서 시퀀스는 자신의 부모에게 성공을 반환한다.

캐릭터가 문으로 걷는 데 실패하는 경우(길이 막혀있는 등), 문을 열어보거나 통과하려고 하는 것은 더 이상 관련이 없다. 시퀀스는 걷기가 실패한 순간에 실패를 반환하며, 시퀀스의 부모는 실패를 우아하게 처리할 수 있다.

시퀀스가 자연스럽게 캐릭터 작업의 순서로 이어지며, AI Behaviour Tree가 이것이 유일한 사용 방법이라고 제안하는 경향이 있기 때문에, 여러 시퀀스를 활용하는 다양한 방법이 있다는 것이 명확하지 않을 수 있다. 이걸 고려해보라 :

위의 예에서 우리는 작업 목록이 아닌 테스트 목록이 있다. 자식 노드는 캐릭터가 배고픈지, 그들이 소지품에 음식이 잇는지, 그리고 안전한 위치에 있는지를 확인하고, 이 모든 조건이 시퀀스 부모에게 성공을 반환하면 캐릭터가 음식을 먹게 된다.
이렇게 시퀀스를 사용하면 동작을 수행하기 전에 하나 이상의 조건을 테스트할 수 있다. 코드에서의 if문이나 회로에서의 AND 게이트와 유사하다. 모든 자식이 성공해야 하며, 이러한 자식은 복합, 데코레이터 또는 리프 노드의 어떤 조합이든 될 수 있으므로 AI Brain 내에서 강력한 조건 확인이 가능하다.

위 섹션에서 언급한 Inverter Decorator(인버터 데코레이터)를 예로 들어보겠다.

이전 예와 기능적으로 동일하며 여기서는 인터버를 사용하여 테스트를 무효화하고 NOT 게이트를 제공하는 방법을 보여준다. 즉, 캐릭터나 게임 세계의 조건을 테스트 하는 데 필요한 노드의 양을 대폭 줄일 수 있다.

➔ Selector (선택자)

선택자는 시퀀스의 양(+)에 대한 음(-)이다.(즉, 반대) 시퀀스가 모든 자식이 성공해야 성공으로 반환되는 AND 연산과는 달리, 선택자는 그 자식 중 하나라도 성공하면 성공으로 반환되고 그 이후의 자식은 처리하지 않는다. 첫 번째 자식을 처리하고, 실패하면 두 번째를 처리하고, 그것도 실패하면 세 번째를 처리하고, 성공이 나오면 즉시 성공으로 반환된다. 모든 자식이 실패하면 실패한다. 이는 선택자가 OR 게이트와 유사하며, 여러 조건을 확인하여 그 중 하나라도 참인지 확인하는 조건문으로 사용할 수 있다.

선택자의 주요 강점은 가장 유리한 것부터 가장 불리한 것까지의 우선 순위에 따라 여러 다양한 경로를 표현하고, 어떤 행동 경로에서든 성공을 반환할 수 있는 능력이 있다. 이것이 의미하는 바는 엄청나며, 선택자를 사용하여 매우 빠르고 정교한 AI 행동을 개발할 수 있다.

이전에 언급한 문 시퀀스 예제를 다시 살펴보겠다. 이번에는 잠재적인 문제와 그것을 해결하기 위한 선택자를 추가한다.

그렇다, 여기서는 몇 가지 새로운 노드만 사용하여 잠긴 문을 지능적으로 처리할 수 있다.

그렇다면 이 선택자가 처리될 때 어떤 일이 일어날까?

먼저 문 열기 노드를 처리한다. 가장 선호하는 동작은 문을 열기만 하는 것이다. 복잡하지 않다. 그 작업이 성공하면 선택자도 성공한다. 그것이 잘 처리된 작업임을 알고 더 이상 해당 선택자의 다른 자식 노드를 탐색할 필요가 없다.

그러나 문이 잠겨있어 열리지 않으면 문 열기 노드가 실패하고 실패를 부모 선택기에 전달한다. 이 시점에서 선택자는 두 번째 노드 또는 두 번째로 선호되는 작업을 시도한다. 즉, 문을 열기 전에 문을 열 수 있는지 시도한다.

여기서 우리는 다른 시퀀스를 생성했다(선택자에 성공을 다시 전달하려면 완전히 완료되어야 함) 우리가 먼저 문을 열기 전에 문을 잠금 해제하고 그런 다음 열어보려고 시도한다.

문을 열 때 잠금 해제 단계 중 어느 하나가 실패하면(AI가 열쇠를 가지고 있지 않거나, 필요한 자물쇠 따는 기술이 없을 수 있으며, 또는 자물쇠를 풀어보았지만 문을 열려고 시도할 때 문이 못으로 닫혀 있는 것을 발견했을 지도 모른다), 실패를 선택자에 반환하고 선택자는 그런 다음 코스의 세 번째로 넘어가 문을 부수게 된다.

캐릭터가 충분히 강하지 않다면 이 작업이 실패할 수 있다. 이 경우 더 이상 취할 수 있는 조치가 없으므로 선택자는 실패하고 이로 인해 선택자의 부모 시퀀스가 실패하여 문을 통과하려는 시도를 포기한다.

이를 한 단계 더 나아가면, 아마도 이 선택기 위에는 이 시퀀스의 실패를 기반으로 다른 조치를 선택할 선택자가 있을 것이다.

여기서는 최상위에 선택자를 추가했다. 좌측(가장 선호하는 쪽)에서는 문을 통해 들어가려고 하며, 그 실패 시에는 창문을 통해 들어가려고 한다. 실제로 구현하는 경우 이 것이 이렇게 보이지는 않을 가능성이 높으며, 이것은 Project Zomboid에서 한 것을 단순화한 것이다. 나중에 더 일반적이고 유용한 구현에 대해 논의하겠다.

요약하면, 여기에는 특정 건물 내부로 들어가는 '건물 진입' 행동이 있다. 건물 내부로 들어가거나 그렇게 할 수 없음을 부모에게 알릴 수 있다. 아마도 창문이 없을 수도 있을 것이다. 이 경우 최상위 선택자가 실패하고 부모 선택자가 AI에게 다른 건물로 향하도록 지시할 수도 있다.

Behaviour Tree에서의 중요한 요소 중 하나는 실패가 무엇을 하려는 것에 대한 치명적인 중단이 아니라 결정 프로세스의 자연스러운 부분이라는 것이다. 이전 시도에 비해 AI개발을 크게 단순화시킨 것이다. (어, 경로찾기 실패, 이제 어떡하지?) 실패는 AI시스템의 패러다임에 자연스럽게 적합한 의사 결정 과정의 일부로 간주된다.

가능한 모든 상황에 대해 안전 장치와 대체 조치를 계층화 할 수 있다. Project Zomboid의 예는 EnacheItemInInventory 동작이다.

이 동작은 인벤토리 아이템 유형을 사용하며 선택기를 사용하여 아이템이 NPC의 인벤토리에 있는지 확인하기 위해 같은 동작에 대한 다른 항목 매개 변수로 재귀 호출을 포함한다.

먼저 동작은 아이템이 캐릭터의 주요 최상위 인벤토리에 이미 있는지 확인한다. 이것은 이상적인 상황으로, 아무런 조치가 필요하지 않다. 아이템이 이미 있으면 선택자가 성공하고 따라서 전체 동작이 성공한다. EnacheItemInInventory가 성공하고 아이템이 사용 가능하다.

아이템이 캐릭터의 인벤토리에 없는 경우 가방이나 배낭의 내용을 확인한다. 아이템을 찾으면 해당 아이템을 가방에서 최상위 인벤토리로 전송한다. 이렇게 하면 성공 기준이 충족되므로 성공한다.

이 경우에도 실패하면 선택자의 세 번째 분기에서 아이템이 캐릭터가 현재 머물러 있는 건물에 있는지 여부를 확인한다. 그렇다면 캐릭터는 아이템이 들어 있는 컨테이너의 위치로 이동하고 컨테이너에서 아이템을 가져온다. 다시 한번 기준이 충족되므로 성공이다.

만약 이것도 실패하면 NPC 슬리브에 또 다른 트릭이 있다. 그러면 그들은 원하는 아이템을 얻기 위한 제작 레시피 목록을 반복하고, 각 레시피에 대해 각 원료 아이템을 반복하며, 각각의 아이템에 대해 순환적으로 EnsureItemInInventory 동작을 호출한다. 이 중 하나라도 성공하면 NPC가 이제 원하는 아이템을 제작할 수 잇는 모든 원료를 소유하고 있다는 것을 의미한다. 그 캐릭터는 그 원료들을 사용하여 아이템을 제작한 다음 성공을 반환하여 아이템이 있음을 충족한다.

만약 이것도 실패한다면, EnsureItemInInventory 동작은 더 이상 대비책이 없이 실패하고, NPC는 그 아이템을 찾기 위해 앞으로의 약탄 미션 중에 주의해야 할 아이템 목록에 추가하고 그 아이템 없이 살아가게 된다.

이 결과로 NPC는 필요한 재료가 있으면 게임에서 원하는 아이템을 제작하거나 해당 재료를 건물에서 얻을 수 있다.

행동의 반복적인 특성으로 인해 재료가 없는 경우, 더 낮은 수준의 재료에서 제작을 시도하며 필요한 항목을 제작할 수 있도록 건물을 찾아가고 여러 단계의 아이템을 제작하여 실제로 필요한 아이템을 제작할 수 있게 된다.

Project Zomboid NPCs by Youtube

갑자기 복잡하고 인상적으로 보이는 AI행동이 생겼지만 실제로는 비교적 간단한 노드가 서로 겹쳐져 있는 것이다. EnsureItemInInventory 행동은 이후에 NPC가 인벤토기에 특정 항목이 있는지 확인해야 하는 경우 다양한 트리 전체에서 자유롭게 사용될 수 있다.

개발 중 어느 시점에서 우리는 더 많은 대안을 추가하여 NPC가 실제로 필수로 원하는 항목을 찾아나가도록 할 것이며, 해당 항목을 가장 많이 포함하고 있을 것으로 예상되는 약탈 대상을 선택할 수 있게 할 것이다.

앞으로 우리는 높은 우선순위의 다른 안전 장치로, 선택된 항목과 동일한 목표를 달성할 수 있는 다른 항목을 고려할 수 있을 것입니다. 언젠가 makeshift(임시 변통) 도구를 지원하는 코드를 작성하게 되면, 덜 효과적인 대안을 찾아 돌로 못을 박는 것이 좀비가 떠도는 철물점으로 가는 것보다 나은 해결책이 될 수 있습니다.

개발 중에 트리를 확장하기가 쉬워서 '작업을 수행하는' 간단한 동작을 만들고 나서 선택자를 통해 더 견고한 안전 장치와 대처책을 고려할 수 있도록 NPC 동작을 반복적으로 향상시키는 것이 쉽습니다. 제작중 안전 장치는 나중에 많이 추가되었으며 NPC가 목표를 달성하는 데 도움을 주는 동작을 더 추가합니다.

더욱이, 신중하게 적절히 우선순의를 지정하면 이러한 대처책들은 본질적으로 스크립트된 동작임에도 불구하고 AI캐릭터에게 지능적인 문제해결과 자연스러운 의사 결정을 부여한다.

➔ Random Selectors / Sequences (무작위 선택자 / 시퀀스)

이전 섹션에서 설명한 것과 비슷하기 때문에 자세히 다루지는 않는다. 무작위 시퀀스 / 선택자 는 하위 노드가 처리되는 실제 순서가 무작위로 결정된다는 점을 제회하면 이름과 동일하게 작동한다. 이는 가능한 행동 과정의 실행에 대해 명확하고 바람직한 순서가 없는 경우 AI 캐릭터에 더 많은 예측 불가능성을 추가하는 데 사용될 수 있다.

---

📌 Decorator Nodes (데코레이터 노드)

➔ Inverter (인버터)

이미 이것에 대해 다루었다. 간단히 말해서 하위 노드의 결과를 반전하거나 무효화한다. 성공은 실패가 되고, 실패는 성공이 된다. 조건부 테스트에 가장 자주 사용된다.

➔ Succeeder (성공)

Succeccder는 하위 노드가 실제로 무엇을 반환했는지에 관계없이 항상 성공을 반환한다. 이는 실패가 예상되거나 예상되는 트리의 분기를 처리하고 싶지만 분기가 있는 시퀀스의 처리를 포기하고 싶지 않은 경우에 유용하다. 이 유형의 노드와 반대되는 노드는 필요하지 않는다. 상위 노드에 오류가 필요한 경우 인버터가 후속 노드를 '실패자'로 전환하기 때문이다.

➔ Repeater (반복자)

리피터(Repeater)는 하위 노드가 결과를 반환할 때마다 해당 하위 노드를 다시 처리한다. 이들은 트리를 계속해서 실행하도록 만들기 위해 주로 트리의 맨 아래에서 사용된다. 리피터는 선택적으로 하위 항목을 설정된 횟수만큼 실행한 다음 부모로 반환할 수 있다.

➔ Repeat Until Fail (실패할 때까지 반복)

리피터처럼 이 데코레이터는 계속해서 자식을 재처리한다. 이는 자식이 최종적으로 실패를 반환할 때까지 이며, 그 시점에서 리피터는 부모에게 성공을 반환한다.

---

📌 Data Context (데이터 컨텍스트)

이에 대한 세부 사항은 동작 트리의 실제 구현, 사용된 프로그래밍 언어 및 기타 모든 방식에 달려 있으므로 이 모든 것을 다소 추상적이고 개념적으로 유지하겠다.

Behaviour Tree가 AI 엔터티에서 호출될 때 데이터 컨텍스트도 생성된다. 이 데이터 컨텍스트는 노드에 의해 해석되고 변경되는 임의의 변수를 저장하는 역할을 한다. (C#의 Dictionary에서 문자열/객체 쌍을 사용하거나, Java의 HashMaep, 아마도 C++의 문자열/void*STL 맵 등을 사용할 것이다. 다만 C++을 사용한 것은 오래전이라 더 나은 처리 방법이 있을 수 있다.)

노드는 변수를 읽거나 쓰어 나중에 처리되는 노드에 컨텍스트 데이터를 제공하고 행동트리가 통합된 단위로 작동할 수 있도록 한다. 이를 적극적으로 활용하기 시작하면 Behaviour Tree의 유연성과 범위가 매우 인상적이며, 손끝에서 실제로 사용 가능한 강력함이 드러난다. 다시 문과 창문 행동을 살펴볼 때 이에 대해 자세히 알아보겠다.

➔ Entitiy & Literal

• Entity : 실체, 객체라는 의미, 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합

• Literal : 데이터(값) 그 자체를 뜻한다. 즉, 변수에 넣는 변하지 않는 데이터를 의미하는 것.
  const a = 1; (a는 상수, 1은 리터럴)

➔ Defining Leaf Nodes (리프 노드 정의)

다시 말하지만, 이에 대한 구체적인 내용은 Behaviour Tree의 실제 구현에 따라 다르다. 리프 노드에 기능을 제공하고 게임 특정 기능을 Behaviour Tree에 추가할 수 있게 하기 위해 대부분의 시스템은 구현해야 할 두 가지 함수를 가지고 있다.

• init : 노드가 처음으로 방문될 때 부모에 의해 호출된다. 예를 들어 시퀀스 노드를 처리할 차례가 될 때 이 함수를 호출한다. 부모가 처리를 완료하고 결과를 부모에게 반환한 후에 다음 번 부모 노드가 발동될 때까지 다시 호출하지 않는다. 이 함수는 노드를 초기화하고 노드가 나타내는 작업을 시작하는 데 사용된다. 우리의 걷기 예제를 사용하면 매개변수를 검색하고 경로 찾기 작업을 시작할 수도 있다.

• process : 노드가 처리되는 동안 매 틱마다 호출된다. 이 함수가 Success 또는 Failure를 반환하면 처리가 종료되고 결과가 부모에게 전달된다. Running을 반환하면 다음 틱에서 다시 처리되며, 계속해서 Success 또는 Failure를 반환할 때까지 반복된다. 걷기 예제에서는 경로 찾기가 성공하거나 실패할 때까지 Running을 반환한다.

노드는 명시적으로 리터럴 매개변수나 제어되는 AI 엔터티의 데이터 컨텍스트 내 변수에 대한 참조와 관련된 속성을 가질 수 있다.

구체적인 구현에 대해서는 언어 및 Behaviour Tree(행동 트리)에 따라 달라지므로 다루지 않겠다. 그러나 매개변수와 Behaviour Tree 인스턴스 내에서의 임의 데이터 저장이라는 개념은 꽤 범용적이다.

예를 들어, Walk 노드를 다음과 같이 설명할 수 있다.

Walk (character, destination)

• success: 목적지에 도달함
• failure: 목적지에 도달하지 못함
• running: 이동 중

이 경우 Walk에는 두 개의 매개변수가 있다. 캐릭터와 목적지이다. AI 동작을 실행하는 캐릭터가 노드의 주체이기 때문에 명시적으로 전달할 필요가 벗을 것처럼 보일 수 잇지만, 'Walk'가 꽤 안전한 선택이기는 하지만 이 가정을 하지 않는 것이 가장 좋다. 특히 조건 노드에서 다른 캐릭터의 상태를 테스트하거나 어떤 방식으로든 상호작용해야 할 때 노드를 다시 코딩해야 하는 경우가 너무 많았다. 거의 확실하더라도 동작을 실행하는 AI만 필요할 것이라고 생각된다면 명령이 적용되는 캐릭터를 추가로 전달하는 것이 항상 가장 좋다.

앞에서 언급한 대로 전달된 위치는 수동으로 x, y, z 좌료포 입력될 수 있다. 그러나 위치는 자주 다른 노드에 의해 변수로 컨텍스트에 저장되며, 게임 오브젝트나 건물의 위치를 얻거나 NPC주변의 안전한 곳을 계산할 수 있다.

➔ Stacks (스택)

Behaviour Tree를 처음 살펴볼 때, 보통 노드들을 캐릭터의 행동이나 캐릭터 또는 환경과 관련된 조건 테스트로만 제한하는 경향이 있다. 그러나 이러한 제한이 동작 트리가 얼마나 강력한지를 이해하기에는 다소 어려울 수 있다.

스택 연산을 노드로 구현하면서 노드의 유용성이 나에게 정말로 명백해졌다. 그래서 게임에 다음 노드 구현을 추가했다.

PushToStack(item, stackVar)
PopFromStack(stack, itemVar)
IsEmpty(stack)

이 세가지 노드에는 단 몇 줄의 코드로 표준 라이브러리 스택 객체를 생성하고 수정하는 데 필요한 init / process 함수만 구하면 된다. 그런데 이것으로 다양한 가능성이 열린다.

예를 들어, PushToStack은 새 스택을 생성하고 전달된 변수 이름에 저장한 다음 'item'객체를 스택에 푸시한다.

마찬가지로 pop은 스택에서 항목을 팝하고 itemVar 변수에 저장하며, 스택이 이미 비어있는 경우 실패하며 IsEmpty는 전달된 스택이 비어 있는지 확인하고 비어 있으면 성공을 반환하고 그렇지 않으면 실패를 반환한다.

이러한 노드를 사용하면 이제 다음과 같은 객체 스택을 반복할 수 있다.

Until Fail 리피터를 사용하면 스택에서 항목을 계속해서 팝하고 해당 항목에 작업을 수행할 수 있다. 스택이 비어 잇는 지점에서 PopFromStack이 실패를 반환하고 Until Fail 피리터에서 빠져나올 것이다.

그 다음으로 정기적으로 사용하는 몇 가지 중요한 유틸리티 노드들이 있다.

SetVariable(varName, object)
IsNull(object)

이들은 Composite(복합)와 Decorator(데코레이터)가 필요한 정보를 트리 상위로 가져오는 데 충분한 세분성을 제공하지 않을 때 Behaviour Tree전체에서 임의의 변수를 설정할 수 있게 한다. 잠시 후에 이와 같은 상황에 직면하게 될 것이다. 하지만 필요하지 않도록 정리할 수 있는 방법이 있다는 것은 의심하지 않는다.

이제 GetDoorStackFromBuilding 이라는 노드를 추가해 보겠다. 이 노드에는 건물 객체가 전달되며 해당 건물의 외부 문 개체 목록을 검색하여 이를 채우고 초기화한 스택에 해당 객체를 설정하는 기능이 있다. 그럼 위에서 설명한 것들을 사용하면 어떤 작업을 수행할 수 있을까?

이게 조금 복잡해진 것 같고, 처음에는 무슨 일이 일어나고 있는지 판단하기 어려워 보일 수 있지만, 어떤 언어든지 결국은 한눈에 읽기 쉬워지고 가독성을 잃더라도 유연성을 얻게 된다.

그래서 이게 무슨 일을 하는 걸까? 처음에는 복잡할 수 있지만 노드가 어떻게 작동하고 성공과 실패가 트리를 횡당하는 방식에 익숙해지면 시각화하기가 훨씬 쉬워진다. 설명이 충분하지 않다면 트리를 따라가는 것을 보여주기 위해 이 섹션을 확장할 수도 있다.

간단히 말해서, 건물의 모든 문을 검색한 다음 들어가려고 시도하고, 캐릭터가 문 중 하나라도 들어가는 데 성공하면 성공을 반환하고, 실패하면 실패를 반환하는 동작이다.

먼저 건물로 들어가는 모든 출입구가 포함된 스택을 가져온다. 그런 다음 자식이 실패를 반환할 때까지 자식을 계속 재처리하는 Until Fail 리피터 노드를 호출한다.

시퀀스인 해당 자식은 먼저 문을 팝하고 이를 door 변수에 저장한다.

문이 없기 때문에 스택이 비어 있다면, 이 노드는 Until Fail 리피터를 성공으로 간주하여 부모 시퀀스를 계속 진행한다. (Until Fail은 항상 성공으로 처리되기 때문) 부모 시퀀스에는 'usedDoor'에 대한 반전된 'IsNull' 체크가 있다. 이 체크는 'usedDoor'가 null인 경우에 실패하게 된다. 그러나 이 노드는 스택이 비어있는 상태에서 이미 Until Fall 리피터를 성공적으로 처리했기 때문에 'usedDoor' 변수를 설정할 기외가 없었다. 따라서 이 실패는 전체 동작을 실패 상태로 만들게 된다.

스택이 문을 잡는 데 성공하면, 문으로 걸어가서 문을 열고 통과하려고 시도하는 또 다른 시퀀스(인버터 포함)를 호출한다.

만약 NPC가 이용 가능한 모든 수단으로 문을 통과하지 못한다면(문이 잠겨있거나 NPC가 문을 부수기에 너무 약하다면), 선택자(Selecotor)는 실패하고 이 실패를 상위 인버터(Inverter)에 반환한다. Inverter는 이 실패를 성공으로 반전시킨다. 따라서 Until Fail 리피터에서 빠져나가지 않게 되고, 이는 반복되어 다음 문을 스택에서 꺼내어(Pop) NPC가 다음 문을 시도하는 새로운 호출을 수행한다.

만약 NPC가 문을 통과하는 데 성공한다면, 해당 문을 'usedDoor' 변수에 설정하게 되고, 이 시점에서 시퀀스는성공을 반환한다. 그러나 이 성공은 실패로 반전되어 Until Fail 리피터를 빠져나갈 수 있게 된다.

이 경우에는 null이 아니기 때문에 'UsedDoor'에 대한 IsNull 검사가 실패하게 되며, 이는 성공으로 반전되어 전체 동작이 성공적으로 처리되게 된다. 부모는 NPC가 성공적으로 문을 찾아 건물로 들어갔음을 알게 된다.

만약 프로세스가 실패한다면, 비슷한 방식으로 'GetWindowStackFromBuilding' 노드를 사용하여 창문을 대상으로 반복할 수 있다. 몇 ㄱ지 추가적인 스택 조작 노드를 사용하여 'GetDoorStackFromBuilding' 와 'GetWindowStackFromBuilding'을 연이어 호출할 수도 있다. 창문을 문 스택 끝에 추가하고 동일한 'Until Fail' 루프 내에서 이들을 처리하여 문과 창문 모두 상호작용을 시도할 수 있다. 이는 Open, Unlock, Smash, Close와 같은 작업이 문과 창문의 일반 베이스에서 동작하거나 수행 중에 작업 대상 객체에 대한 런타임 타입 체크를 수행한다고 가정한다.

마지막으로, 문을 닫는 노드에 부모로 Succeeder 데코레이터를 추가한 것에 주목할 것이다. 이는 NPC가 문을 부수면 닫는 데 실패할 것이라는 생각이 들어 추가한 것이다.

만약 Succeeder가 없다면, 'usedDoor' 변수가 설정되고 다음 문으로 이동하기 전에 시퀀스가 실패하게 된다. 또 다른 해결책은 문이 부서진 경우에도 'close Door'가 항상 성공하도록 설계하는 것이다. 그러나 우리는 문을 닫는 성공 여부를 계속해서 테스트 하고싶다. (예를 들어, 'Secure Safehouse' 동작에서는 문이 거치대에서 떨어져 나갔기 때문에 문을 닫는 데 실패한 것으로 간주됨) 따라서 Succeeder를 추가함으로써 실패가 필요한 경우 무시할 수 있도록 처리했다.

Stack & Pop

스택의 개념

• 메모리의 스택 영역은 함수의 호출과 관계되는 지역변수, 매개변수, 리턴 값등의 임시 데이터를 저장한다.

• 스택이란 단어 '차곡 차곡 쌓여진 더미'를 의미한다.

• LIFO(Last In First Out, 후입 선출) 구조 라고도 한다.

스택의 구조

• 가장 먼저 저장되는 데이터는 스택의 아래 쪽(높은 주소)부터 쌓이고, 다음 저장되는 데이터가 바로 그 위(낮은 주소)에 쌓인다.

스택에 새로운 데이터를 추가하는 것은 PUSH라고 한다.
PUSH를 하면 기존 데이터 위에 새 데이터가 순서대로 쌓아진다.

스택에 있던 데이터를 다시 빼내는 것은 POP라고 한다.

---

📌 출저

• Behaviour Tree
  AI의 행동 트리 : 작동 방식

• 스택이란?
  IT_Try tistory