Major Project Blog - Hachiman
- May 8, 2025
- 9 min read
Over my final year of my Games Design degree, I developed a 2D one-on-one fighting game, known as Hachiman. In this blog, I will discuss the creation of the game, mainly through design and scripting, as this is my focus in Games Design.
Pre-Production
I knew when coming into this project that I wanted to create a 2D fighting game. The fighting game genre is one I’m passionate and knowledgeable about, so I was excited to create one myself. However there were two central challenges in creating my own fighting game; a unique selling point and scope.
I needed a way for my fighting game to stand out from competitors, and after researching other fighting games, I decided to do this through my health system. Taking inspiration from games such as Pocket Rumble and Fantasy Strike, I decided to implement a health bar system of chunks, rather than a traditional health bar. This would make deciding damage values on attacks a lot easier, as health could be removed per chunk, rather than having to decide through a much larger number, as many fighting games use health values around the one thousand mark. This makes the health bars a lot easier to read at a glance.
I also then decided to look at the Killer Instinct series, and use a system inspired from their potential damage system, where recoverable damage can be built up over time and then cashed out to do permanent damage. I would then implement this into my game by making normal, safer attacks do “grey” damage, and riskier special attacks could do permanent damage that would also remove all the grey damage. However, you could also recover health over time if you don’t get hit.
Scope was important to determine for this project, as trying to do too much could lead to a half-finished project that suffered as a whole. How many attacks a character has would affect how long each character would take to develop, and figuring out how many characters could be created for the length of time I had for this project was important. I also had to consider the audience I wanted this game to be made for.
I eventually decided on making the game relatively easy to pick-up and play, so each character would have a grounded & aerial light, heavy and special attack, as well as a grab, giving each character 7 attacks to use. I also decided on having a minimum of four playable characters to use, with additional characters being able to be added as a development stretch goal if I completed them earlier.
I decided on these four playable characters being based upon four common fighting game archetypes; the all-arounder "shoto" character, the quick "rushdown" character, the big-bodied "heavy" character, and the range-focused "zoner" character. This would give me a balanced roster of characters for people to use while also letting me research these archetypes for attacks and statistics they’d have.
The choice of using 2D sprites over 3D models came from a few different reasons. I have more experience in working with 2D sprites, as well as not having an artist on my team, nor being an artist myself, it was easier finding unique assets that could be adapted into a fighting game that came in the form of 2D sprites. Also, as these sprites are split up, it would be easier to edit around the sprites in Unreal Engine’s flipbook system to make attacks slower or faster, recover quickly or slowly, allowing for customisation of the sprites I had. Sprites also could be spliced. This was most commonly used in Hachiman’s development to create jumping attacks and grabs, as the sprite sheets I used for the game’s development did not come with these.
With the assets I found, the game ended up taking a Japanese samurai aesthetic, as the character and stage assets that had enough creative freedom for sprite sheet usage and splicing were of this aesthetic. This is where the name for the game, Hachiman, came from, as this was the name of the Japanese deity for war in the syncretism of Shinto and Buddhism.
Implementing Fighting Game Mechanics and Standards
Developing the mechanics of the fighting game was a challenge, as I’d also have to develop my first character around these mechanics. Many fighting game norms had led to heavy adaptation of Unreal Engine during Hachiman’s development.
I decided on what actions a player could take alongside their attacks. Different fighting games have numerous ways to move around the stage, such as walking, dashes and jumps. I mapped dashes to a separate button on the gamepad’s shoulder and also allowed players to dash jump, where if they jump during a dash, they get a larger boost in momentum than they would have just jumping regularly. This was to give characters a better ability to close the distance against their opponent, especially if you wanted to approach your opponent who was playing defensively. I also included both a block button, and the traditional 2D fighting game option to block by holding backwards to the direction your character is facing. Some fighting games, like Street Fighter use back-to-block, others like Mortal Kombat use a block button, and some such as Granblue Fantasy Versus allow players to use both. I decided to include both, as they both can give an advantage to the player. Holding backwards can allow a player to retreat with movement while also blocking, while a block button allows you to block even if the opponent crosses over to the other side and lets you block while not moving.
Character movement stats were something that had to be edited compared to conventional movement in other genres though. Fighting game characters stop and start on a dime, have no air acceleration or deceleration when they jump, and their jumps are limited to three directions; jumping straight up, to the left and to the right. These all were things which would have to be edited in order to get the correct feel of a 2D fighting game.
Some things were much harder to implement however. Namely, walls. Fighting game maps usually have walls at each end of the map, making playing near the corners much riskier, as you eventually run out of space to back away. However, in development, I was having continual issues where a player would get stuck in-between a wall and the other player. Having issues with fixing these walls, I turned to research other fighting games and came across Soul Calibur. Soul Calibur’s stages lack walls, and instead players could be knocked off of the map to lose a round. This was a lot easier to implement and also more obviously showed to new players that playing near the corner of the stage would be more dangerous than a wall typically would, as a newer player may not be able to exploit the advantage of their opponent being against the wall.
Implementing attacks was done through the use of Anim Notify States, although use of the PaperZD plug-in was necessary to have access to these for sprite flipbooks in Unreal Engine, as normally this is only accessible for 3D models without PaperZD. Using Anim Notify States, I was able to determine where hitboxes for attacks should be placed, and in combination with Animation Blueprints and Animation Sources, how long an attack should be active for, or give additional effects to the move, such as projectile immunity or moving while attacking. Anim Notify States were the key part of the game’s development, as without the use of them, the attacks in Hachiman would not have been able to have the level of individuality or customisation that makes each attack shine in a different situation in a fighting game.
The health system was a key aspect of the game so developing it, and fleshing out its mechanics was important. While there was a basis upon conception of the health bar being composed of chunks, and temporary grey damage could be “cashed out” in order to deal real damage,
Characters
Each character would share universal attributes, such as 8 health chunks, a consistent speed when dashing and a 4 frame jumpsquat, a period where characters in fighting games have a delay before they jump, both for balance and for characters to feel more realistic. But character walk speed, fall speed and jump height all were changed between characters to make each character move and feel different from each other.
Deciding on each character’s special moves was difficult, while the Shoto character, later named Shogun to fit with the game’s aesthetic, was able to easily take inspiration from the Shoto archetype characters such as Ryu and Ken from Street Fighter have for his projectile special and aerial spinning attack, I had to research deeper for the different options the other character archetypes would have. I looked at different special moves across different fighting games for inspiration for my cast, and listed the upsides and downsides of including them in my game, in particular how they’d interact with the health, control and movement system of my game. For instance, a fast, full-screen beam projectile would be much too strong in Hachiman due to the ease of access for this move and lack of mobility options to get around such a move.
After weighing up options, I decided on what special moves each of the other characters would have. Most special moves in Hachiman can be either directly punished by blocking the move, or avoiding the move and then punishing its endlag. This was done so that a strategy of throwing out your larger attacks in order to do permanent damage to the enemy’s health would be riskier and lead to getting punished yourself. This was further emphasized by the design decision of aerial special moves having extra end-lag once you land with them, making them even more vulnerable if they didn’t hit an opponent.
On the other side of this, normal attacks on the ground could be cancelled into specials, allowing for combos that deal multiple chunks of health in one sequence, and hitting an opponent out of the air even with a normal attack would deal real damage, further rewarding smart use of attacks & strategy, and to dissuade spamming attacks in order to succeed.
Issues With The Game’s Development
The largest hurdle to overcome with my game’s development was the multiplayer aspect of the game. While some aspects of multiplayer were not too hard to implement, such as having two players controlling different characters at the same time, the difficulty came up in designing menus for two players to be able to utilise.
The main issue was the character select screen. While other menus could get away with only the first player controlling it, such as the main menu, or the player who pressed the button gets control of the menu, such as the pause menu, the character select screen needed two players to simultaneously be able move independently in order to select their character. Even a solution such as one player selecting their character, and then the next player selecting their character after would need me to be able to have a widget or UI element both players could access, which I was struggling to figure out how to create and populate.
The solution for this came from ditching using a traditional UI element for this and instead making a level, with unique pawns to act as cursors and and actors to replace the UI elements. While it required some manual work in Blueprinting in order to recreate the functions of scrolling up and down, or selecting a character, once it was created it worked just as well as using a widget for the character select screen.
Due to relying on pre-existing assets for characters and their movesets, a downside was the lack of animations that could be used for attacks. While Hachiman is intended to be a simpler game to play in terms of attack variety, more attacks could have been added in order to spice up strategy and further specialise attacks. In particular, crouching attacks could have been used to create moves that hit as far-reaching, low pokes or specially designed anti-air moves, but the lack of even crouching sprites in these assets led to this having to be scrapped early on. This led to a lot of the normal attacks having to take on more generalist roles in their design, such as serving both as fast attacks and an anti-air at the same time.
Conclusion and Reflection
In conclusion, over the course of development, Hachiman’s identity became clearer and more defined. The game focused on its strengths of being able to be picked-up and played by players regardless of fighting game experience or how good they are at the genre. Features were streamlined so that the learning process of the game are able to be picked up quickly, with quick access to controls and player abilities through menus so that someone can quickly jump into the fray and play the actual game.
The gameplay is the focus and shine of Hachiman so getting to it quickly and having players understand how to play the game well enough to enjoy it was a key goal in the game’s development.
I do wish I was able to flesh out character movesets more, having an artist on the team who would be able to make custom sprites for the game could have developed further depth, while not sacrificing much in the ease of access.
There were additional stretch goals I had planned too, such as additional characters and a game mode with more gimmick-focused levels, taking inspiration from Street Fighter 6’s Extreme Battles, or the stages featured in Super Smash Bros., where additional hazards may interfere with battle. However, I was worried that these gimmick-focused levels’ development would take away from the polish I wanted for the core gameplay, so these were left out. Other additional modes that were planned included a training mode and a playable tutorial, the latter being removed due to it.
Comments