I wanna make a fighting game! A practical guide for beginners — part 8

Andrea "Jens" Demetrio
8 min readNov 9, 2021

Hold back to block — a primer in building defensive interactions

After a seventh entry completely revolving around offense and — more specifically — how to build a sound combo system, this week we tackle some principle of defense, from an implementation point of view. So, steel your reflexes, tap forward with the right rhythm and perform that Daigo Parry while giving your players some tools to thwart the opponent’s pressure!

LET’S GO, JUSTIN! — note that in this article I won’t explain how to implement a parry, as this topic deserves an article on its own due to its complexity and implications.

No blocking in this venue

Before we delve into the topic, a due premise: fighting games do not always NEED to have a block/guard/parry option. Games like Dive Kick and HYPERFIGHT show — if anything — that you can make a fun game without having to implement nothing more than attacks and movement options. However, most fighting games out there, even the simplest, are bound to have access to some sort of defensive option. The two examples above use movement and positioning as a way to avoid the opponent’s attacks, while more traditional games opt to implement a guard/block system — that is, a system that allows a player to avoid part or all the damage of an incoming attack by pressing a specific button.

HYPERFIGHT has no block, every attack must be avoided by carefully dodging and dashing around the screen. This doesn’t prevent it from being a fun multiplayer experience. [1]

Walk back or press a button?

There are two different schools of thought on how to input blocking in a fighting game, and two other different schools of thought on what kind of block should stop what. Before delving into technical details, let’s review the current state-of-the-art and the different approaches to how blocking should work and interact with the rules of the game.

The first big distinction is having a “dedicated block button” versus allowing the players to “hold back to block”. Most 2D and 2.5D games nowadays default to the second input systems, allowing players to fend off attacks simply by holding the back direction while their character is standing or crouching. This paradigm has one significant exception in the Mortal Kombat series, which always made use of a dedicated block button that needs to be kept pressed down to block attacks.

In 3D games with emphasis on free, 8-way movement, the dedicated block button is more prominent, being used in most of the main 3D franchises, with Tekken being the one outlier.

There are also games which allow for both holding back and using a dedicated button, such as Granblue Fantasy Versus and the Dead or Alive series.

Both schools of thought have significant representation, but the number of games which default to “hold back to block” are SIGNIFICANTLY more than those which implement a block button, at least in the traditional fighting game design space.

Before going on, please notice that there is no one “correct” solution. Your decision should be based on what you and your prospective players are more comfortable with, but it’s most times not a deal breaker. As a rule of thumb, though, remember that 2D games usually favor “hold back to block”, while 3D players are more accustomed to block buttons.

The main advantage of holding back is that it might be simpler or more intuitive for new players; the advantage of having a block button is that, if you plan to go for 8-way movement, you can use the block button to map actions like jumps and crouching without disrupting the fluidity of the motion.

All mids are overhead. No, wait, actually not!

The second big distinction is centered around “what kind of attacks should each type of block stop”.

Attacks in fighting games tend to have different “heights”, which is roughly related with which part of the opponent’s body they are going to hit. Low attacks are aimed at the legs, while mid (short for “middle”) attacks hit both crouching and standing opponents. High attacks have historically held two different definitions, depending on the game: in some, the label is used to define all attacks that can defeat a crouching block, in others, it is used to describe attacks that cannot hit a crouching opponent. In the first case, they are also called overhead attacks, to further up the confusion.

Yet another distinction: what should block what? The division between 2D and 3D games is actually pretty easier to spot for this specific point. A caveat for the plot: With the exception of Mortal Kombat 9, where all Mid attacks must be blocked while standing, all other Mortal Kombat games align themselves with the above chart.

Definition of high attacks aside, the philosophical divide is now between what is the default/preferred block state. In all games where mid attacks can be blocked even while crouching, crouching block is the “go to”. This is how it works in most modern 2D and 2.5D games. In game where mid attacks cannot be blocked while crouching and low attacks do not yield as much reward, the “go to” block is the standing block. All major contemporary 3D games follow this approach.

As for the “hold back to block”/”block button” discussion, there is no correct solution and it all depends on how this decision mingles with the rest of your design choices — so, feel free to go for the one you prefer.

Implementing a simple block system

[An important warning: the pseudocode presented in this chapter is extremely simplified and not completely suitable for implementing proper game logic. You might want to check your character state and store the block status for ease of retrieval, or delegate everything to another function altogether. The listings below are by no means executable code and are just meant as a guide to understand the logic behind the process!]

