Game Development Reference
In-Depth Information
function DecisionTreeBrain:Think()
return self._root:Decide();
end
This class implements the
TeapotBrain
class. The
Init()
function calls a private
_BuildDecisionTree()
function. My version of this function (which you can see
in the GameCode4 source code at Dev\Assets\Scripts\DecisionTreeBain.lua) manually
creates the tree you saw in Figure 18.3. In a real game, this would load an XML
resource and build the tree from that. You
'
ve seen XML used quite a bit in this
book, and there are plenty of examples all over the place in the actor system and
the game editor you
'
ll see in Chapter 22,
“
A Simple Game Editor in C#.
”
I leave
this as an exercise for you.
The
Think()
function of
DecisionTreeBrain
simply calls the root nodes
Decide()
function and returns the results. This function starts the chain of recursion to find the
appropriate state to be in.
Decision trees are extremely useful. The example here is trivial, but it could easily be
expanded into dozens or even hundreds of nodes. The tree is still relatively efficient,
since whole chunks of the decision-making process are culled with each decision.
Assuming a perfectly balanced tree, each decision will cut the possible decisions in
half.
Even if you
re processing hundreds of nodes, the nature of the tree structure means
you can easily make the decision across multiple frames. At each step, you check to
see how much time has passed. If the decision is taking too long, you simply save the
current node and return. The next time, the decision-making process can be picked
up at the last node. Just be careful with this; the decisions already made may no lon-
ger be valid. As long as the decision doesn
'
'
t take more than a couple of frames, this is
rarely a problem. You just have to validate the final result at the end. Attempting to
grab a pickup may not be the right decision if the pickup is no longer there.
The decision tree shown here is a binary decision tree where each decision node
results in a yes or no answer that determines where to go next. It
s perfectly valid
to have nonbinary decision trees. You could have a node with multiple children
based on a range of values. For example, the
IsHealthLowNode
class could be
changed into a
ProcessHealthNode
class that has three different children. If their
health were low, the AI could find health or run away. If their health were especially
high, they could be much more aggressive. If their health were in the middle some-
where, they could act normally.
'
