CO1301: Games pts 2015

Dr Nick Mitchell (Room CM 224)email: npmitchell@uclan.ac.uk

Lecture 5Finite State Machines

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

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.

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)

Hunter

Hunted

Eaten

Power Pill

CollisionTimer

Power Pill

ResurrectStart

Pac-Man: Player Character (simplified)

Hunted

Hunter

Dying

Power Pill

Timer

Power Pill

Collision

If lives > 0

Start

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

State machines are visualised in UML as State Transition diagrams (STDs).

14

Basic UML STD notation

StateAction

Event 1 / Action

Event 3

Event 2

Start State

End State

Before creation

Transition

Event causing a

state change

Event not causing a state

change

Entity destroye

d

State showing action

performed on entry

Action performed

by entity on transition

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

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

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;

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

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 changeTransition

to a new state

Action takes place

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

Example outline structure of codeSetup section:

Define state variables (and initial states)

Game loop section:Detect events update state variablesperform transition actions

Check statebehave appropriately (e.g. Move objects etc.)