Tuesday, August 14, 2012

Behavior Trees

The general design in Unity is to write multiple behavior scripts, and attach them to a game object.  For example, a "rotate" script and a "shoot-at-anything-that-gets-close" script are attached to an object separately, rather than combining all behaviors into one script.

I like this approach - until an object needs to only apply behaviors selectively.  At that point I realized a finite state machine (FSM) was probably the way to go.  If an object had several scripts attached to it, there would need to be an FSM script which messaged all the other scripts so they knew what state the object was in.  Ugly.

Fine - ask Dr. Google.

People are still using FSMs out there - but the new glorious technology now seems to be Behavior Trees (BT).

I'm just beginning to teach myself about this tool.  There is some comparison between BT and hierarchical finite state machines (HFSM) - the latter which I have no experience with.

An FSM will go from state to state with transition events, and have the capacity to become a fascinating conversation piece among the more super-genius programmers spaghetti nightmare.  Even very simple FSMs can be painful to look at.

BT appears to remove some of the FSM free-form.  They seem to provide a framework of limited logic-flow.  It makes me wonder if eventually processors will be optimized around BT - because it looks like a sort of graphical programming language.  More importantly, it looks like a new way of thinking and building engines.

Here is the best summary page I've found so far (and an excellent blog overall on the subject):

http://aigamedev.com/open/articles/popular-behavior-tree-design/