Finite State Machines
Finite State Machines (FSMs)
An abstract machine that can exist in one
of several different and predefined states
 Defines a set of conditions that
determine when the state should change
 State defines the behaviors to be
executed

Finite State Machines (FSMs)

Long history of involvement in game AI
◦ Ghosts in Pac Man are FSMs
 Ghosts can roam freely, chase player, evade player
 The transition between these behaviors are
determined by the player’s actions

Even today, FSMs are still very commonly
used
◦ Easy to understand, implement, debug
◦ Lightweight and efficient
Basic State Machine Model

A generic FSM diagram:
◦ ‘S’ nodes are states, ‘t’ arrows are transitions

Each FSM typically models a set of
behaviors for a character or group of
characters
Basic State Machine Model
4 possible states {Si, S1, S2, S3}
 Transition functions {t1,t2, t3,t4, t5}
 Initial state  Si , remains in this state
until t1 provides a stimulus to switch to
S1

‘Pac Man Ghost’ FSM
3 possible states: Roam, Chase, Evade
 Transitions include conditions for
remaining in a same state

‘Pac Man Ghost’ FSM
Finite State Machine Design
Previous sample implementation may not
be the most efficient design
 Efficient design  Encourage re-usability
 Two main components in design

1. Data structures used to store the data
associated with the game AI entity
2. Functions for operating transition between
states
Finite State Machine Design

Structures and
Classes
class AIEntity
{
◦ Typical to store all
game AI-related
data in a structure
or class
◦ You can also store
the current AI
state (for FSM)
public:
int type;
int state;
int row;
int column;
int health;
int strength;
int intelligence;
int magic;
};
Finite State Machine Design

Use some global
constants to define
the states (which are
in integers)
#define kRoam 1
#define kEvade 2
#define kAttack 3
#define kHide 4
Finite State Machine Design

class AIEntity
Transition functions {
◦ Add additional
functions that
determine how the
AI entity should
behave
public:
int type;
int state;
int row;
int column;
int health;
int strength;
int intelligence;
int magic;
Boolean playerInRange();
int checkHealth();
};
Finite State Machine Design

In your main game loop, constant
checking should be done to determine
when to change states
if ((checkHealth()<kPoorHealth) &&
(playerInRange()==false))
state=kHide;
else if (checkHealth()<kPoorHealth)
state=kEvade;
else if (playerInRange())
state=kAttack;
else
state=kRoam;
Finite State Machine Design

How would the original FSM diagram
looked like for this example behavior?
if ((checkHealth()<kPoorHealth) &&
(playerInRange()==false))
state=kHide;
else if (checkHealth()<kPoorHealth)
state=kEvade;
else if (playerInRange())
state=kAttack;
else
state=kRoam;
Example: Ant FSM

Description of Ant AI
◦ First, the ants will move randomly in their environment in an
attempt to locate a piece of food. Once an ant finds a piece
of food, it will return to its home position. When it arrives
home, it will drop its food and then start a new search for
water rather than food. The thirsty ants will roam randomly
in search of water. Once an ant finds water, it will resume its
search for more food.
◦ Returning food to the home position also will result in a new
ant emerging from the home position. The ant population will
continue to grow so long as more food is returned to the
home position. Of course, the ants will encounter obstacles
along the way. In addition to the randomly placed food will be
randomly placed poison. Naturally, the poison has a fatal
effect on the ants.

Can you summarize the behavior in an
FSM?
Example: Ant FSM
AI Design-to-Implementation
Storyboarding  Character Design  AI
Design (FSM)  AI Implementation
 FSMs can model behaviors very easily, but
much more work needs to be done
earlier for character design
 Can we use one generic FSM to model
the behavior of a few types of AI
characters?

Re-using one generic FSM?
No, if your AI characters require different
set of states and transitions
 Yes, if they have the same set of states
and transitions, but different condition
variables

◦ E.g. A stronger and matured ant and a junior
ant might have the same behaviors (states,
transitions) but different requirements for
finding food/water, or different resistance
levels towards poison.
Limitations of a single FSM

A single FSM can have limitations in
expressing some behaviors.
◦ A common source of difficulty is “alarm
behaviors”, or behaviors that require the AI
character to do something urgently at any
given state, and to resume back the state later

Can you think of a scenario where this
might happen?
Example: Cleaning Robot AI



Single FSM operates with no problems
However, the robot can run low on power and
requires recharging
Alarm mechanism: Interrupting the normal behavior
to respond to something else important
Example: Cleaning Robot AI
Adding “Get Power” state to accommodate the
alarm mechanism is not difficult  but number
of states increase about x2
 What if we have a “Hide” alarm that is another
alarm behavior?

Example: Cleaning Robot AI
So, rather than combining all the logic into a
single FSM, we can separate into several FSMs,
arranged in a hierarchy
 Higher levels of hierarchy can respond to alarm
behaviors

Hierarchical State Machine
Higher level: Operates the alarm behavior (to
get power)
 Lower level (within the Clean Up mother state):
Operates the cleaning up behavior

Hierarchical State Machine

H* state: “History state” that indicates which
sub-state (in lower level) should be entered
(initially) or resumed (if just returned from the
higher level)
Hierarchical State Machine
It is possible to implement both FSMs
separately, but a lot of switching between the
two is required  implementation inefficiency
 Nested hierarchy: We are in more than one
state at a time (on different levels), just keep
track of multiple levels of states

Cross Hierarchical Transition
If the robot has no objects to collect (of found
nothing useful), makes sense to go back to
charging bay rather than wasting power
 Transition from lower level state to a higher
level state – Lower level FSM is reset, with no
history record

Weaknesses of FSMs
1.
Rigid modeling of behaviors
◦ Each character can only have one state at a
time – straightforward but limited
2.
Complex transition conditions can affect
efficiency
◦ …if many conditions need to be checked
3.
Behaviors are deterministic
◦ Designer pre-determines the actions and
behaviors of the character, unlikely for it to
respond out side what it was designed to
Addressing them…
1.
Rigid modeling of behaviors
◦ Modeling multiple states in a nested hierarchy
might help to construct more complex
behaviors
2.
Complex transition conditions can affect
efficiency
◦ Use decision trees in the transitions
3.
Behaviors are deterministic
◦ Apply fuzzy logic to the transitions