Dr Nick Mitchell (Room CM 224) CO1301: Games pts 2015 Lecture 5 Finite State Machines Dr Nick Mitchell (Room CM 224) email: npmitchell@uclan.ac.uk

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.

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 Collision Timer Resurrect Start

Pac-Man: Player Character (simplified) Hunted Hunter Dying Power Pill Timer 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...

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

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.

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

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