General Combat Design

I joined Weird Hat Fight after the prototyping stage had been completed. From the prototype, it was clear the game had promise, but there was clearly something missing. The initial format of combat in the game was that each player had a single life, and 100 HP. Hats (which each had an ability tied to them) could be picked up and discarded at will, and each hat primarily did damage (with no other significant effects). Once a player's HP hit zero they were eliminated, with the last player standing being the winner.

​

When I joined the team and began operating as the Lead Designer, the first thing I did was playtest the game extensively, and play it in various different ways. I then identified the areas where I thought the combat had the most problems:

1. Hats had nearly no practical differentiating factors.

2. The combat felt unresponsive.

3. It was extremely easy to continuously damage a player without interruption until they were dead.

4. Players would typically find their favorite hat and keep it forever.

5. When two players attempted to pick up the same hat, the one who didn't get the hat had a nearly insurmountable disadvantage.

6. It was extremely difficult to keep track of health when there were more than two players in the game.

​

After identifying these problems, I set about trying to fix them. The first thing I did was to try and address problem #1, as it was the most significant problem. After looking at the systems available as a whole, it became quite apparent that the problem was that hats could fundamentally only ever do one thing: Do Damage. They could change the amount of damage, how easy it was to hit enemies with the ability, and the cooldown, but fundamentally there weren't enough unique ways to do damage in the games system. That left me with two options. Firstly, I could focus on attempting to differentiate the various ways to do damage. When I looked into this, it became clear that doing this would probably require shifting the target audience, as the options available would require more skillful expression to interact with than a party game generally expects. The clearest example of this would be fighting games, which often include dodges that put an emphasis on timing. In fighting games, attacks vary their timings and some attacks may take longer to execute to allow the enemy an opportunity to dodge and counter-attack, while others might be shorter to prevent this from happening. However interactions like this require significantly more skill expression from the players than I felt fit our target audience.

​

The second option was to add another output to the hats other than damage. This was the route I ended up going, as the goal was to create a party game, which necessitates a low skill floor. This new output had to still be targeted towards defeating your opponents, which significantly limited the options for what it could be. Given that the game already included a mechanic where falling of the stage resulted in instant elimination, I leaned into this and made knockbacks the other output besides damage.

​

Introducing knockbacks to the game and attaching them to all attacks solved a lot of issues. It firstly solved problem #1, as it drastically increased the problem space. Not only could I vary both the damage and the knockback strength of attacks, I could also vary the knockback direction. Additionally, adding knockback solved problem #2 (since there was an immediate visual reaction to getting hit) and solved problem #3 (since attacks could be made to knock enemies out of range of a followup).

​

Despite this, adding knockbacks introduced a new issue. You could defeat an opponent by lowering their health to 0 or knocking them off the edge, but these two mechanics felt unrelated. If you knocked an opponent off the edge, you didn't care if they were at 1 HP or 100 HP. Likewise, if you wanted to reduce a player to 0 HP you didn't care about the knockback mechanics at all. To solve this, I took inspiration from the Smash Bros series and replaced the health counter (which counted down) to a damage counter (which counted up). I removed the death condition upon taking too much damage, and made knockback force stronger the more damage you had. Doing this also had the side effect of solving problem #6, as now your health was significantly less important (so losing track of it occasionally was acceptable). This resulted in attacks having the following balancing levers for the problem space:

• Damage Per Hit

• Base Knockback (Amount of knockback applied regardless of the damage level of the player hit).

• Growth Knockback (Amount of knockback applied per 100 damage already on the player hit).

• Launch Angle (The angle the player is knocked back in).

• Attack Startup Time (How long it takes for the attack to actually generate a hitbox after the player presses the button).

• Attack Duration

• Hitbox Shape

• Attack Range

• Attack Cooldown

​

The next issue was that players would pick up their favored hat then keep it forever. While playtesting, I discovered the game was the most fun if players were required to swap hats often. While the intention of the original designer had been that the hats should be good at different things, and thus there should be reason to swap, I found that it was difficult, if not impossible, to design for that. The major reason players were never incentivized to swap hats for one that was better in a given situation was that the situation was always the same. There weren't enough variables changing in the game environment to make some hats better or worse. Rather than make the situation the players were in change wildly over the course of a match (which I judged would make level design significantly more time consuming, no matter what implementation method I chose), I decided to instead force the players to change hats. To do this, I added either a maximum number of uses, or a maximum use time (for hats with a continuous effect) to all hats. After being used too often, the hat would expire and the player would require a new one. This solved this problem well, and in testing I found that players enjoyed the game the most when they were required to constantly swap hats (receiving only a single use out of most hats).

​

The last problem remaining was problem #5, where if a player was stuck without a hat when their opponents had one, they were nearly guaranteed to lose. The solution to this was fairly easy, I added a attack that players could use when not wearing a hat. This attack was weaker than any hat, but lessened the gap between players with hats and those without.

​

After all of these changes, I dived back into playtesting to identify new pain points. I was pleasantly surprised to find very little. There were two major issues I identified:

• More experienced players became frustrated at their inability to do anything when knocked off the edge.

• The games ended too quickly.

​

To fix the issue where the games ended too quickly, I first tried decreasing knockback scaling in order to require players to apply higher damage amounts before knockback began to become dangerous. While this had the intended effect of prolonging games, it made them feel like a slog. I reverted this change and instead chose to give each player a number of lives, only eliminating them when they ran out of lives. This felt much better, and solved the problem.

​

The other issue was trickier. It was clear that it was frustrating to be knocked off the edge with no possibility of recovering, but most solutions to this problem caused other problems. If players were given the ability to easily recover (for example, by having a single air jump after being knocked back) then it became extremely hard to actually defeat another player and became frustrating to play for the opposite reason. After several failed attempts, I came up with an idea: What if you could recover, but it cost you something? Once I had that idea, I quickly found a solution that was satisfactory. By dropping a worn hat while in the air, the player performs a strong air jump, giving them a chance to return to the level. This works fantastically, due to the following attributes:

• It emphasizes periods of strength and weakness (as not having a hat means you lack the ability to recover).

• Recovering still has a cost, so it feels better to the attacking player.

• It is less accessible to new players. This turns out to be a boon in disguise, as it creates the feeling that there are  techniques to learn and there is room to improve (all while not actually providing too much of a benefit to players able to execute it, as they are still at high damage and likely to just be knocked off the edge again).

​

After these changes, I performed more playtesting and found no more major pain points. This combat design is what is used in the final version of Weird Hat Fight.