Game Development Reference
the most,'' yielding an appropriate number of levels in the diagram. In an FSM,
the partitioning is done once; in a behavior tree, it is done as many times as
needed. Superior partitioning localizes concerns better . Graphically, this can be
seen if the nodes in a behavior tree have few links and the states in an FSM have
many transitions. In addition, behavior trees do not loop.
Like all divide-and-conquer methods, great pains must be taken in the divide. If
the divide is not clean, then the conquer is unlikely to succeed. The divide step is
also a good time to evaluate which method to use. If your tree has minimal levels
and a relatively broad base, an FSM or a hierarchical FSM might be the optimal
solution. If your tree has much depth or is uneven, with broad parts here and
deep parts there, a behavior tree may be best.
Throughout the discussion, we have tied behavior trees to diagrams. Non-
graphical methods of specifying a tree or an FSM may detract from the clarity of
the design, but decisions about what AI algorithm you use should be made
holistically. Tool support may have a strong influence on those decisions; the
Spore developers described their particular way of defining their behavior tree as
''fairly self-documenting'' while at the same time having ''the side benefit of
compiling extremely rapidly'' [Hecker07]. Implicit in that statement is the idea
that their design definition was used to generate code, avoiding any disconnect
between the design and the code at the potential price of a design that was harder
for people to deal with.
The sophisticated behavior selection available does a very good job at handling
AI that thinks in terms of ''What should I be doing right now?'' Whether we
evaluate in the typical top-down or the more expensive bottom-up sequence, we
arrive at a single thing that the AI should be doing. This is predicated on a
fundamental question to ask before considering a behavior tree for your AI: ''Can
I make high-level decisions or categorizations at all?'' Along with that is the
question of whether doing just one thing is appropriate.
The benefits to behavior trees come from the fact that they control complexity. If
your tree starts with a single root and then explodes immediately into a large
number of leaves, you have lost the simplifying power of the method. Put another
way, you need to ask, ''Can I effectively organize the AI behaviors into a hier-
archy?'' If there is no benefit to the hierarchy, perhaps another method would be
better. If you cannot because you need to string a bunch of behaviors together, a
planning architecture may be what you need.