• shane tupler


As I mentioned in my previous devlog, while you are in a Recovery state in a fighting game you cannot take any actions. For example, after an attack you will be in recovery for a few frames. Any inputs made during this time are invalidated and will not do anything. But in most modern fighting games, there is a period of time when the input for an attack can be accepted, even while you are unable to act. This is known as a Buffer Window. Inputting an attack within this window ensures that it will come out on the first possible frame that you can act again and sometimes that means canceling the recovery of your previous attack.

One example of a buffer window is chaining an attack during hit stop. A Chain is when an attack’s recovery is canceled into another attack. Hit stop occurs when an attack connects, whether it is blocked or not. It freezes both players animations for a short period of time in order to sell the impact from the hit. I wanted to achieve this type of buffer window in my fighting game to make the combo a little easier.

Attached are two gifs in which the same attacks are inputted : Light, Medium, and then Heavy.

You’ll notice that in the first example, only two attacks come out, the light and the medium. This is because heavy was inputted too early. An attack can only be chained into (will explain this earlier in the devlog) while you are in hit stop. Since medium is pressed during hit stop, the recovery of the light attack is cancelled, and the medium attack comes out. However, heavy was also inputted during the hit stop from the light attack. Since medium was pressed first, the input for heavy was “eaten” and the move never came out. Even though, the player pressed an acceptable series of inputs, nothing happened, and this could result in the game feeling unresponsive to them. To avoid this, I implemented a system for queuing attacks.

In the second example, all three attacks come out. This is because of the attack queuing system. If an attack is inputted while in hit stop, that move is chained into. If another attack is inputted while still in hit stop, that attack will be held in a queue. Now, after the second attack comes out, the third attack will be chained into as soon as it possibly can.


  • NormalAttack.cs

  • In Directional Input, the forward slash in between the two numbers indicates that either of those inputs can be used

  • 4 = back on the stick

  • 5 = neutral

  • SpecialMove.cs

  • The directional input for a Dragon Punch motion is made up of a forward, down, and then down forward motion or 623

  • I am also allowing for down forward, down, down forward or 323 to make it more lenient

  • CharacterData.cs

  • Holds data for the character's movement such as jump height and number of jumps

  • Also has lists for all of the Normal Attacks and Specials Moves the character has access to

  • I will cover what Uniques are in a future devlog

To see any of these in more detail, check out my GitHub. Otherwise, that is all I have for this devlog. I hope you enjoyed!

17 views0 comments
  • shane tupler

Updated: Aug 12, 2021

[Link to GitHub Repository]

Yep, those sure do look like hitboxes


Bot Brawl is a fighting game that I am working on in my free time with a colleague. We are still very early on and are using placeholder models and animations from Mixamo for testing purposes. I have no prior experience developing a fighting game, but I am a big fan of the genre. I do not expect it to be an easy task, but I believe it will be an educational experience (and hopefully an enjoyable one too).

The game is being developed in Unity and I will be doing the majority of the programming for the project. It is a 2D fighting game and our plan is to take aspects from various different fighting games which we enjoy. It is leaning more towards being an "anime game" in terms of its gameplay, with fast and strong movement options such as a run and an air dash. Our goal is to create a fully-functional experience with just one character to see if our concept works before continuing further.

Before I get started, I'll explain a few basic terms and ideas of the fighting game genre. If anything is unclear, I would point you towards The Fighting Game Glossary by Infil. It is a fantastic resource for fighting game terminology. I myself am using it almost every day that I work on the game.


In simplest terms, fighting games are about reducing your opponent's health to zero without allowing your health to deplete. In one-on-one fighters, you win a round by reducing your opponent's health to zero. If you win two rounds, you will have won the game. Fighting game characters have access to normal attacks at the press of a button, special moves which are activated by a motion input and a button, and lastly, supers which are only available when you have a certain amount of meter and are also activated by a motion input and a button. You are able to block incoming attacks by holding the opposite direction of your opponent. Overhead attacks, such as air attacks must be blocked while standing (holding back), while low attacks must be blocked while crouching (holding down and back). There are also throws, activated by a single button or multiple buttons at the same time. Throws are a way of damaging a player who is blocking, but they can only be used in point-blank range.


