Intro

When creating an A.I. system for your game, you’re going to want objects to be able to make decisions on their own, or at the very least have some sort of flowchart-like interaction. What if you were able to easily set up those basic interactions, and simply have your objects detect when certain stimuli change their states, and have actions and reactions dependent on the states of an object? We can create seemingly more intelligent objects, and a potentially more immersive game.

The Individual State

Each of the states in our machine will have the following information:

• State Name
• Minimum Duration
• Maximum Duration
• Transitions

This way, we can define the state with a human name that would make sense to a designer and something that could be easily scripted, and we can specify a range at which the state can last. With random state lengths, we can make objects seem a bit more organic. For objects that we need specific lengths, we can simply set the two to equal each other! Lastly, we need to know all the different states into which an individual state can transition.

The Transition Table

Each State will carry it’s own “Transition Table”, will include two important bits of information per entry:

• State Name
• Weighted Percentage

This way, we know which state we are going to transition to, and we are going to allow the definition of a weighted percentage of the states that are chosen. This will allow us to introduce rarity with our transitions.

The Machine

Our FSM will have several important actions which we will need to consider:

Add State

After our FSM is created for an individual object, we will add the different states that will be valid for this particular object. We will give the option to add a min/max duration of the state, in case we want to attempt to make certain states less predictable than others.

Remove State

We may see a need to remove a state from our object. Consider  enemies that after being provoked will not stop engaging/attacking the player until they kill the player or are destroyed themselves. We could get this feature ‘automatically’ if we removed the idle state from this object, and any transitions that may have brought us to this state.

Add Transition

In order for a state to transition from one state to the next, we are going to want to add these connections in individually, with a weighted percentage at which they have the possibility of being picked. This can allow for balancing the choosing of states. We will also have this action update transition if it already exists in the table.

Remove Transition

We may want to implement conditional transitions, or remove transitions for states that no longer exist.

Set State

For setting an initial state on our object, or forcing the object into a specific state.

Choose Next State

When the current state expires, the FSM will need to select a transition and set the next state

Usage

Usage is fairly simple. You’ll first want to include the code in your Solution. To every object file you wish to use the FiniteStateMachine in, you need to add a:

using Zapdot;

At the header with your other using statements.

You will then want to add a class level variable.

class Enemy
{
   FiniteStateMachine mFSM;

   public Enemy()
   {
      setupStateMachine();
   }
}

Now, for tidiness-sake, create a method that you’ll use to store the setup for this particular object, to be called once during initialization.

 private void setupStateMachine()
 {
 mFSM = new FiniteStateMachine();
 mFSM.AddState("idle", 2, 3);
 mFSM.AddState("walk", 2, 2);
 mFSM.AddState("run", 1, 3);
 mFSM.AddTransition("idle", "walk", .5);
 mFSM.AddTransition("idle", "run", .5);
 mFSM.AddTransition("walk", "idle", .5);
 mFSM.AddTransition("walk", "run", .5);
 mFSM.AddTransition("run", "idle", .5);
 mFSM.AddTransition("run", "walk", .5);
 // Pick our first state.
 mFSM.SetState("idle");
 }

This instantiates the new object, and adds three states to the Enemy object. (“walk”, “run”, and “idle”). Both idle and run will have random time between their respective min and maximums, but walk will always be 2 seconds long, no matter what.

We then add the transitions for these states, essentially saying that every state can transition to the other, and that they have equal weight to do so.

Lastly, we tell the object what state to start in.

After this object is setup, we can add it to our update class:

mFSM.Update(gameTime);

And do some tests on it to affect gameplay.

if ( mFSM.CurrentState.Equals("idle") )
   mVelocity = kIdleSpeed;

And so on.

The Code

Download (MIT License)

The code is available below, and being released under the MIT License. Feel free to do whatever you want with it, just don’t blame me.

If for some crazy reason you do start using the code, please tell me what you think, or what cool things you’re doing with it.

Future Additions!

This is only the starting point from here, and I hope to be able to add much more. Future additions include wonderful things like multiple concurrent states to give a little more depth to our objects and add for some interesting decision-making!