As someone who considers himself an avid fighting game player, it was inevitable to develop a fighting game system. I have set out to develop an easy to use and streamlined tool that can aid in the development and fast prototyping of 2D beat 'em ups and fighting games. Information about the requirements and how to create robust systems for these games is quite scarce. But I was able to find some resources that deemed very useful in my endeavour to create tools and an adequate combat system. You can read more about this further down the page.

  • C++
  • Unreal Engine 5
  • Scripting engine for composing behaviors with instructions
  • Input buffer system for various input commands
  • Hitbox editor
  • Fighting game-esque physics system
  • Plugin for Unreal Engine 5


  • Akli Lounès Touati

Why develop scripting tools?

High-level scripting is very important in game development. It can enable people to create content for a game even if they are not comfortable with programming. It can also save you a lot of time. You want to be able to easily add, modify and remove logic to parts of your game without waiting for a compiler and having to think too much about it. This is especially true for beat 'em ups and fighting games. Characters in these games have a lot of states. In some games, the number of states per character is easily in the hundreds or even in the thousands. There is an average of 20 playable characters in fighting games. These characters need to be programmed and often fine-tuned on the frame. This process takes a lot of time. Doing this in a low-level language like C++ is very counter-intuitive.

Timelapse of me recreating part of Ryu's move-set in this framework in roughly an hour.

Why Unreal Engine?

I am aware that Unreal Engine is mainly used for 3D game creation, but I noticed that many modern triple-A fighting games are made using Unreal Engine. This made me very curious about the engine and I wanted to learn more about it.

The Input System

Input in a fighting game is very important. Players must be able to buffer input for leniency and complex commands. The tech for doing this is called an input buffer. An input buffer stores player input in a list. This list has to be parsed to deduce what action the player wants to do. It is kinda similar to pattern recognition, timing plays a huge role in an input buffer. You must differentiate between many different types of commands (Adjacent commands, charge commands, mixed command, etc). I have written tools and helper functions to define input conditions and parse the input buffer.


Easily define input conditions for actions.


The Scripting

By now you have heard the term scripting quite a few times. For this framework, I have developed a scripting engine inspired by Mugen and the scripting engine used by Arc System Works (which you can learn about form this resource by dantarion). The behaviour of a state is composed of small pre-defined functions called instructions. UE4's blueprints are a good fit for defining these instructions. Instructions are stored inside tables. Tables define which instruction needs to be executed at which frame. When a character enters a new state it can query the table for which instruction to execute. Having all data separate makes it easy for characters to share behaviour. This is also the reason why you see lots of games have clone characters. You can easily develop characters based on other ones because the data already exists. No need to write new logic. Just adjust the already existing ones.

Instructions are blueprints. You can write any kind of logic you want and have it executed by a character.


The table editor for creating hitbox and behavior data.


States can be easily composed from tables and instructions.

The process

Beat 'em ups and fighting games look like very simple games to make, but looks can are very deceiving. It is true that these game do not have a large number of different systems, but rather have deep and dense systems that are intricately connected with each other. If something about a system is wrong the whole just falls apart. That is why proper planning was crucial for the development of this tool. I made sure to work out UML diagrams. This was very helpful because the editions of new systems are likely to conflict with existing ones. UML gave me a nice overview of how the current systems are connected to each other. This spared me a lot of time not rewriting systems because of inconsiderate design choices.


Future plans

This is the first time I have created a robust system for 2D combat. I have learned how to manage lots of nested data, design a pleasant workflow and plan my architecture in advance to save my self a headache refactoring code. I am currently working on my own engine specifically catered towards fighting games. I am planning on creating externals tools and a domain-specific language for behaviour scripting. These tools are used to create character files. This way you can have logic independent of your game engine. I also want to dabble into networking so that I can implement rollback networking into my engine.