CO1301: Games
pts 2015
Lecture 5
Finite State Machines
Dr Nick Mitchell (Room CM 224)
email: [email protected]
References
 Rabin, Introduction to Game Development, chapter 5.3
discusses Finite State Machines in the context of AI.
States
In the labs, I have informally introduced the idea of
using states to model behaviour of objects in the
game, or even the game itself.
Whilst getting some practical experience of
working with states we shall briefly look at some of
the theory.
States are a commonly used approach in computing.
It is possible to express the “rules” for how the
game progresses on State Transition Diagrams.
They are an excellent design tool to help
understand what it is you are going to program
before you hit the keyboard
The State Model
 We can view all kinds of entities as having a number of
possible states.
 Think of a light switch – its state can be on or off.
 Events trigger the transition from one state to another.
 Pressing the switch turns it on or off.
 In transitioning from one state to another, an entity
might also perform an action.
 Certain actions cause an event to happen for another
entity.
 Turning on too many lights at once might cause the
fuse to blow.
 The purpose of modelling state-behaviour is to capture
and enforce the “business rules” of entities in the game.
4
Usefulness of States for Games
States help us express complex behaviour or activity.
 Example: Pac-Man
A
simple state model for NPCs (ghosts) controls
their behaviour.
 Changes in behaviour are triggered externally.
 Player swallows a power pill (event)
 Ghosts’ behaviour changes (transition) to a
different state (from Hunter to Prey).
 Further events will have different outcomes
according to the current state
 For example, when player and ghost collide
http://www.youtube.com/watch?v=uswzriFIf_k
Pac-Man: NPC Ghost (simplified)
Power Pill
Power Pill
Hunted
Collision
Hunter
Start
Timer
Resurrect
Eaten
Pac-Man: Player Character (simplified)
Power Pill
Power Pill
Hunter
Timer
Hunted
Collision
Start
Dying
If lives > 0
State Machines
 A complete model of the life-cycle of an entity like this is
called a “state machine”.
 A state is a unique set of properties.
 Particular behaviour will be executed in response to
particular input when in a given state.
 State
 Input (event)
 Response (action and/or transition to a new state)
 In combination they form a unique configuration, this
particular state with this particular input will lead to that
particular outcome.
 E.g. collision between Ghost and Pac-Man has different
outcomes in different states…
Why are states used?
 States describe the game extremely well.
 You are able to understand this aspect of the game
mechanics.
 State Machines are flexible but also extremely powerful.
 A good way to implement the mechanics of a game (and
other types of software).
 It is easy to store the states of entities as variables:
 One part of the program can respond to events by
updating the values of the state variables;
 Another part of the program will decide how entities
should behave according to those state values.
Why are states used?
Aesthetically pleasing.
The player experiences smooth game-play.
Unobtrusive.
 Typically
a player will not perceive the existence of
the state machine.
 Even if it is the case that they do, state machines are
accepted approach.
Also used extensively in AI. You may look at this again
(along with other AI techniques) next year.
Can provide strong signals to the player, i.e. what has
happened, what to do next, etc.
Multiple State Machines
A program may have many different state machines.
There may be state machines for the player
character and different non-player characters.
Each of these things can be considered an object
(or entity) within the program. This approach
allows us to easily describe (and therefore
implement) the life cycle of an individual object.
The game itself may have an overall state machine.
Pac-Man example re-visited
 For the one of the Ghost NPCs:
 In
Hunter state
 Ghost will move towards Player (behaviour)
 Collision (event) will cause (action) Player to die
 (on Player’s STD as event causing transition)
 In Hunted state
 Ghost will move away from player (behaviour)
 Collision (same event – different effect) will cause
Ghost to be eaten (transition to new state) and
turn into a pair of eyes (action)
 In the Eaten state
 Ghost will move towards home area (behaviour)
 Arrival at home (event) will resurrect Ghost
(transition and action)
Interacting State Machines
There is interplay between the states of different
entities within the game:
An action performed by one entity may be
regarded as an event for another entity.
This insight leads on to aspects of Unified Modelling
Language – UML
You have seen some UML already with Lesley
Used to support a design method used for
Object Oriented Programming.
You will see lots of this in CO2401 next year...
Basic UML STD notation
 State machines are visualised in UML as State
Transition diagrams (STDs).
Event causing a
state change
Action
performed
by entity on
transition
Event 1 / Action
Start State
Before
creation
Transition
State
Action
Event not causing
a state change
Entity
destroyed
Event 2
Event 3
End State
State showing
action performed
on entry
14
State Transition Diagrams are NOT
Flow Charts (or Activity Diagrams)!
 State charts and Flow charts show quite different things.
A
flow chart is a way of modelling a business process.
 In UML this is done with an activity diagram.
 STDs are not algorithmic in the same way.
 The important thing to remember is that the EVENTS
take place when the system is doing (or has done)
something.
 Depending on the system, you can sometimes think of
it as “resting” when it has arrived in any given state.
 The names you choose for states should reflect
this…
 This is the opposite of flow or activity diagrams, where
15
the boxes show “processing” happening.
STDs as a Code design tool
 It is a good idea to draw STDs to help you understand
how entities will behave BEFORE you start coding.
 The state of an entity can be captures as a variable
 The possible values of the variable represent the
different possible states.
 These can be taken straight from the diagram.
 Example: A sphere moving left and right between limits
Reach left limit / change skin
Left
Right
Reach right limit /
change skin
Enumerated types in C++
 enums are an elegant way to define values for states.
 The enum defines a new type, along with the possible
values which can be assigned to variables of that type.
enum DirectionState {Right, Left, Up, Down};
 In the same way we can declare an int called foo with
the value 5, we can declare variables of the new type.
Int foo = 5;
DirectionState sphereDirection = Right;
Type
Name
Value
 The value of the variable is the current state.
Implementing STDs Faithfully
 Events cause state transitions and actions.
 Code is needed to detect events
 An
event could be a key press, a collision, a
counter reaching a certain value, etc, etc.
Event causing a
 Example:
if (sphere->GetX() > rightLimit)
{
sphereDirection = Left;
sphere->setSkin(“newSkin.jpg”);
}
state change
Transition to
a new state
Action takes
place
 This is a simple example - Note that the transition
may be dependent on the current state.
Behaviour according to State
 Once you have a state variable, it is easy to see what
state the game/entity is in.
 Behaviour and transitions are determined by the state.
if (sphereDirection == Right)
{
sphere->MoveX(speed);
sphere->RotateZ(rotation);
}
else if (sphereDirection == Left)
{
sphere->MoveX(-speed);
sphere->RotateZ(-rotation);
}
Test to
determine
current state
Appropriate
behaviour
Example outline structure of code
Setup section:
Define state variables (and initial states)
Game loop section:
Detect events
update state variables
perform transition actions
Check state
behave appropriately (e.g. Move objects etc.)