Finite State Machine, 유한 상태 기계
유한한 개수의 상태들로 구성된 하나의 간단한 기계
캐릭터의 행동을 각 상태로 모듈화.
캐릭터의 행동 추가/삭제에 대해 어느 정도 유연함을 가지고 있는 편
하지만 State를 나누기가, Transition을 리와이어링 하기가 매우 어렵다. (State가 늘어나면 늘어날수록!)
확장이 제한된다.
HFSM(Hierarchical Finite State Machine)을 사용하여 문제점을 보완할 수 있지만 유지 보수 코스트는 여전히 높다.
콘솔 게임에서는 온라인 게임보다 AI가 훨씬 더 중요한 요소 -> FSM이 부적합
출처 : https://www.slideshare.net/yonghakim900/2009-ndc
Blackboard를 사용하는 이유
1) 효율적인 Event-Driven 동작을 만들기 위해
: Blackboard를 변경하면 값을 확인하기 위해 모든 프레임을 업데이트할 필요 없이 BT의 흐름을 변경하는 이벤트가 발생할 수 있다.
2) To Cache Calculations
: 계산 되어야하는 일부 데이터들은 반복해야 하거나 단순히 성능 면에서 비용이 많이 들 수 있다. 따라서 BT 전체에서 사용할 수 있도록 계산된 값을 Cache하여 반복하여 다시 계산할 필요가 없도록 하는 것이 좋다.
그렇게 한다면 값을 계산하는 빈도가 낮아지고 오류 발생률도 낮아진다. 데이터를 두 곳 이상에서 재계산할 경우 실수로 다르게 계산될 수 있다.
3) As a scratch-pad for behaviors
: BT에서 사용해야 하는 일부 데이터에는 다른 명확한 home이 없다.
예를 들어 시퀀스를 시작할 때 BT의 다른 부분이 시퀀스에 끼어들지 않도록 시퀀스를 시작했음을 note하고 싶을 수 있다. 그러나 이 순서는 이미 어딘가에 저장되어 있는 특정 클래스나 지식과 쉽게 동일하지 않을 수 있다. 이 경우 Context Override*를 사용하여 값을 설정 및 clear할 수 있다.
4) 데이터 집중화
: Blackboard는 데이터를 중앙 집중화하고 데이터의 출처에 대한 추가 지식이 필요하지 않은 좋은 방법이다. Blackboard가 없으면 다양한 클래스에 저장된 정보를 쿼리하기 위해 여러 단계를 거쳐야 하는 경우가 많다.
모든 것을 Blackboard에 복사하지 않는 이유
데이터를 Blackboard에 제대로 복사하지 못하면 디버깅 악몽이 생길 수 있다! 값을 소스만 또는 Blackboard만 보고 있는 경우, 두 값이 다를때 문제가 발생하고 있음을 즉시 깨닫지 못할 수 있다.
충분한 값을 자주 업데이트하여 Blackboard에 계속 복사해야 하는 경우 성능이 저하될 수 있다.
출처 : https://forums.unrealengine.com/t/blackboard-documentation/1795