Dev Update #7 – How to Balance a Game – Part 2

While Part 1 of this article explained the basic methods of game balancing, I now want to apply this to an actual game. By the way, if you are interested, I shared the spreadsheet from part 1 on Google Docs. You can find it here.

It’s time to run a first balancing pass over my game design for Game Tower. This will be fun! I feel much more comfortable creating formulas, tables and spreadsheets than creating art. Numbers are my friends. A woman with glasses has her hand on her hips and says: "I'd like me some 3.14159"

In the last week I created a ton of spreadsheets and graphs to tell me if my numbers are reasonable. I will pick two of these and present them in (some) detail here.

Does leveling up punish the player?
As a player levels up in Game Tower, more complex games can be produced. A higher level game takes longer to make, but will also pay more. But will it be enough?

My main concern was that it wouldn’t pay off for the player to create higher level games. If the longer work time didn’t pay a lot more, players would want to stay at a low level as long as possible. Leveling up would feel more like a punishment than a reward. What a perfect opportunity for some pre-implementation balancing! So I created a table that listed the time it takes to complete a game production and the money the game would make in relation to this time.

I work with undefined units instead of actual numbers. This means 1 Work Time unit will give me 1 Money unit – without specifying how many minutes or dollars that actually is. In the final game one time unit might be 15 minutes, and 1 money unit $7. For the math to work out, it doesn’t matter! Once the balancing is right, the resulting functions will work with any numbers I throw in. 🙂

I already knew what to expect, but to check my theory (and to be able to present it here), I started out with a simple linear relationship: 1 time unit would pay 1 money unit. At first my spreadsheet looked like this:

The graph shows that the payoff is perfectly linear to the work time. If the work takes twice as long, the payoff will be twice as much.

The graph confirmed what I already knew, a longer production time wouldn’t pay off (the blue and the red are overlapping perfectly). I needed a non-linear relationship between the work time and the money payoff.

So I added a third column to my table, which would contain a growth factor for the money payoff. In simple words – the more time a game required, the more each individual time unit would pay. I found a curve that would make a longer game production not only pay more, but a lot more than a lot of smaller games. This way it will always be beneficial for the player to level up to be able to produce more complex games for a bigger payoff. Here is the table:

A graph showing the non-linear relationship between work time and payoff. The payoff increases exponentially with the time spent working. If the work takes twice as long, the payoff is more than just double.

The new graph shows how the red line (money payoff) is increasingly moving away (up) from the blue line. The result of this balancing is a simple formula which I can implement inside the game’s code to calculate how much money a game will make, based on how long it took to create it.

By the way, this problem can not be solved by simply increasing the amount of money that a time unit will pay. Any linear relationship between money and time would yield the same result. If 1 time unit paid 5 money units, it still would not make higher level games more profitable.

Why? Here is the explanation:

In a linear relationship between time and money, each hour of work will yield exactly the same payoff. If I get $1 per hour, it doesn’t matter if I produce ten 1-hour games, or one 10-hour game. The payoff at the end would be exactly the same: $10. Increasing that factor does not change that truth. It doesn’t matter if one hour pays me $1 or $5 or $10. It will never make a difference, the payoff will be the same for both scenarios.

In a non-linear relationship the amount of money an hour of work will pay is not fixed, but defined by a formula. The more work a game requires, the more each individual hour will pay.
Example: A game that takes 1 hour to complete, will pay $1 for each hour. But a game that will take 10 hours to complete, each hour will pay $2. Which means, if I make ten 1-hour games, I end up with $10, but if I make one 10-hour game, I end up with $20! In both cases, I have worked 10 hours, but the higher level game pays twice as much!

This is the formula for my work time payoff:

Formula: Money = WorkTime * (1 + WorkTime/100)

Instead of one formula, you can use multiple
One size doesn’t fit all, and that is true in balancing as well. If a balancing formula is great for part of the problem, but not for all of it, it might still be usable.

I ran into this when balancing the prices for building new floors. I wanted the cost of a department to increase with each floor, but wasn’t sure by how much. I started out with simply increasing the price by 50% each time the floor was built.

