일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 선택정렬
- enumasByue
- 약참조
- 프로그래머스
- 정렬
- BFS
- dataasset
- C++
- 델리게이트
- 람다
- C++최적화
- 데이터애셋
- 언리얼가비지컬렉터
- UE4 커스텀로그
- 애셋로드
- moreeffectiveC++
- 언리얼엔진구조체
- UE_LOG
- stl
- 스마트포인터
- unorder_map
- 알고리즘
- 정렬알고리즘
- UML관련
- 크리티컬섹션
- 강참조
- 자료구조
- map
- 람다사용정렬
- UELOG
- Today
- Total
기억을 위한 기록들
[UE4] Behavior Tree에 관하여(4) - Black Board 본문
...캐릭터가 방에 진입하려할 때 어느 방에 들어가야하는지에 대한 정보의 표현이 없다면 BT를 구성할 때 레벨 상에 존재하는 모든 방을 별도의 분기로 처리해야 할 것입니다. 이건 정말 말도 안되는 비효율적인 낭비겠죠?
아시다시피 BT의 Task들은 프로그래밍 언어로 치자면 서브루틴 또는 함수로 간주할 수 있습니다. 프로그래밍 언어에서 함수에 파라미터를 집어넣어 처리하듯 BT도 이런 식으로 접근한다면 분명 효율적일 겁니다.
함수의 효율성은 단지 파라미터를 사용할 수 있다는 것 뿐 아니라, 한번 만들어 놓으면 재사용이 가능하다는 큰 장점을 지닙니다. 우리가 BT를 만들때도 마찬가지로 이러한 재사용성의 고려가 분명히 필요합니다. 잘못된 Data의 사용은 직관적이고 단순하게 표현할 수 있는 BT의 큰 장점을 한 순간에 무너트릴 수 있습니다. 하지만 Task 내에 Data를 선언하게 되면 필연적으로 이런 문제가 생기고 맙니다.
이를 해결할 수 있는 좋은 방법은 Task들과 Data를 분리하는 것입니다.
BT가 필요한 Data를 외부에서 따로 선언하고 관리함으로서 이러한 독립성을 유지할 수 있습니다. 이렇게하면 BT의 각 Task들은 Data가 필요할 때 이를 질의(query)해서 들고 오거나, 쓰면(write) 깔끔히 해결이 됩니다.(이건 Design Pattern에서 객체와 객체 간의 상호작용은 구성(Composite)을 사용하는게 좋다라는 철학과 약간 비슷한 것 같습니다. 즉 필요한 Data는 별도로 캡슐화해서 독립성을 보장하는 거죠.)
이러한 사유로 BT에서는 Data를 별도로 관리하게 되는데 이곳을 Blackboard라고 부릅니다.
(Blackboard는 원래 BT와 별도로 존재하는 개념인데(흔히 Blackboard Architecture로 알려져있습니다.), BT에서 이 개념을 들고 왔습니다. 차후 여건이 되면 Blackboard 자체에 대한 개념을 이론적으로 다뤄보도록 하겠습니다.)
이상 간단하게 Blackboard가 무엇이고 등장하게 된 배경에 대해 살펴 보았습니다.
'UnrealEngine > UE- BehaviorTree' 카테고리의 다른 글
[UE4] Behavior Tree에 관하여(3) - Service (0) | 2022.03.27 |
---|---|
[UE4] Behavior Tree에 관하여(2)- Task / Decorator (0) | 2022.03.27 |
[UE4] Behavior Tree에 관하여(1)- Composites(Sequence/Selector/Simple Parallel) (0) | 2022.03.27 |