Game Development Reference
In-Depth Information
part of the high-level state's update function. Subtleties within the high-level
state are handled by the low-level state machine. If our monster is a fire-breathing
dragon, the Attack high-level state might have a few low-level states, such as a
Close state in which the dragon charges and breathes fire on far-away targets.
When the dragon gets near, it would switch to a Combat state, where it wants to
avoid breathing on itself and instead employs claws and teeth. Likewise, the high-
level Flee state might involve two low-level states: Running and then Flying. With
hierarchical FSMs, the low-level machines from one state have no outside
interaction with any of the other low-level FSMs.
Transition Explosion
Transitions can grow in number and complexity. If an FSM design suffers from
state explosion, a far worse transition explosion almost always follows. One
characteristic of a good FSM is that the states have mostly local, rather than
global, transitions. Hierarchical FSM machines enforce this good trait, but reg-
ular FSMs benefit from it as well. Any given state has transitions to a small subset
of all of the states. In pictorial form, the FSM resembles a flat mesh with few lines
crossing. Without this locality, state growth may be manageable, but the tran-
sition growth may not. Ask yourself, ''If I add this state, how many existing states
will have to connect to it?'' If the answer is all (or nearly all) of them, it indicates
potential problems. If the answer is a few of them, it is a good sign. Recall from
the complexity discussion that the number of possible transitions grows much
more quickly than the number of states.
Another characteristic of a good FSM is that the transitions are simple. ''Simple''
here means that of all the data that gets evaluated by all the transitions, a given
transition only depends on a few of those items. Disambiguation methods deal
with the problem of multiple valid transitions. If the disambiguation methods are
inadequate, the complexity of the transitions grows with the number of data
items touched by all transitions. When adding a new transition or changing an
existing one, ask, ''How many transitions need to be updated to consider this
new data item?'' If the answer is only a few, your disambiguation is solid. If the
answer is all (or nearly all) of them, your machine is not effectively exploiting
what are called ''don't care'' conditions. (The ''don't care'' conditions are all the
things that can safely be ignored when evaluating a particular transition. Clever
disambiguation simplifies important factors of an evaluation into don't care
conditions. For example, in our monster AI, the High Health transition from the
Flee state to the Attack state cares about health, but the No Players transition
 
Search Nedrilad ::




Custom Search