Finite State Machines

Stanislav Tsanev

Outline

• Introduction, definition

• Extensions/Deviations

• Implementation

FSMs in Game Programming

• “[FSMs] are without a doubt the most commonly used technology in game AI programming today. They are conceptually simple, efficient, easily extensible, and yet powerful enough to handle a wide variety of situations.” (Fu&Houlette)

• “[Finite] state machines are widely used because they poses some amazing qualities. They are easy to program, easy to comprehend, easy to debug, and completely general to any problem.” (Rabin)

Game AI Uses

• Used to control the behavior of different game elements (monsters, etc.)

• Small number of states representing the state of the element

• State changes usually based on a small set of external events

• Actions associated with either states or transitions

• Used at design time and in code

Finite State Machines

• Mathematical formalism from theoretical computer science (CSE 318, 409)

• Finite set of states Q• Finite input alphabet Σ• Transition function• Various possibilities for output• In practice, more relaxed FSMs are used

QQ :

Example

q0 q1 q2

a

b

b

a

a, b

FSMs in Practice

• Actions take place either in states or at transitions or both

• Inputs are other aspects of game world

• Often complicated computations necessary to determine transitions

• Can have variables in addition to the state

• Many extensions and variations

Example

Gather Treasure Flee

Fight

Monster in sight

No monster

Cor

nere

d

Monster dead

From Fu&Houlette

Extending States

• Add actions to be executed when an FSM first transitions to a state or when it leaves a state

• Can be emulated with more states

Hierarchical FSM

• Each state consists of sub-states

• Better modularityGather Treasure Flee

Fight

Monster in sight

No monster

Cor

nere

d

Monster dead

Find treasure

Take treasure

Go to treasure

Stack FSM

• Extension of the “pushdown automata” from CSE 318

• Stack provides additional memory• Can be used to remember state history (push)• Can return to previous state (pop)• Or enter a new state entirely and forget about the

old one (replace).

Example

Patrol Hide

Attack

See enemy See enemy

Stack

Attack

Patrol

Message-Passing FSM

• Event-driven

• Integration with other FSMs or game engine

• Messages are enums

• Used to notify of external change of the world

Example

Default State

Robot Scanned

Wall Hit

Bullet Scanned

Robot Hit

…

Polymorphic FSM

• Even minor changes in one FSM can introduce the need of changes in other FSMs

• Use polymorphic FSMs instead

• Achieves different behaviors

• Parameterize key behavior aspects

• Code reuse, flexibility

Example

Gather Treasure Flee

Fight

Monster in sight &

AggressionLevel<0.5

No monster

Cor

nere

d

Monster dead

Monster in sight

&

AggressionLevel>0.5

Fuzzy State Machines

• Based on Fuzzy Logic, where truth values are real numbers between 0 and 1

• Multiple states at the same time with varying degrees of presence

• Not widely used in game AI

Probabilistic FSMs

• Transition function is stochastic

• (meaning which state to go to next is determined “randomly”)

• Adds element of chance, achieves more varied behavior

Example

Gather Treasure Flee

Fight

Monster in sight (0.3)

No monster

Cor

nere

d

Monster deadMonster in sight (0.7)

Implementation

• Development Environment/Tools

• Integration within the game

• Interface to the rest of the game

Representing FSMs with Standard Programming Languages

• Plain/native code (C++/Java)• No need for specialized tools• Various degrees of abstraction/ encapsulation:

– FSM– State– Transition– Action– Condition– Etc.

• Can become hard to maintain/debug• Where do actions go?• When does the state transition take place?

Examplevoid RunLogic(FSM * fsm)

{

int input = 0;

switch(fsm->getStateID())

{

case 0: //GatherTreasure

GatherTreasure();

if (SeeEnemy()) input = SEE_ENEMY;

break;

case 1: //Flee

Flee();

if(Cornered()) input = CORNERED;

if(!SeeEnemy()) input = NO_ENEMY;

break;

case 2: //Fight

Fight();

if(MonsterDead()) input = MONSTER_DEAD;

break;

}

fsm->stateTransition(input);

}

Using an FSM Language

• For instance, using preprocessor macros (C++)

• More readable

• More structured

• Easier to write and debug

• Introduces a minimum of new key words

• Need to make decisions about those

ExampleBeginStateMachine

State(0)

OnUpdate

GatherTreasure();

if(SeeEnemy()) SetState(1);

State(1)

OnUpdate

Flee();

if(Cornered()) SetState(2);

if(!SeeEnemy) SetState(1);

State(2)

OnUpdate

Fight();

if(MonsterDead()) SetState(0);

EndStateMachine

Data-Driven FSM

• Create a specialized scripting language (will covered in next class) or GUI tool

• Easier for non-developers to understand• Helps in design• Relies on translation rules and other data to

interface the game• Can compile either to C++/machine code or

be interpreted• Big overhead in creating tools

Example

Gather Treasure Flee

Fight

Monster in sight

No monster

Cor

nere

d

Monster dead

GUI Tool(user input)

void RunLogic(FSM * fsm)

{

int input = 0;

switch(fsm->getStateID())

{

case 0: //GatherTreasure

GatherTreasure();

if (SeeEnemy()) input = SEE_ENEMY;

break;

case 1: //Flee

Flee();

if(Cornered()) input = CORNERED;

if(!SeeEnemy()) input = NO_ENEMY;

break;

case 2: //Fight

Fight();

if(MonsterDead()) input = MONSTER_DEAD;

break;

}

fsm->stateTransition(input);

}

Generated Code(output)

Data

Polling Implementation

• FSM logic executes on fixed interval– Either certain number of frames/ticks or on

timer

• Very easy to implement

• Potentially a lot of useless computation

Event-Driven Implementation

• Implement broadcast-subscribe paradigm

• Each FSM subscribes to events of interest

• Recalculation only when event is received

• Need to make decisions about granularity, what events to make available

• Far more efficient than polling

• Infrastructure cost

Multithreaded implementation

• Each FSM runs in a separate thread parallel to the game engine

• Concurrent communication

• Continuous updates

• Synchronization, etc., considerations

• This is the one used in Robocode

Interfacing options

• Need to interface the rest of the game to receive inputs and to perform actions

• Hard-code each action as a separate function

• Maintain an array of function pointers

• Invoke functions by name

Summary

• FSMs are a powerful technique for encapsulating behavior logic

• Many extensions exist• Can be coded directly or with the help of

specialized languages or GUI tools• Can be polled, event driven, or run in parallel• Can interface the engine by directly calling its

functions, by function pointers, or by dynamically invoking methods