Following this formula the first Code department might cost $10, the second one $15 and the third $23 and so on. I get a small increase early but a steep increase in prices later in the game, which will entice players to build different departments instead of building the same one over and over. I put this into a spreadsheet and let the table figure out the build costs for building the same floor 50 times to verify my idea:

The graph shows the building cost increase exponentially. It doesn't rise much at all at first, and then rises super fast and super high.

For the first 25 floors, the prices looked OK. But after that the departments became much too expensive (as you can see, they literally went off the chart 🙂 ). But there is no reason I have to stick to this formula for all floors. Once the numbers get too large, I can switch to a different formula:

The graph shows the building cost increase with more moderation. It doesn't rise much at first, and then rises linearly and constantly.

The red line represents the discarded previous formula

The graph looks a lot better now, with the right half of it increasing steadily and linearly. The graph still goes off the chart – but in a much shallower incline. And while my table calculates the cost for 50 floors, I actually consider everything above 25 as late-game. If I get to build more than 25 floors of the same type in my tower, my tower is easily over a 100 floors tall in total.

In this case I went with the 1.5 exponential increase for the first 25 departments, and then after that switched to a linear function, to keep the increase in price reasonable.  I also went through the table and manually edited the prices for the first 25 build levels, using the calculated prices as a guideline, but rounding them to a pretty number. $5023 would be rounded to $5000 and so on.

My game is now reading those numbers from a hardcoded table for the first 25 build levels, and will switch to a linear increase function after that. The function that implements this is only a few lines long, since it only has to look up how many floors of this type exist, and then decide which pricing model to use.

The hidden Spreadsheet
I am cheating a little bit by ending the blog post here. There is a third spreadsheet that I haven’t mentioned yet and am not going to. This sheet takes the data from the two tables I discussed above and combines them. It can give me information about how long it would take a player to earn enough money to build the tower to a certain height.

This spreadsheet is my reality check. While the numbers are only an estimation (every player will build different floors and the order in which they are built is important, too), it can give me a sense of whether my values make sense or not. I will have to play the game to see if the mathematical model actually holds up.

I chose not to discuss that final spreadsheet here, because it would blow up the post even more – and there really isn’t any more to gain from it. It is more of the same: A table, numbers and graphs. Massage the numbers until the graphs look pretty. 🙂

Now the implementation begins!
Stay tuned for some first look screenshots!

Dev Update #6 – How to Balance a Game – Part 1

This is part 1 of my take on game balancing. This post will deal with the what and how of game balancing. In part 2 I will give an real life example, and run through some numbers, formulas and tables for my current game project.

Girl in front of her computer is devastated, because her favourite character class in the game she plays has been nerfed again.

Balancing means adjusting all numbers and values in your game so that they work together well. Here is an example showing what this means and why it is so important:

The Overpowered Warrior
Think of a warrior, a type of game character that commonly has very high values in defense. In a fight with a monster he can take a lot of hits without dying. But on the downside the warrior can only do very little damage, compared to a wizard for example. Essentially, a warrior needs his high defenses to stay alive longer – because he needs longer to kill an enemy. This is in essence how a basic warrior class is balanced.

Without this trade-off between damage and defense the character would become unbalanced. If a warrior had high defenses and high damage output, he’d be overpowered and players wouldn’t play any other class anymore. If he had low defenses in addition to his low damage, they would play any class but the warrior. You want to avoid either scenario.

Balancing on Paper vs. Balancing by Playing
Finding the right numbers for armor, damage, item prices and monster difficulty is not as straight-forward as one would initially think. Most games have more than two values that influence each other. This is what makes Game Balancing a topic all on its own.A scale with not two, but four plates hanging at a perfect balance.

Balancing is important for basically any game genre, from shooters to tycoon games. Does building get too expensive later in the game? Will the upgraded weapons make too much damage and make fights too easy? Does it pay off more for the player if he didn’t level up and kept the monster levels down?

