Night of the Spook - Thoughts on Balance
Hey folks!
We wanted to share our experience of trying to balance our entry Night of the Spook as the jam was winding down.
On Sunday night, we had all of the pieces of our game ready: - player controls - enemies - spawning off camera - combat equipment - upgrades - art assets, sound effects, and music - most of the map complete
It was time to start bringing these pieces together to make a coherent and enjoyable experience from start to finish.
What do you mean we have to balance our game!?
But we felt a slight twinge of panic as we looked at all of these pieces, all of the various levers we had to tweak, in order to bring some semblance of balance to the game.
As the clock crept closer and closer to midnight on Sunday, we knew we had a few constants we could rely on to base our balance around
Enemies
|
| 
|
|
|------------------------------------------------------------------------------------|---------------------------------------------------------------|----|
|
|
| 
|
We had create a pool of 6 enemies to pull from (plus a secret mystery boss), and we wanted to utilize all of them.
Game Length
For Ludum Dare games, we try to target 5-10 minutes for the player to experience every mechanic the game has to offer in one play session. Since we had 6 enemies + 1 boss, we targeted 7 minutes. This way we could keep the game fresh by adding something new every minute.
Upgrades
We had created three different types of equipment, each with three stats and two levels of upgradability. The player's main weapon (the Spookbuster) also had three stats and two levels of upgradability. 3*3*2 + 3*2 = 24 possible upgrades. We wanted gameplay to feel different between runs, so we knew we didn't want the player to be able to reach level 24 in a single run.
Beam Damage
During development, we arbitrarily decided to set the player's beam to 2 DPS. We decided to stick with this value as an anchor for future numbers.
Player Health
For simplicity, and to soothe our increasingly melted brains, we decided to set the player health to 100.
These constants gave us enough of a foundation to balance the gameplay around. From there, we want to planning out these 7 minutes: how enemies would spawn, which enemies would be (relatively) more powerful than others, which enemies would be faster, where they would spawn, etc...
Spreadsheet Balancing
By this point it was Monday morning - we only had a few hours left, and we had roughly sketched out timings and power rankings the night before. We were happy with the general flow, so we went to the spreadsheet.
We started off by setting damage and health stats for our enemies based off the power rankings from the night before. Since we knew the player health was 100, and did 2, 4, 8 DPS depending on their upgrades, we had a solid foundation to assign some values. We knew we didn't want enemies to be as fast as the player - during early playtests, we found that to be incredibly frustrating, so we had a speed ceiling. We also decided to link attack speed with movement speed, so that removed another variable.
We added a DPS column to make sure none of our stats (damage, attack speed) ballooned out of control. To calculate a enemy's experience value, we multiplied their health by their DPS. Why? Well, because we felt like it! This entire exercise was the blind leading the blind, but in practice this ended up to work out okay.
Once we had a table of stats, we could implement them in Unity and play around for a bit. We tweaked enemy speeds here and there, lowered the health values of early mobs so the player could kill them more easily, but were relatively happy with how things turned out.
Wave Progression
Once we had numbers we were happy with, we had to design the waves. We decided on 7 minutes until the game's boss spawned, and we broke those 7 minutes into 1 minute chunks.
From our discussion the night before, we knew we wanted to introduce a new enemy approximately every minute. We created a table where we sketched out how many enemies would spawn per wave: this would be broken down further in practice, where enemies would spawn in mini waves every X seconds and the new unit would be introduced at the X:30 mark. By this point we had been playing a lot of our game in test scenes, so we had a vague idea of how many units we wanted on screen in the late game, and we knew we wanted a gentle ramp-up to that point. To be honest, the exact numbers we put in this table was almost entirely vibes.
We also created tables that tracked the amount of experience gained per enemy type per wave, as well as a table tracking maximum wave experience + total accumulated experience. When we were happy with the numbers, we moved on to calculating the experience curve.
Going back to one of our previous anchors, we knew we had a maximum of 24 upgrades, and we didn't want the player to experience them all, so each run could feel different. We decided to target a player level of 12 around the time they got to the boss. So we create a table that tracked per level XP requirements as well as total cumulative XP required. We then charted this graph and the previous table tracking possible XP gained per wave. With the "max possible XP over time" serving as our anchor, we could tweak the values in the level XP curve until we were happy with how they tracked each other. This also allowed us to set level targets per wave, ensuring that the player felt consistently rewarded.
Final Thoughts
Ultimately, we had very little time playtesting our spreadsheet balancing, as the deadline was rapidly approaching. I believe only one of us finished the full 7 minutes before we submitted, but we felt really happy with how the numbers ended up feeling through short play sessions. Being able to visualize much of the balance in a single spreadsheet and see how one number change can propagate throughout the spreadsheet really helped.
Did it work? I think so! As a team, we played our game a bunch after submission, as we were just have a genuinely good time playing it (which has not always been the case with our previous games). We had runs where we won, runs where we almost won, and runs where we got utterly wrecked. We have comments ranging from "game's too easy" to "game's too hard", "beam's too weak" to "beam's too strong", "equipment's too weak" to "equipment's too strong", which in a way tells me we did okay. :smile:
If you have interesting thoughts on balance to share, please leave them in the comments or make a post of your own! Balance has always been a great boogy man we leave until the last minute, and it would be great to learn how others approach it.
It's been almost 2 weeks since the end of the main work and the moment when we started to finalize the game. While we were away, we didn't stop working. Many bugs have been fixed. Unfortunately, we didn't have time to add all the cool things that had already been worked out. It is a pity that there was not enough time for this. Nevertheless, we really worked. We have an improved version of the game ready, which you can evaluate.
Until then, please continue to rate 