Axecutioners
Technical/Gameplay Designer
Product Owner
Axecutioners is a simple, slow paced fighting game that delivers satisfying gameplay through the strength of its attacks and simplicity to learn
Started with a team of 7 people from September-December 2022 before growing to a team of 13 and continuing development January-May 2023
Made with Unity and FMod
Designing
Axecutioners
Axecutioners started as a fighting game with comedically oversized axes whose impact feels incredible. From there I prototyped many different mechanics and came up with the core of the game. Because the weapons were so large, the attacks had to be slow to sell the impact that they have, but this came with a problem. If our attacks are so slow, how will we make a meaningful combat loop with attacks and responses that doesn't just make waiting for your opponent to attack and then punishing them the only optimal strategy?
To solve this problem we designed the attacks to innately counter
each other. In the gif on the left you can see an early representation
of this. The game has three attacks that function as a rock, paper,
scissors. The low attack ducks down and is a quick strike. The medium attack does more damage than the low attack but will swing over it. During the high attack the player jumps into the air before delivering a massive strike to their opponent, jumping over the low attack but being slow enough to be caught by the mid attack. This core gameplay loop was an excellent start but was too simplistic to produce a fighting game that felt good to play. There was too much of that rock, paper, scissors in this prototype and not enough gameplay or ability to outmaneuver your opponent.
Axecutioner's Concept Art
The High Attack countering the Low Attack
Blocking
The game was missing was a defensive option. We had offensive options that countered other attacks but if all the player could do was attack it once again got down to choosing an option and hoping. I started with two different styles of blocks, a quick reactionary parry and a slow committal block. I did not expect the parry to work with our game due to the slow nature of attacks, but I still wanted to try it to see if there were any ideas we could take and iterate on. For these prototypes I used colors to distinguish between the different states the player entered.
For the slow block, the player would press the block button and enter half-block, light purple, which reduced the damage they took from attacks. If they held this button for long enough, which was longer than attacks took to come out, they would enter full-block, dark purple, which would make them entirely immune to damage and knockback. This was fantastic but there needed to be a way to counter this which led to me prototyping a guard break, yellow.
The slow block system was excellent for our game as we wanted actions to be slow and deliberate, but it came with its own problems. For one, the entire game had to be designed around attacks doing one less damage. This was because players could press the block button and get the half-block up reducing the damage they take by one no matter which attack was used. This made the low attack not very appealing as their opponent could just half-block and negate any damage.
​
Players got confused once more art was added because of how the animations lined up. Some players would hit a high attack that normally kills in one hit, but because of half-block would only do two damage. One the flipside, some players would get hit when they thought they were in block creating more aggravation. This made it clear something needed to change, so I got back to prototyping and redesigned the block. This new block needed to fix as many of these issues as possible while not introducing problems of its own.
The parry is very similar to the slow block but in reverse. When the player pressed the block button they would be placed into the parry state, dark purple, which would render make any attack deal no damage or knockback. After this, they would be placed into a blocking state, light purple, that reduced knockback and the damage by one. Both the block and the parry could still be effected by the guard break, yellow.
Player getting hit due to confusing animation
Dashing
While I was concepting for the new block, we added a dash to our game allowing players to move around more. Axecutioners is purposefully slow but the low walking speed was beginning to cause issues. The dash was there to add energy to the movement without cranking the walking speed to a point that it would have been difficult to balance around. There were other balance considerations for the dash such as how it could be used as a defensive option by dashing out of attacks. The balance we settled on was to make it fun while not voiding all attacks via movement.
The dash got a lot of positive feedback from testers as it made the game feel much more energetic even if the movement was only slightly faster than walking due to its startup and end lag. Players also enjoyed dodging out of attacks as it felt much more dynamic than the slow wind-up for block.
Further Iteration
The new block I prototyped shared a lot of similarities to the slow guard, but had two key distinctions to insure that it felt good to use and was more understandable. The first of which was that half-block no longer reduced damage. This would take away the frustration that players were feeling when their attacks would not do as much damage as they expected or when they took damage when they thought they were in block.
A second change to the block allowed players to move once they were in full-block. This was needed to ensure it felt satisfying as it could no longer be used as a reaction to an attack but instead must be used before the players were in attacking distance. The ability to close the distance while being in the block made approaching the opponent much safer but this was not implemented without other balance considerations.
The first one is making sure the guard break that was already in the game still was appropriately balanced with how the new block worked. The biggest change that got added is a blockstun which stunned for the blocking player for short time when an attack hit their block. This stun time was far shorter than the amount of time it took to recover from an attack but it allowed us to make different moves more or less effective against block. Through several iterations of prototyping I was able to balance the game in a way that made the low attack hard to punish when hitting the block, while also making the high attack not just kill the player using it when the other player was blocking.
Even with all of these changes, players still preferred the dodge to the block as it felt much more dynamic to use. The block was balanced but not fun so we decided to cut it as we still had a defensive option with the dash. I spent much more time focusing on the balancing the dash against the different attacks making it slow enough that the player could still be hit by the fast attacks and quick enough that the damaging attacks could still be dodged out of. This decision reinforced the strength of our attack triangle with the lower damage attacks being less risky while taking a risk can give a massive reward.
Reflection
My experience designing and prototyping this game reinforced how important iteration is. The biggest example I will point at is how we approached a defensive option for the game. It started as a pair of concepts of which the one that matched our game better got picked. From there the functionality was good but once art got added it got confusing and we needed to redesign it. I even prototyped other additions to it like a perfect release that rewarded players for letting go of block right before an attack would hit them. This turned out to not work well and was confusing for new players trying to get into our game. Then we decided to remove blocking entirely due to how players enjoyed dashing more. Through all of this iteration I was able to prototype and mold the mechanics of this game into what they are now. While almost all of the mechanics fit the game during its whole lifespan, it only got better through this iteration and we were able to select the best version that would allow for the most fun for everyone.