There are two ways these questions can be answered: By playing the game – or by looking at spreadsheets.

Balancing by Playing
Balancing can be done simply by playing the game and adjusting the numbers until it feels right. But there are some downsides to using that as the only approach to balancing.

First of all make sure you are not under the illusion that balancing will somehow work itself out automatically as you go along. Simply playing a game every now and then won’t cut it. You will need to play the game a lot. A whole lot. And then again every single time you adjusted your numbers. You will need to schedule time for this into your development plan. And this is where the first problems arise.

The game needs to be playable first
Since you need to be able to play the game to do this type of balancing, all of the important game features need to implemented first. This means you have to be pretty far in development before you can even begin to start adjusting your numbers.

But the downside of waiting with the balancing until the end of the implementation is that it has a high risk of being skipped or not given enough attention. Time becomes a hot commodity near the end of production, when all efforts are spend on polishing, bug fixing and ramping up marketing. So it a good idea to start a early as possible with balancing.

You need to notice a problem before you can fix it
If a game is balanced only by playing it, you rely on perception to notice unbalanced sections of your game. In other words – you need to notice a problem before you can fix it. But almost every game can be played in several ways, with different strategies. A player with a different play style than your own might find your game terribly unbalanced, even when the numbers work great for yourself.

A blindfolded woman - Justicia - holding up scales. The blindfold is a symbol of equal justice for everybody.

Great for Justice – But not for Game Balancing

If you are the only one playing your game for balancing, you run the risk of adjusting the game to your personal play style, while being blind to issues others might encounter. So you need to seek strength in numbers. To balance by playing, you need beta testing more than ever to get your game in the hands of as many players as possible and hope for valuable feedback.
And even then it is easy to miss things.

The Late Game is hard to reach
Not every game has a late game, so this paragraph only applies to those that do. Late game is called late for a reason. It should take some serious play time to get there. And since it takes so long to get to the late game, you will not reach it by accident. During development games are usually only played for a few minutes at a time, to test out a feature or fix a bug.  You don’t play for hours on end to get to the final level to fix a bug in the boss fight. You will directly jump there using some kind of debug or cheat feature.

This is fine for development, but to truly balance your game, you will need to reach the boss battle through regular play. And then, when you realize the boss is horribly overpowered and you quickly lower the prices for better weapons and armor – you will need to start all the way from the beginning again – and play your game through with the new numbers. In short, the amount of time you need can quickly get out of hand. You run a serious risk of an unbalanced late game if you rely on this method of balancing alone.

Balancing on Paper
The other method of balancing a game is to use mathematics. I call it paper balancing – though of course instead of paper I am using spreadsheet software like Excel and Google Docs.

Using this method you work with your numbers directly and put them into tables and graphs to see whether they all work out. This can give you a tremendous amount of information about your game that you would never find out otherwise.

Various graphs, overlayed over one another, symbolizing that there is a LOT of data to evaluate to achieve balancing.

One of the strengths of paper balancing is that it is very easy to see the results and consequences of any changes your make to your values. In case you are easily scared off by math, you will be happy to hear that it requires very little actual math skills.
To demonstrate how paper balancing works I will give an example.

Paper Balancing – a simple example game
In this example I am developing a simplified hack’n’slash game. The player needs to kill monsters to  earn XP to level up. Now let’s do the basic balancing.

The first step is to find some starting numbers. I decided the player needs 100 XP to get the first level up, and each monster will give 5 XP. That means the player has to kill 20 monsters to get the first level, which sounds fair. But these starting numbers are not all that important, the real balancing starts now.

To make each level a bit more difficult, the XP needed to get to the next level should constantly go up. I am choosing that each level will require 35% more XP than the last.

Now I need to make the higher level monsters worth more XP – otherwise the players will just keep killing the low level monsters. Again I pick a random number and decide that each monster will give 10% more XP per level. This number has to be lower than the 35% more XP needed for leveling up. If it grew at the same rate, players would need to kill exactly the same amount of monsters to level up each time.

