Stencyl 3.4.0 is now out. Get it now!

Finite State Machine Platformer


  • Posts: 2
Have you ever had trouble managing how your character can transition into different states? Can a ducking character wall jump? Can a jumping character duck? If you've been tackling these problems with lots of flags and if statements, you might want to give finite state machines a look!

It sounds complicated, but a finite state machine is basically just an object that can be in a single state at a time... like jumping, falling, walking, etc. As the object transitions between states, enter and exit state events are triggered. When the jumping state is entered, for example, you would probably want to start the jumping animation and play a jump sound effect. You could even have an object with multiple state machines. Maybe another state machine for whether you're holding an object, throwing an object, or without an object? Maybe another state machine for who is controlling the character--a script, AI, or the user?

In this implementation, you simply attach the "State Machine" behavior to an actor, and specify a list of state machines that the actor will have, along with a list of the different states each machine can be in. For example, the "Movement" state machine might be able to be in an Idle, Walking, Jumping, Falling, or Ducking state.

Each state corresponds to a behavior.  If you list "Walking" as a possible Movement state on your character actor, for example, your character actor must also have a corresponding "Walking" behavior. All the listed states (behaviors) are disabled by default, except for the first one listed. This is the default starting state. The order you list the states is otherwise unimportant.

From here, you can call a few different methods on the State Machine behavior to change what state the machine is in--thereby activating the new active state (behavior) and disabling the previous one. Only one state (behavior) will ever be active at a time for each state machine. The methods for changing state are...

Change State: Replaces the current state of a machine with a new one.
Add State: Adds a new state to the top of a machine's state stack--changing to the new state.
Remove State: Removes the state from the top of a machine's state stack--restoring the previous state.
Reset State: Clears a machine's state stack--resetting the machine back to its default state.

Whenever a state change occurs, an "ExitState" event is triggered on the previous behavior (the one that's about to be disabled), and an "EnterState" event is triggered on the new behavior (the one that's about to be enabled). You can handle these events in your state behaviors to play animations and other setup/teardown procedures.

The attached example is a complete rework of the original Jump and Run Kit. It comes with a few other noteworthy things...
An animation queue allows you to easily queue up animations. For example, when a character lands on the ground, you could queue up a landing animation that plays once, followed by the idle animation.
A control translator that allows control of an actor to be switched (from user input, to a script, or AI, etc) at runtime.

It might look a little complicated at first glance, but once you wrap your head around it I think you'll find it's a much more manageable structure for large projects. The project I wrote this for is stagnant now, but hopefully someone else will find it useful!


  • *
  • Posts: 2340
After analyzing it, I can see all the meticulous and ingenious work that you have done. I appreciate all the effort you have made in creating this well-crafted "State Machine" behavior so practical, versatile and useful.

Thanks a lot for sharing it.
I'm spanish, excuse me for my bad English.
I'm not a private teacher. Please, post your questions in the public forum.


  • Posts: 2
Appreciate the kind words, @liberado. Glad you like it!