I wanna make a fighting game! A practical guide for beginners — part 3 (2021 update)

6 min readOct 9, 2017

This article was originally written by me and published at https://indiewatch.com on October 9, 2017. Since I have restarted this series of tutorials, I have come to the decision of reworking my earlier articles and uploading them to Medium, in order to have more control over them and update them in case of need.

Characters as state machines

After a long hiatus, let’s start again with our journey in the realm of fighting game making! Now, we start with technical guides and insights on the actual game building pipeline. If you have lost some lessons, worry not! All links to the previous parts of this series of tutorials are listed at the end of the page.

Today’s article is a small system-agnostic, technical introduction about building the character as a state machine.

What is a state machine?

Okay, let’s take a deep breath and review the title again. What is a state machine?

*A turnstile state machine diagram by Chetvorno (Own work) [CC0], via Wikimedia Commons*

There are plenty of articles and learning material out there (see the Wikipedia page), but, to put it simple, we are talking about a device which can move between a finite number of different configurations in a controlled way.

As a real-life example, we can consider a turnstile (thanks Wikipedia for the idea and the diagram). As you can see in the above schematic, this simple device has only two states: locked and unlocked.

In its locked state:

pushing it to open has no effect (it remains into the locked state);
inserting a coin turns it into the unlocked state.

In its unlocked state:

pushing the button opens the locker and sends it back to the locked state;
inserting a coin has no effect, effectively maintaining it into the unlocked state (and, hopefully, giving you the coin back).

*What about using this as a game character? Well, if even* *a car* *made it, why not? =P*

Well, a fighting game character works almost like a turnstile… just in a more complex fashion. Instead of having only two states, there are several of them, connected by button presses and events (being hit, performing a move…).

The character state machine

Each of the states in which a character can find itself during a match is interconnected in different ways. The next picture shows a rough, simplified example of what I’m talking about:

For those wondering, yes, I’m using my game for building this example. It’s easier to take screenshot and has no copyright issues =D

As you can see, the table of possible states is now more populated — but the basic reasoning is almost the same.

Standing state:

pressing UP sends the character into the jumping state;
pressing DOWN sends the character into the crouched state;
pressing FORWARD sends the character into the walking state;
pressing nothing keeps the character in the standing state.

Crouched state:

pressing nothing sends the character into the standing state;
pressing DOWN keeps the character in the crouched state;
pressing UP or FORWARD has no effect.

Jumping state:

pressing nothing sends the character into the standing state (when the jump ends);
pressing DOWN, UP or FORWARD has no effect.

Walking state:

pressing UP sends the character into the jumping state;
pressing DOWN sends the character into the crouched state;
pressing nothing sends the character into the standing state;
pressing FORWARD keeps the character in the the walking state.

Can you see the pattern? Depending on the player action, the character goes into a different state, which opens up the possibility to go to another state, and so on and so forth.

A fighting game character works almost like a turnstile… just in a more complex fashion

The artist’s struggle

Now, if you are a rational guy and you are still thinking about the first article in this series, you could make a simple, cute, one million bucks question:

HOW THE HECK AM I SUPPOSED TO ANIMATE THE TRANSITIONS?!

Well, short answer: in a 2D game, either you have to animate every single transition or not to animate them at all (or find a reasonable way between). After all, 2D is a more acceptable break from reality, so rough transitions do not have a game-killing effect (unless the transition is really rough)! That said, you usually need to animate only a small subset of all transitions to get a good feeling for the game graphics.

As an example, have a look at this spritesheet of Ryu, from the SNES version of Super Street Fighter II. You’ll immediately notice that the crouching animation is just one frame long, that there is no transition to blocking and that the only two big animations for state changing are the recovery animation and both jump animations (which anyway have repeated frames, reducing the number of resources needed).

As for 3D… hey, friend! That’s your lucky day!

Your 3D savior: animation blending

Enters animation blending! Most game engines have already this life-saving function! Basically, once you have two animations, the engine will calculate the transition between the two for you and smoothly connect the states!

It’s available in many commercial engines, ranging from Unreal Engine 4 to Unity3D. Even older engines like Irrlicht support this feature, so — if you are a one man team — you won’t need to create all and every connecting animation: your engine will do the dirty job for you.

Notice that this is not an universal solution: for some complex transition, you could be required to create a specific animation OR to tweak the blending parameters in order to make it more natural.

Thanks to 3D animation blending, you won’t need to create all and every connecting animation: your engine will do the dirty job for you.

Moves and States

So, now that we discovered that the animation side is more or less straight forward, how to use this to your advantage? Why would you need a state machine? The answer is straight-forward: to manage your character’s moveset in the most effective way.

Using states is the key to build a differentiated moveset which needs little to no maintenance. When you design and build a move for your character, you should associate it with a state: crouching moves, jumping moves, running moves become then separate entities which are not talking to each other — unless instructed to do so!

Let’s suppose you have a simple punch move, associated with a press of the punch button. This move has to work only in the standing state. Then, good news! If your character’s state is not matching the required one you can avoid checking it altogether! Also, you can create moves which share the same input but are performed in different states.

*Same button, three different moves: the power of state machines!*

A simple check on the character state will help you reduce the searching domain and allow for higher flexibility in defining the moveset.

Also, you will be able to create moves which make a smooth transition between states, allowing for a wider range of combos without having to introduce more complicate inputs.

Phew, it’s enough for this step! See you to the next article! If you have questions or requests, you can contact me on Twitter (@AndreaDProjects) at any time!