1. Dr Nick Mitchell (Room CM 224)
CO1301: Games pts 2015
Lecture 5
Finite State Machines
Dr Nick Mitchell (Room CM 224)

2. References
Rabin, Introduction to Game Development, chapter 5.3 discusses Finite State Machines in the context of AI.

3. 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

4. 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.

5. 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

6. Pac-Man: NPC Ghost (simplified)
Hunter
Hunted
Eaten
Power Pill
Collision
Timer
Resurrect
Start

7. Pac-Man: Player Character (simplified)
Hunted
Hunter
Dying
Power Pill
Timer
Collision
If lives > 0
Start

8. 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…

9. 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.

10. 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.

11. 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.

12. 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)

13. 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...

14. Basic UML STD notation
State machines are visualised in UML as State Transition diagrams (STDs).
Before creation
Transition
Event causing a state change
Event not causing a state change
Entity destroyed
State showing action performed on entry
Action performed by entity on transition
State
Action
Event 1 / Action
Event 3
Event 2
Start State
End State

15. 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 the boxes show “processing” happening.

16. 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
Left
Right
Reach left limit / change skin
Reach right limit / change skin

17. 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.

18. 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.
Example:
if (sphere->GetX() > rightLimit) {
sphereDirection = Left;
sphere->setSkin(“newSkin.jpg”); }
This is a simple example - Note that the transition may be dependent on the current state.
Event causing a state change
Transition to a new state
Action takes place

19. 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);
Appropriate behaviour
Test to determine current state

20. 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.)