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  :QQ
• Various possibilities for output
• In practice, more relaxed FSMs are used
Example
b
a
q0
b
q1
a, b
a
q2
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
Monster in sight
Gather Treasure
Flee
No monster
Fight
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
Monster in sight
• Better modularity
Gather Treasure
Flee
No monster
Find
treasure
Go to
treasure
Take
treasure
Fight
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
Hide
Patrol
Attack
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
Robot Hit
Default
State
Robot
Scanned
Wall Hit
Bullet
Scanned
…
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
Monster in sight
&
AggressionLevel<0.5
Gather Treasure
Flee
No monster
Fight
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
Monster in sight (0.3)
Gather Treasure
Flee
No monster
Fight
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?
Example
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);
}
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
Example
BeginStateMachine
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
Monster in sight
Gather Treasure
Data
Flee
No monster
Generated Code
(output)
Fight
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);
}
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