Finite State Machines

On my previous article, I have mentioned that in the Zombie Survival Shooter Game, the Enemy states will be designed using FSM principles, rather than using a traditional approach. In short, the states will be responsible for their own behaviour, I will not be stating some conditions and behaviours according to conditions.

So, what does Finite State Machines stand for? Here’s the definition of FSM from Wiki:

Finite State Machine is an abstract machine that can be in exactly one of a finite number of states at any given time. The FSM can change from one state to another in response to some inputs; the change from one state to another is called a transition.

To get a better and detailed understanding, I suggest you to take a look at Unity Learn regarding State Machines by clicking here. Previously, videos prepared by Pluralsight were available on Unity Learn and despite their videos were short, you would probably be frustrated even by watching and you would have get to that “Aha! I know that feeling!” point — the point that you realize that your code is getting more and more complicated.

If you are familiar with Animation and Animator window, you are actually familiar with FSM: There are a finite number of states and the character can only be in one state at a time. Here’s a sample shot from the Dungeon Escape game:

As can be seen above, the Player has 5 defined states and he can only be in one state at a given time. In the Dungeon Escape game, I have used a traditional approach, without using a FSM, to trigger transitions between two states. Here’s a list of parameters I have used:

In order to decide on the state of the Player, 3 triggers and a boolean was used.

So what makes using a Finite State Machine preferable over traditional, interdependent approach?

In the most basic way, using Finite State Machine makes our game more readible, and easy to debug and fix.

Imagine the workload required if we are going to decide on adding new states to the Player. After some point, you will feel the headache of too many conditions and excessive coding, which makes your coding complicated. In short, traditional approach is hard to expand (think that you want to add/change or remove a new action for a game object) and requires a lot of energy and time in order to get an acceptable result — certainly with a huge load of lines of coding. Certainly, these make the code hard to debug.

FSM approach simply tells us not to focus on the behaviour but to focus on State. A state is only interested in the behaviours that belong to that state.

Enum types are used for defining states. Handling the behaviours of AI is much more easier with using FSM as we do not need to focus on their current conditions (the state they are in, the animation that is playing etc). All of these will be handled by State Machine, which saves us from too many booleans and conditional statements.

In the Zombie Escape game, the Enemy will have 3 main states namely: Idle, Chasing and Attacking. However, it might have many more states if we wanted to.

Up to this point, I have created 3 states and defined the behaviours for Attack and Chase states. As you can see above, there is no boolean or trigger telling the Enemy to Attack or Chase. Despite the fact that I am actually at the beginning of the project, you might have realized that there is no boolean such as “isAttacking” or “chasing”. Rather, the behaviours are being handled within the states.

I will be updating this article as I progress further in the project.