Finite State Machines are a common used principle in games and applications. And most of you have a basic grasp of them. However I have often seen them implemented incorrectly. For each programming language it is different and even within a programming language there are several methods of implementing decent to good FSMs. This tutorial will focus on GML for implementing FSMs.
First and foremost thing to know about states and finite state machines in any language is:
1) A state is always defined by 1 attribute (variable) and not more.
2) The values of attributes (member variables) do NOT define the state, but the state DEFINES the values of attributes.
3) State valid values for the attributes are set when entering the state, not during an update cycle.
This means that checking several numerical or boolean variables like "jumping", "falling", "isRunning", "facing" in several if statements is not using states.
There are several ways to implement states in GML. I will give three methods on how to use states. All three of them will have the object in question have an attribute called "state". This attribute will thus hold the value for the state and this is the only variable that will be checked to determine the code that needs to be executed during the event/cycle/frame.
Method 1: Numerical or StringOkay, this is my least favorite method and not one I would recommend for games with some complexity. The 'state' variable will hold a value that is an string or an integer. For examples look at the code below:
String:
state = "jumping";
Integer:
state = 1;
Note that when using integers as your state variable it is better to have some constants defined such as 'JUMPING'. This will make the code more understandable for yourself and others. I will be using constants in the rest of the examples.
During the events you then check the 'state' variable's value with a switch or if-else statements. This will allow the event to execute the right code for that condition.
switch( state )
{
case IDLE:
//do the idle <event> code
break;
case WALKING:
//do the walking <event> code
break;
case JUMPING:
//do the jumping <event> code
break;
default:
//you are in an error state
//do the error handling code
break;
}
//OR
if( state == IDLE )
{
//do the idle <event> code
}
else if( state == WALKING )
{
//do the walking <event> code
}
else if( state == JUMPING )
{
//do the jumping <event> code
}
else
{
//you are in an error state
//do the error handling code
}
It is also good practice to use one event to check if a transition to another state has to occur. A Step or Draw event is something that is done every cycle and often the transitions are an animation end, distance to another object or a timer timeout, these events are good choices. You can also implement the checks in different events, but it is harder to assess whether you have implemented it properly. Some might argue that putting the checks in the events, such as Draw, Key Release and Animation End, that associate with them is more sensible.
Whatever your choice, the checks are most often done in an if (- else if) statement and when true the 'state' attribute value is set. A common mistake however is that only the 'state' attribute is set. Remember, the state DEFINES the values of the attributes and NOT the value of the attributes defines the state. Thus when setting the state you should also set the values of all the attributes of the object to a for the state valid value. However some attributes do not matter or should not be changed at all like the position of the object. These do not have to be considered. Some attributes can have a valid range and thus the value needs to be checked if it is within the valid range.
if( key_pressed('A') )
{
state = JUMPING;
sprite_index = player_jump;
image_speed = 0.5;
attribute1 = 6;
if(attribute2 < 3)
{
attribute2 = 3;
}
else if(attribute2 > 9)
{
attribute2 = 9;
}
//else attribute2 keeps its value
}
It is important that the values of the attributes are set to state valid values when the state changes. Failing to do so might or even will cause errors when executing the state specific code. It is also propper to execute state specific code when exiting the state. This is cleaning up, because each state only knows what happens within himself and does not know what happens in other states. However this is not absolutely necessary as it can be safe to assume that the next state will set the right values for the variables. But when the state has created an extra object and the object should not have a lifecycle beyond the state it is propper to destroy the object when exiting.
Method 2: ScriptsThe characteristic of the first method is that all the code for each state is listed in a event. When the game is simple and there are only a small number of states the listing won't get long and that method is good. However when the game gets more complex and the number of states grows, so does the code listing in the event. You need to scroll more and it becomes much harder to oversee what you have implemented. For others it also because a bit more difficult to read.
Game Maker offers a solution to this by separating code into Scripts. Instead of having the 'state' attribute hold a numerical or a string value the attribute holds a Script value. Even the object no longer needs to check the state it is in during the event code and with a simple command the state specific can be executed. And scripts are capable of accessing the attributes of the object it is called from like it is part of the event code. The following code shows how to initialize the state:
state = scrIdle; // scrIdle is the name of the script when the state is IDLE
The disadvantage is that a script does not automatically know from which event it is called like the event code. Game Maker provides some functions to check which event in the gamecycle currently is active. However each script can have up to 16 arguments to provide some additional information. Thus it is a simple matter to provide an event identifier as the first argument. To make the code readable it is propper to use constants for event identifiers when possible. The code with the object is then as follows:
if(state != 0 && script_exists(state))
{
script_execute( state, <event>, ... ); //... are any additional arguments for this event, such as locally calculate values.
}
else
{
//you are in an error state.
//do the error handling.
}
The "script_execute" command is also available in the Lite version of GameMaker and can have up to 16 arguments besides the script argument.
switch(argument0)
{
case STEP:
//do step event code for the state;
break;
case DRAW:
//do draw event code for the state;
break;
case KEYPRESS:
//do keypress event code for the state;
break;
case ENTER:
//In this case the state of the object has transitioned to this script.
//Set all the attributes to the correct values.
break;
default:
//Error, an unknown event has been passed.
//handle the error or let it slide
break;
}
//OR
if(argument0 == STEP)
{
//do step event code for the state;
}
else if(argument0 == DRAW)
{
//do draw event code for the state;
}
else if(argument0 == KEYPRESS)
{
//do keypress event code for the state;
}
else if(argument0 == ENTER)
{
//In this case the the state of the object has transitioned to this script.
//Set all the attributes to the correct values.
}
else
{
//Error, an unknown event has been passed.
//handle the error or let it slide
}
Note that the example has a special event called "ENTER". This is a state machine specific event which does not occur in Game Maker. The purpose of the event is to set all the attributes of the object to state valid values, when the state of the object transitions to this particular script. A similar event is when the state transitions and the script has clean up for "EXIT"ing the state. The following example shows two methods for changing the state:
if( key_pressed('A') )
{
if(state != 0 && script_exists(state))
{
script_execute(state, EXIT);
}
//else an error
state = scrJump;
if(state != 0 && script_exists(state))
{
script_execute(state, ENTER);
}
//else an error
}
//OR nr2
if( key_pressed('A') )
{
if(state != 0 && script_exists(state))
{
script_execute(state, EXIT);
}
//else an error
if(script_exists(scrJump))
{
scrJump(ENTER);
}
//else an error
}
...
case ENTER:
sprite_index = player_jump;
image_speed = 0.5;
attribute1 = 6;
if(attribute2 < 3)
{
attribute2 = 3;
}
else if(attribute2 > 9)
{
attribute2 = 9;
}
//else attribute2 keeps its value
break;
case EXIT:
image_speed = 0;
attribute1 =0;
break;
...
//OR nr2
...
case ENTER:
state = scrJump;
sprite_index = player_jump;
image_speed = 0.5;
attribute1 = 6;
if(attribute2 < 3)
{
attribute2 = 3;
}
else if(attribute2 > 9)
{
attribute2 = 9;
}
//else attribute2 keeps its value
break;
case EXIT:
state = 0; //I know it is an error state, but it forces the next script to set a propper state
image_speed = 0;
attribute1 =0;
break;
...
Like with the first method of numerical/string values the attributes have to be set to values that are for the state valid. Just changing the script is not enough. And the best place is within the script that is also the state.
Method 3: Array of scriptsThe 2nd method has the advantage over the 1st method that the code for each state is separated in their own listings and thus far more easy to debug then when everything is put in the event code. However the check for what state the object is in during the event code of the 1st method is swapped by the check for the event that the game is in during the script code of the 2nd method. This check can also be eliminated when the state uses an array of scripts.
Okay this goes a bit against the requirement that the state is only a single attribute, because an array is a container of the same type attributes. However it has more advantages. So let me explain. The 'state' attribute is container for several script values instead of just one. The first element of the container is still the state identifier, which will be referred to as ID (value = 0). The rest of the scripts can be accessed using the event identifier (starting with value 1 and going up). Thus the code in a single script only contains the code that is needed for that state during that event. Setting it up is done as the following example:
state[ID] = scrIdle;
state[STEP] = scrIdle_step;
state[DRAW] = scrIdle_draw;
state[KEYPRESS] = scrIdle_keypress;
[/event]
Note that the code for entering and exiting the state is put in the script under ID. Executing the state specific code for an event is similar as in the 2nd method, but no event identifier needs to be provided.
[code=event]
if(state[<event>] == 0)
{
//no code or a default needs to be executed.
}
else if(script_exists(state[<event>]))
{
script_execute( state[<event>], ... ); //... are any additional arguments for this event, such as locally calculate values.
}
else
{
//you are in an error state.
//do the error handling.
}
//do all the script code.
A state transitions is also similar to that of the 2nd method, however the initialization needs to do a bit more.
if( key_pressed('A') )
{
if(state[ID] != 0 && script_exists(state[ID]))
{
script_execute(state[ID], EXIT);
}
//else an error
if(script_exists(scrJump))
{
scrJump(ENTER);
}
//else an error
}
if(argument0 == ENTER)
{
state[ID] = scrJump;
state[STEP] = scrJump_step;
state[DRAW] = scrIdle_draw;
state[KEYPRESS] = scrJump_keypress;
sprite_index = player_jump;
image_speed = 0.5;
attribute1 = 6;
if(attribute2 < 3)
{
attribute2 = 3;
}
else if(attribute2 > 9)
{
attribute2 = 9;
}
//else attribute2 keeps its value
}
if(argument0 == EXIT)
{
state[ID] = 0; //I know it is an error state, but it forces the next script to set a propper state
state[STEP] = 0;
state[DRAW] = 0;
state[KEYPRESS] = 0;
image_speed = 0;
attribute1 =0;
}
Note that during the "ENTER" the script that is set for the DRAW event is called scrIdle_draw. This is another advantage of this method as it allows states to reuse scripts when two states have exactly the same code for an event. However if there is in the code one token difference like a '+' changed into a '-' then a new script still has to be created. This method can rank up the number of scripts and if you do not organize them well it can be a confusing mess.