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!

For those of you who don’t know, Google Wave is aiming to be the next evolution of online communication. From what I have seen so far, it seems to be a consummation of email, message boards, and chat, forcing users to no longer think of online communication as individual collections of messages and responses, but a cluster of ongoing conversations, where individuals can enter and leave at will.

The feature that piqued my interest, was the feature that turns the conversation into a chat, and allows both users to see the conversations being typed by each other in real time. While this could be very useful for conversing with someone who typed painfully slowly, it changes the way users have generally used instant messaging up until now.

Instant Messaging serves as a platform to allow generally, two people to have a conversation with each other in “real time”, where one user sends a message, the other responds, etc, in the same way that you and I may have a face-to-face conversation. If you wanted to map the features one-to-one, then while you are talking to me in person, I will be listening to your statement, and thinking about what I want to say in response, this is the same as reading your message in an IM, and typing my response in my client.

However, lets say you and I are having an in-depth conversation, or debate, on either medium. We make take our time to collect our thoughts, to consider our responses, and figure out what we want to say next. We may even completely change our response we had originally planned in order to answer some new topic that has come up. Either way, this can be afforded to us in IM clients by typing out our responses and looking them over before we send them off.

While I agree that when talking to someone over instant message, the time waiting for a response can seem length. However, almost all clients today will notify the receiving person that you are typing, alerting that there is indeed a conversation taking place. The question begs then, how do users react to a feature that allows us to see the response of a person, as it is being created?

While this is an interesting feature in it of itself, it could do one of a few things:

• Bring users closer to the experience of having a true conversation through text.
• Users would be distracted by the other person typing a response, or follow up message to what they just sent, and it would cause confusion.
• A new rule of “internet etiquette” would appear within the use of this tool, and you would patiently wait for others to finish their thought before you start typing your response.

Google will offer a checkbox to turn this feature off, and it will be interesting to see how the response to this feature is received. Within innovation, one will ultimately be forcing adopters to rethink or retool their processes in order to adopt a new technology. It’s important to consider what the processes you are “fixing”, because maybe they weren’t broken, but a matter of course from the translation of a process from one medium to the next.