Simple Unity State Machine

When developing we needed a simple state machine, preferably already implemented. From the list of implementations that Google offered, we chose this one for simplicity and compactness. We use at home, in general, FSM is not bad. Next, under the cut translation of the original article by the author of Greece Tasos Giannakopoulos. I am not a translator, so I tried to convey the meaning, sometimes explaining the essence in my own words, for which I apologize to the perfectionist.

What is a State Machine?

The state machine is a popular design pattern that game developers use to implement behavior, for example, the behavior of units or some complex objects.
A finite state machine (Finite state machine or FSM in bourgeois terminology) is easily described by diagrams and then programmed, which allows using it to implement a wide range of behaviors.

According to the definition of the site AI-depot.com (the best site according to AI in the opinion of the author of the original article), the state machine consists of four main elements:
- states that define behavior and can produce actions
- state transitions that define the transition from one state to another
- the terms and conditions that must be met for the transition
- input states received from the outside or inside, which can lead to state transitions according to the rules

I will not go into the theory of finite automata, who needs it - there is the Internet with a bunch of detailed articles, and there are several links at the end of the article.
')

Why all this?

To implement the behavior of the main character, in the project I'm working on, I used FSM. Implementation on C #. At the moment, the code is far from its final form, but it has basic functionality, which is enough to explain the principle of FSM.

- Initialization of the finite state machine and a set of transitions determining the character's behavior
- When input events come, an attempt is made to transfer the FSM to the appropriate state
- If a transition is possible, the state changes and a callback is called for the corresponding transition.

In general, I wanted something that would allow me to implement the following scheme, which determines the behavior of a player’s character. In addition, I would like the system to be expandable and you can easily add new states and transitions.

Design and implementation

I looked here, thought, and decided that in C # this problem is best solved with the help of delegates. Delegates in C # are function pointers, allowing you to call a function from anywhere. They are easy to use, flexible, and most importantly, they work fast (this is almost a direct function call).



In the class diagram above, you can see the StateTransition which is implemented through the IEquatable interface and FiniteStateMachine, the actual state machine interface itself. Both classes are templates that allow the user to define a state. I use them with enums, which allow us to define a list of possible states.

StateTransition is essentially a C # tuple, where two states are generated as a key. After I implemented, I learned what can be done easier - to implement through System.Collections.Generic.KeyValuePair <K, V>, where K and V are possible states. But since I'm not sure that the transition from the tuple to the KeyValuePair will increase the speed, I decided to leave everything as is.

At the end of the article you will find a link to the source code of my implementation. Just unpack, and use as in the example below. I have already said that FSM is far from complete, but it provides basic functionality, and may be the starting point for other projects.

How to use

First, create an enumeration of all the states of your object and pass them to FiniteStateMachine.

// Add the possible states here public enum eCharacterState { IDLE, RUN, // ... };  public class CharacterFSM : FiniteStateMachine<eCharacterState> {}; 

You have to create a bunch of functions that implement the behavior of your object, for me, for example, it is Run (), Idle (), IdleJump () and others. Then use AddTransition () to add the desired state transitions. Under certain conditions, you call Advance () in order to try to switch to the desired state. If the transition from the current state is possible, then a user-defined function is called.

The code below implements a part of my character's behavior. This code snippet is enough to understand how to use FSM.

 public class Player : CatGameItem { // ... public CharacterFSM mFSM; void Start () { mFSM = new CharacterFSM(); // Add state transitions here mFSM.AddTransition(eCharacterState.IDLE, eCharacterState.RUN, Run); mFSM.AddTransition(eCharacterState.RUN, eCharacterState.IDLE, Idle); // This calls the Run() function while on run state. // I will probably replace it with with a state callback or something similar sometime in the future to avoid calling TryGetValue all the time. mFSM.AddTransition(eCharacterState.RUN, eCharacterState.RUN, Run); // ... } // FSM Delegates void Run() { //Debug.Log("RUN!"); float curMoveSpeed = Controller.GetGroundSpeed(); AnimationController.SetSpeed("Cat_Run", curMoveSpeed/RunSpeed); AnimationController.Play("Cat_Run"); } void Idle() { AnimationController.Play("Cat_Idle_Breath"); } // ... void UpdateInput() { mCurAxisInput.x = Input.GetAxis("LeftAxisH"); // Get Horizontal axis (XBox360 xAxis OR 'A', 'D') mCurAxisInput.y = Input.GetAxis("LeftAxisV"); // Get Vertical axis (XBox360 yAxis OR 'W', 'S') } void UpdateStateMachine() { // Based on the input events, advance to desired state // Run, Idle if (mCurAxisInput.magnitude > 0) mFSM.Advance(eCharacterState.RUN); else mFSM.Advance(eCharacterState.IDLE); // ... } void FixedUpdate() { // Update the state machine here UpdateStateMachine(); } void Update () { // Update user input UpdateInput(); UpdateCharacterMovement(); } } 

FSM source

Links to related articles:

https://en.wikipedia.org/wiki/Finite-state_machine
http://ai-depot.com/FiniteStateMachines/FSM.html
http://jessewarden.com/2012/07/finite-state-machines-in-game-development.html
http://unitygems.com/fsm2/

The author of the original article: Tasos Giannakopoulos .