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

transitionsEach 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 DesignPrevious sample implementation

may not be the most efficient design

Efficient design Encourage re-usability

Two main components in design1. Data structures used to store the

data associated with the game AI entity

2. Functions for operating transition between states

Finite State Machine DesignStructures and

Classes◦Typical to store

all game AI-related data in a structure or class

◦You can also store the current AI state (for FSM)

class AIEntity

{

public:

int type;

int state;

int row;

int column;

int health;

int strength;

int intelligence;

int magic;

};

Finite State Machine DesignUse 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

Transition functions◦Add additional

functions that determine how the AI entity should behave

class AIEntity

{

public:

int type;

int state;

int row;

int column;

int health;

int strength;

int intelligence;

int magic;

Boolean playerInRange();

int checkHealth();

};

Finite State Machine DesignIn your main game loop, constant

checking should be done to determine when to change statesif ((checkHealth()<kPoorHealth) && (playerInRange()==false))

state=kHide;

else if (checkHealth()<kPoorHealth) state=kEvade;

else if (playerInRange())

state=kAttack;

else

state=kRoam;

Finite State Machine DesignHow 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 FSMDescription 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-ImplementationStoryboarding 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 transitionsYes, 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 FSMA 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 problemsHowever, the robot can run low on power

and requires rechargingAlarm 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 FSMs1. 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