Now onto some of what I have implemented so far. For starters, inputs. My solution for input detection is to get a Vector2 from the player’s thumbstick or keyboard inputs and convert it into a string depending on its values. Then for button inputs, the three attack buttons which are X, Y, & B on an Xbox controller, will become a string of “light”, “medium”, or “heavy”. I considered using an enum for holding the input data, but I decided to go with strings instead because I wanted to be able to easily look for multiple correct inputs for attacks.

This is the “Jab” attack, which you can get by pressing the light button and holding either back or neutral on the thumbstick. There is an attack that is only obtained by holding forward and pressing light, therefore you cannot get jab while holding forward. Other than that, either back or neutral on the stick are acceptable directions for getting a jab. Since this character has only one crouching light attack, it can be activated by holding down and back, down only, or down and forward.

Holding back or neutral on the stick & light
Holding down back, down, or down forward

Something that I am thinking about doing is transitioning the string format for directional inputs to one using ints instead. I am considering this change for two reasons. Firstly, using ints instead of strings would be more performant. While it may not be a huge difference in performance, I want to make absolutely sure that the game is able to run at a consistent 60 frames per second. Also, because other games use this notation to describe different attacks and inputs. Numpad Notation uses the nine numbers on a keyboards numpad to describe the nine directional inputs. It may seem confusing at first, but I prefer it in the long run especially when describing the inputs for a combo. For example, it is far quicker for you to say “2L, 2M, 2H, 236H” than “crouch light, crouch medium, crouch heavy, quarter circle forward heavy”. Most fighting games have their own unique notation, although numpad notation is used in most anime style fighters and so I’d prefer to use it to describe my games inputs.


To finish off this devlog, let me talk about some of the fun stuff… normal attacks and combos. Fighting games need to maintain a consistent frame rate (generally 60 fps) because most actions in game are measured in the number of frames they take to perform. Normals are broken up into startup, active, and recovery frames. Startup frames are how long it takes for the move to become active. Active frames are how long the move is active for or for how many frames your opponent can be hit by it. Recovery frames are how long until you can take another action. Setting this functionality up was relatively simple. When a normal attack is inputted by the player, it starts a coroutine which waits for the appropriate number of frames and switches states between startup, active, and recovery. When it is in the active state it enables the moves hitbox and then when it transitions to recovery it disables it.


After being hit by a move, you are put in a state called hit stun. While in hit stun, you cannot take any action including blocking, jumping, or attacking. Different normals have different startup frames and put you in hit stun for a different number of frames. Due to this, only certain moves can be combo’d into one another. A combo occurs when you are hit while still in hit stun from the previous hit. A basic combo is 5L, 5M, 5H. It is very beginner friendly because you are just moving from one button to the next in order of strength level and do not need to worry about changing your directional input throughout the combo.


Hit stop occurs when an attack connects, whether it is blocked or not. It freezes both players animations for a short period of time in order to sell the impact from the hit. Hit stop is beneficially for adding weight to stronger attacks as well as making it easier for the player to react to their hit connecting. Notice the difference in speed from the version without hit stop (left), and the one with hit stop (right).

Without Hit Stop
With Hit Stop

The slower speed of the hits make it significantly easier to react to the first attack hitting and continue the combo. Plus I think it "feels" much better to watch because the attacks look weightier. I originally set it up without any hit stop, but changed my mind once I tested it and saw how it looked.

Well that is going to be all for my first devlog. In my next post I will be diving deeper into the base classes I created such as NormalAttack, SpecialMove, & CharacterData. I hope you enjoyed and learned something from this.

74 views0 comments