A goblin stands next to a sign post that lists his statistics. It reads: "Goblin. Level 1. Reward 5 XP, Time to Kill: 2 minutes"

Now that I have these two numbers, I can put them in a table and see if they work out. The spreadsheet immediately tells me that I need 135 XP to get to the second level. Since each monster on that level gives me 6 XP, I need to kill 25 monsters to level up. That’s 5 monsters more than I needed for the first level. Everything sounds pretty good so far, right?

But then I notice the rather large numbers near the bottom of my table. To get from level 29 to level 30, the player needs 446,011 XP. At this level, each monster will give 72 XP. My spreadsheet automatically calculates that this translates to 6,186 monsters that I need to kill. It also calculates how long this would take. The result is horrible.

If I killed a monster every two minutes while playing, and I would play for 8 uninterrupted hours a day, without stopping for food or going to the bathroom – it would still take me 26 days of playing without a break to get that level up. A more realistic player who can play maybe 8 hours a week would need to spend 4-5 months to get just this one level up. I have nothing against a little grinding, but that is just not acceptable.

And this is where the paper balancing really shines. Let me tweak the number of how much more XP is required for each level. I am tuning it down from 35% to 25%. Immediately the numbers adjust. Now I only need to kill 717 monsters to get from level 29 to level 30. This would mean 24 hours of game time, or 3 days of 8 hour power-gaming sessions.

Those numbers sound a lot more sensible now! And I found this out within 5 minutes of working with a spreadsheet. Can you imagine how long it would have taken me to balance this only by playing the game?
Isn’t math cool? 🙂

[To those actually double checking these numbers with a calculator right now: All numbers are rounded up. Since you cannot earn 3.5 XP, you will get 4 XP instead and so on.]

I shared the spreadsheet with this sample data on Google Docs, so you can take a look at how a balancing table can look like. You can also copy the document and play with the number to see what happens.
Here is the link: Balancing Table Example on Google Docs

The complexity goes up!
Just in case you are not yet convinced of the power of paper balancing, let me drive the point home some more. See, a real game is a little more complex than the example above.

In my hack’n’slash game, the player gets more XP when killing a higher level monster. But what is to stop low-level players from killing higher level monsters? Clearly, they need to be harder to kill. So their health needs to go up with each level.

But if their health goes up, it would take longer to kill them. To counter this, higher level characters need better weapons to do more damage in the same amount of time. So I need to make higher level weapons with higher damage.

Then, to stop low level players from buying high level weapons I need to make them more expensive. But to enable higher level players to buy those weapons, I also need to make higher level monsters drop more gold.

Question 1: At what rate do you need to increase the rate of gold drop for each monster level, so that a player can afford a new weapon each level before he has gained enough XP from the same monsters to level up?

Question 2: Do you really want to balance this by playing? Or does paper balancing sound pretty nifty right around now?

Not a perfect system
While they sound boring, spreadsheets will show you problems in your game that you would never see otherwise. It is not a perfect system, but it is definitely a more objective system than just playing and fixing the issues that happen to bother you. It is also a great tool to balance parts of your game that are hard to get to through playing, especially the late game.

But not all parts of a game can be balanced on paper. Action elements that require reflexes and timing – such as quick time events for example – are better balanced by trial and error during play. The same is true if you are making Flappy Bird. 🙂

Graphs and tables also can not tell you every strategy and exploit that your players will undoubtedly find when playing your game. This is why many online games need to readjust their balancing so often, as massive hordes of players develop new play styles and combos.

Best of Both Worlds
Summing up, balancing a game purely by playing it is a poor choice.
This isn’t necessarily true for all types of games, but enough to let it count as a general rule of thumb. 
This is not to say that you shouldn’t play your game. You should. A lot. It might be off-topic, but I cannot stress this point enough: Play your own game.

But as usual, the best approach is to use both methods of balancing. Have your spreadsheets and formulas ready, and then actually put those numbers to the test by playing the game, tweaking and adjusting as you go along. And if you run short on time near the end of development, you can rest assured that your spreadsheets have your late game covered.