Game Development Reference
In-Depth Information
U SING N UMBERS TO S ELECT
The finite state machine (FSM) depicted in Figure 3.1 is an example of something
that is often seen in games. This sort of linearity of action is evident—and even
common—in the most rudimentary game AI. For instance, an enemy in a first-person
shooter (FPS) or a role-playing game (RPG) may start out in an idle state. Once a
criteria is established, such as the player entering a certain radius, the enemy
changes to an approach state. This is similar to the transition from state A to state
B in Figure 3.1. There is no other option. If the player doesn't approach, state B is
never entered. Continuing on, once the player is within range, the enemy may
switch to state C, attack. If it never reaches the player, there is no other option; it
stays in state B. Likewise, state D could represent “die,� the transition triggered by
its health reaching zero. If the health never reaches zero, it doesn't die (and keeps
attacking). There's not a lot of AI going on here.
FIGURE 3.1
A very simple FSM with one static transition to and from each state.
The fault is not in the FSM, itself, however. After all, a state machine is a tool.
As simply a tool, there is very little depth to it. In fact, with the assumption that sim-
ple logical triggers are behind the transitions (the arrows in Figure 3.1) from one
state to the next, there is an implication of rigid predictability. If you know those
transition cases, you know the next state. In the case of the FPS enemy, eventually
a player will figure out that entering a certain radius triggers the transition from idle
to approach. There is no variation whatsoever, and, accordingly, there is not a lot
of drama. It is reminiscent of the predictability of Tic-Tac-Toe. “If the player can
win next turn, block his movement.�
By comparison, the state machine in Figure 3.2 provides something subtly
different. While there are four states, just as in the one in Figure 3.1, state A can
 
 
Search WWH ::




Custom Search