But this post is not about complex patterns. It’s about a very simple one; The first one I learned that used several classes as well as interfaces. Somewhat infamously at this point, I’m notoriously fond of interfaces and the freedom they offer the developer -which is ironic, because they are about limitations and requirements- and if you want to trace that love to its inception, the “finite state machine” is it.
What is a state machine?
A state machine is a complex (but cool sounding) term for an object that can be in one of a limited selection of states. The typical example is the light switch: It can be in two states; on or off. The light-bulb can be lit or dark. The power can be up or down. Maybe you have poor wiring; the power can be fluctuating as well, a third state. In fact, as a Flash developer, you have probably been working with states and finite state machines ever since you first started playing around with the Flash IDE. MovieClips are nothing but state machines where every frame is a state. A MovieClip of a walk cycle animation contains a state in which the character’s left foot is touching the ground. It can also be in a state where the left foot is lifted.
If this sounds like I’m overstating the obvious, I really am. A basic state machine is an exceedingly simple concept. Where state machines begin to shine however is in the concept of “transitions”.
What is a transition?
A transition is, as you’ve guessed, the proceedings that take place when a state machine changes its state. We don’t need transitions for a state machine to fulfill its purpose, but they are very powerful. A rule that is important to reiterate is that a state machine can only ever be in one state, and it’s this rule that offers one of the core benefits of the pattern; A sense of clarity.
(In this way programming is like maths to me. You know that 1+1=2, and that is a fact of the universe. Doesn’t it feel great to have such a solid grasp of reality?)
So given that a state machine can only ever be in one state, how would we change that state? Let’s go with the MovieClip example for now. Let’s say that MovieClips don’t exist, and we have to design their logic.
Our animation consists of a set of states, each describing a frame, and for a frame of animation the concept of a transition is simple; you simply tell the MovieClip to set its current state to another indexed frame, and the state changes, bam. Right? But even this simple state change has a transition. The previous frame is removed, and the new frame is shown. This transition could be handled by the state machine itself (in this case, the MovieClip), or by the individual frame. In the case of a dumb MovieClip with no logic attached to frames, our hypothetical reinvented MovieClip could handle this state transition just fine:
removeChild(_currentFrame);
_currentFrame = frames[index];
addChild(_currentFrame);
}
Let’s assume our frames have content however. Let’s say the first frame has a video player, and that the next frame has a sound to play. The video should stop, and the sound should begin playing. The state machine, in this case the MovieClip, doesn’t need to know exactly what is contained in the frames, but it does need to tell them to shut down and initialize. Again, not hard to imagine.
_currentFrame.shutdown();
removeChild(_currentFrame);
_currentFrame = frames[index];
addChild(_currentFrame);
_currentFrame.initialize();
}
And voila, we have described the state machine pattern that I have become so fond of, in its entirety!
Applying the state machine pattern
When I first started reading about artificial intelligence for games, state machines were introduced very rapidly. AI behavior could be described as a graph where each node was linked to possible states it could transition to. For instance an AI in a sneaking game could be defined by a graph such as this:
Each box is a state the AI can be in, and the arrows represent possible transitions, each defined by the states themselves. The framework driving the AI only really needs to keep updating the current state, and let the logic of each state define the behavior.
I’ve written a primitive version of this AI using the state machine pattern, defining a simple autonomous agent that can move around the world, and a set of states that define its possible behaviors. Let’s take a look!
Our Agent is a small, overconfident, myopic black arrow. He will hang out for a bit, then wander around at random, pausing once in a while. When the mouse cursor is in front of him within a certain radius, he will chase after it. When he comes close however, he’ll freak out and run away until he reaches a safe distance. Then he will resume his normal behavior again.
This behavior is defined by the following states
Each state implements the IAgentState interface, which looks like this:
The IAgentState interface
{
import agent.Agent;
public interface IAgentState
{
function update(a:Agent):void; //called every frame
function enter(a:Agent):void; //called when the state becomes the current state
function exit(a:Agent):void; //called when the state ceases to be the current state
}
}
This interface specifies 3 methods to be called by the state machine, each taking a reference to the state machine itself. I like to work on this reference because AI states can be treated as largely abstract; It’s not hard to conceive of several different types of agent needing the wandering behavior, and it is nice to be able to reuse the same behavior instance. Let’s look at the Idle state to see what this means.
The Idle state
{
import agent.Agent;
public class IdleState implements IAgentState
{
/* INTERFACE agent.states.IAgentState */
public function update(a:Agent):void
{
if (a.numCycles > 30) { //Have we executed/idled for 30 frames?
a.setState(Agent.WANDER); //Then let's take a walk
}
}
public function enter(a:Agent):void
{
a.say("Idling...");
a.speed = 0; //Stop the agent
}
public function exit(a:Agent):void
{
a.randomDirection(); //When we leave this state, face the agent in a random direction
}
}
}
The wander state
{
import agent.Agent;
public class WanderState implements IAgentState
{
public function update(a:Agent):void
{
a.say("Wandering...");
a.velocity.x += Math.random() * 0.2 - 0.1; //very simple wander behavior,
a.velocity.y += Math.random() * 0.2 - 0.1;
if (a.numCycles > 120) {
a.setState(Agent.IDLE); //Let's take a break every 120 updates
}
if (!a.canSeeMouse) return;
if (a.distanceToMouse < a.fleeRadius) {
a.setState(Agent.FLEE);
}else if (a.distanceToMouse < a.chaseRadius) {
a.setState(Agent.CHASE);
}
}
public function enter(a:Agent):void
{
a.speed = 1; //Begin moving the agent
}
public function exit(a:Agent):void
{
}
}
}
At this point I am sure you are getting the idea; The states themselves contain no data, and are entirely dependent on a state machine instance to interact with. In this case, it’s almost like a set of template methods that are being swapped out. The nice thing here is that instead of creating a ton of state objects for every agent, we can reuse the same states. Click the stage in the above swf to create new agents, all using the same static states.
Finally, we’ll look at the state machine itself.
The Agent class
{
import agent.states.*;
//imports omitted
{
public static const IDLE:IAgentState = new IdleState(); //Define possible states as static constants
public static const WANDER:IAgentState = new WanderState();
public static const CHASE:IAgentState = new ChaseState();
public static const FLEE:IAgentState = new FleeState();
public static const CONFUSED:IAgentState = new ConfusionState();
private var _previousState:IAgentState; //The previous executing state
private var _currentState:IAgentState; //The currently executing state
public var velocity:Point = new Point();
public var speed:Number = 0;
public var fleeRadius:Number = 50; //If the mouse is "seen" within this radius, we want to flee
public var chaseRadius:Number = 150; //If the mouse is "seen" within this radius, we want to chase
public var numCycles:int = 0; //Number of updates that have executed for the current state. Timing utility.
public function Agent()
{
//Boring stuff omitted
_currentState = IDLE; //Set the initial state
}
/**
* Update the current state, then update the graphics
*/
public function update():void {
if (!_currentState) return; //If there's no behavior, we do nothing
numCycles++;
_currentState.update(this);
x += velocity.x*speed;
y += velocity.y*speed;
if (x + velocity.x > stage.stageWidth || x + velocity.x < 0) { x = Math.max(0, Math.min(stage.stageWidth, x)); velocity.x *= -1; } if (y + velocity.y > stage.stageHeight || y + velocity.y < 0) {
y = Math.max(0, Math.min(stage.stageHeight, y));
velocity.y *= -1;
}
_pointer.rotation = RAD_DEG * Math.atan2(velocity.y, velocity.x);
}
public function setState(newState:IAgentState):void {
if (_currentState == newState) return;
if (_currentState) {
_currentState.exit(this);
}
_previousState = _currentState;
_currentState = newState;
_currentState.enter(this);
numCycles = 0;
}
public function get previousState():IAgentState { return _previousState; }
public function get currentState():IAgentState { return _currentState; }
}
}
As you can see, we are still applying the same theory as in our MovieClip example; Close what you had, open what you’re getting, and since we’re doing realtime stuff, update what you got. I’ve put up the source for this example, in case you’re curious to take a peek.
Summing it up
State machines are mechanisms that have their behavior defined by a known set of states. Knowing this, you can easily jot down your application as a state graph and use the state pattern and a rudimentary state machine to throw together a click through for instance, while maintaining scalability. I’m just scraping the surface. State machines have a huge number of uses, from managing visual states, to choosing which game state to execute, such as the title screen, leaderboards, game loop etc, to state machines creating new dynamic state machines during parsing algorithms. States themselves can very well be state machines.
I hope I haven’t bored you to death with my rambling. I’ve used this pattern and variations of it for a wide range of projects. It’s a safe bet for prototyping, almost indispensable for game development, and super stupid easy to pick up. Thank for your reading 
I love it!
Very nice article!
I never realised I was using Finite State Machines all along, only mine aren’t structured quite so elegantly. Will definitely be coming back to this to make better EnemyBrains in my next game.
Yeah man, it’s such a simple pattern you can be using it entirely by “accident”
Nice!! Excellent reading to start my day with!!
Well done!
the demo is too funny
Well written post man, good read.
Great, Concise, Informative!
Cool beans! Thanks for sharing.
Great article and just what I was looking for as I am porting some Flash games that were developed using the timeline to form the basic structure to a non timeline based language .
I was really struggling to find a solution on how to represent the flow of the game using purely code. Your article has helped me think about how a state machine could assist me with this task.
Excellent description – love the finite state machine pattern.
an interesting exploration that I will have to look at again when developing anything that needs to look like it is more than just random action!
Thanks for the post.
[...] The State Machine by Andreas is well worth the read if you are interested in more content like this. [...]
Very well explained and an inspiring demo!