A simple implementation of a block system can be expressed by the following pseudocode.

In simple terms, you can check if your block button of choice (either a dedicated block button or the Back direction input) is pressed by the player, while the character is standing or crouching. Of course, this is not the whole story: with the above implementation, a block state would be triggered just by virtue of pressing the button, no matter what else is happening on screen. This is perfectly fine for the “dedicated block” solution (Soulcalibur and Mortal Kombat work exactly like this) but it’s not at all practical for games where block is tied to a direction.

The easiest workaround to this issue is adding one additional check on the opponent’s status:

By checking if the opponent is performing an attack while your character is trying to block, we can trigger the state — and the respective animation — only when needed.

Of course, there is yet another issue with the above: if you are a full screen away from your opponent, and they just mash an attack on repeat, your character will start guarding even if there is no immediate threat, as soon as the back direction is pressed and the opponent hits that button. To solve this, we can resort to using something called “proximity guard” — that is, triggering the block animation only while the character is inside the effective range of the opponent’s attack.

Triggering a block only during collisions

There is an alternative to all of the above — which is, checking for the block button only when an attack connects with the opponent. This is how games like Tekken work, not stopping your character in their steps until there is a collision to be processed. This method can be also used in conjunction with the simple block implementation shown before, as one doesn’t necessarily exclude the other. By borrowing a page from my previous article about combos and hit stun, this is how the pseudocode might look like:

You might have noticed that even when the block is successful, we activate what in the pseudo code is called “block stun”. Block stun is conceptually almost the same as hit stun, except it is only applied during a successful block and is — usually — shorter.

Block stun is used to fine-tune the interactions between attackers and defenders. Without it, the defender would be able to move as soon as they let go of the block button, thus making every attack unsafe, even if correctly spaced.

Block stun is extremely important and must be set wisely. Too much, and you will have endless offense going on, too little and every attack will be punishable with complete impunity.

Chip damage — what is it and why it counts?

While browsing through the pseudocode listing, you will also notice something called “chip damage”. This is essentially damage that is dealt even when an attack is blocked and is — again, usually — only a fraction of the normal damage output of the move.

Chip damage has been historically a staple of every Mortal Kombat game, almost totally absent in 3D fighting games, and relegated to special and super moves in most other 2D/2.5D games. In some of the most recent entries, chip damage cannot cause a K.O., unless it’s from a super move.

I won’t spend many words on the legitimacy of removing “chip kills” outside of super moves, as there are good arguments both in favor and against it, so you will need to choose for yourself depending on the feeling you want to achieve for your game.

In Street Fighter V, only super moves can cause a K.O. when blocked. Special moves won’t K.O. the opponent on block, even with one single pixel of health left.

Advanced blocking options

Some games offer additional or complementary blocking options, either tied to resources (e.g. Faultless Defense in Guilty Gear, which nullifies chip damage among other things) or to precise execution (e.g. Parries in Street Fighter III, where the player has to tap forward as the opponent is going to connect with their attack in order to cancel its effects).

These are all welcome additions, but require additional scrutiny and explanations that deserve an own article and will be probably tackled in the future in this very blog!

Summary and conclusions

This time, we went through the absolute basics of a block system, going through a simple implementation for both “hold back to block” and “dedicated block button”. We have seen how to deal with blocks during attack interactions and spent some words on chip damage, block stun, and more advanced blocking options.

In the next issue, we will tackle the topic of grabs and throws — which was highly requested because of its less than intuitive logic steps!

Notes, credits, and additional useful material

[1] Game: HYPERFIGHT (PC), screenshot from my previous article on the game: https://andrea-jens.medium.com/hyperfight-or-how-i-learned-to-stop-blocking-and-love-a-frog-4fc0bb191db6

[2] Infil’s fighting game glossary: https://glossary.infil.net/

Other articles in the series

  • Part 1 — Introduction;
  • Part 2 — Design decisions;
  • Part 3 — Characters as state machines;
  • Part 4 — Hitboxes and hurtboxes;
  • Part 5 — Determinism;
  • Part 6 — Input buffers and “reading” moves;
  • Part 7 — Hit stun and combo systems;
  • Part 8 — Implementing a simple block/guard system;

If you are interested in more game-making tutorials, you can find me on Twitter at @AndreaDProjects. My DMs are open!

--

--

Andrea "Jens" Demetrio

PhD in Physics, indie game developer, fighting games connaisseur (he/him).