Balancing Challenges and How we Managed Math on Idle Idol

Introduction

Idle Idol is a k-pop themed Idle Game, with many places to explore, upgrades to buy, idols with different skills to assign to your group and many other features which you can use to maximize your money gains. We decided to merge both the trending k-pop theme and idle games to bring alive a project that, overall, was really fun to complete.

When we first started developing an idle game, I thought it would be easy to balance things out, because well… What can go wrong with an idle game balancing? You just have to do some exponential growth, put some costs and values and there it is. Turns out I was wrong, things quickly started to feel bad. The game pacing was too slow, I changed a couple values and then it was too fast, then I changed again and it just felt wrong. 

Everything just got eventually harder when we added more values that changed how the game worked. Active skills, passive skills, special systems, more ways to generate money. How would we prevent it from breaking the game? How would we make passive skills balanced between each other? How would we make the progression feels right?

In this article I’ll cover some thoughts about balancing that we learned on Idle Idol that can be used for any game, not only idle games. 

Things usually have a formula

Just to get clear about what we’re going to talk about next: Idle games usually have two main values the player deals with, the cost of upgrades - which have an exponential growth - and the reward given by them - usually a linear growth. Those upgrades usually can also be leveled up, which means the reward and the cost increase each time the player increases its level. 

In this chart, the cost surpasses the reward at about level 35, which means that every level after that will be more expensive when compared to the reward given at that level. Each upgrade had a base cost and reward (the cost and reward at level 1). Both the cost and reward base costs had an exponential growth of 1.1X, which means a 11%-19% growth in cost from the upgrade before it (the exact value changed a lot during production so it doesn’t matter), being the reward slower so the pacing of the game would slow down. 

It worked for the first few upgrades, but exponentials can get off control really fast, so even a 0.01 difference would mean a huge difference for, say, the 20th upgrade, so the game was TOO slow and changing so little wouldn’t impact a lot. We changed this a couple times, like link the reward value to its cost instead of the previous reward, but it still wasn’t feeling right.

So we refactored it all. At this time of the game we had played enough to know the game feel and estimate how much each upgrade would be nice to cost, so we did it manually. We put a cost for each upgrade without using any formula to determine it and since the reward was dependant on the cost, this approach worked very well and we thought “It’s good now, we don’t need a formula.”

Turns out we did. The costs started fine and it was amazing compared to previous iterations, but we couldn’t tune it to be late game optimal, so after a few days of gameplay, it started to slow down and we couldn’t be dependant of a chance of getting it right because each test would take some days. The manually defined costs were focused on the number exponent instead of the number itself, like 10, 1000, 1 million, 1 trillion… And since it worked out great, we knew our approach was on the number size rather on the full number itself.

The final formula then considered the exponent growth rather than the number, and then it was fine. The pacing was slowing down throughout the game, but not very fast or very slow, maintaining a good and this time math-based game feel.

Don’t get too caring about your charts

When we start balancing, all we want is a screen full of charts so we can analyze data, evaluate progression speed, if things are balanced between each other and this kind of stuff. And although charts help a lot (specially by turning numeric data into visual data so we can change values much easier), sometimes we need to accept that math and perfect charts aren’t so good to the game feel.

Idlle Idol has a system of active skills, they are skills the player has to tap a button to activate and they usually have effects that boost by a lot the player’s income, speed, progress, etc. Those effects are usually something like “Double your income for the next X seconds” or “Doubles the effect of the next skill”. They also have a cooldown, so after the player uses it, they have to wait to use it again.

When we first started balancing active skills, we tried to figure out a way to keep all effects balanced so we could let cooldowns approximately equal. We took some care with our calculations to nivelate them and our charts told us it was very good, but the game feel was just awful. This looks like something that goes against the first topic in this article, but sometimes your charts make sense mathematically, but it just makes your game feel bland. Sometimes it’s okay to have skills unbalanced between them, since it’s balanced elsewhere somehow.

Some skills for example have smaller cooldowns, because we wanted the player to use it all the time.

Sometimes skills can have different cost growth if some of them have much stronger late game effects.

In short, yeah your charts are important, but your values may have huge disparities if they make sense.

Automatizate your spreadsheets

The first thing we’ve done when we started to design the systems and the math behind Idle Idol was to have automatic spreadsheets. You know, those ones that make your eyes shiny and think “Well, we’re safe”.

The values are above are all the values we have for the entire upgrade and progression systems. Every change we make in the overall game balancing is done here. If we decide that the level up cost is high, we can change the Cost Increase per Level and all 40+ upgrades cost are changed at once. The same is applied for every other bonus, for level caps, for bonus multipliers and everything. This turns manual work to automatic, since we don’t have to apply math to each cell of each upgrade value.

Another automatic thing  you must have if you’re dealing with numbers is a game calculator. In our game, we had one where we could choose one of our upgrades and input prestige points (a bonus multiplier the player would get later on). This would generate another tab (and cool charts) with all values from each level of the upgrade selected with the amount of prestige points determined: 

Automatic balancing is efficient, but be cautious

We did passive skills one by one, of course we had some good practices, but since we had like 40 passive skills in the game, it eventually got harder to keep all skills balanced between each other.

To make things easier, eventually we designed a system that would “auto-balance” skills.

In this system, we had skill effects and skill parameters. Skill effect is what the skills do and parameters are usually “when” the effect applies. Some effects only apply on special occasions, while other apply all the time. What we did was give a weight to each effect and then a weight to each parameter depending on how “strong” they were. This would make possible for us to balance effects and parameters rather than individual skills. At the end of the day, we just multiplied the effect multiplier by the parameters that skill had to get the final outcome:

This is a great way to not only save time, but also to be a little more certain that things are balanced. Just be careful, you’ll probably have to tweak some values at the end anyway.

Sometimes the problem is not about balancing

To finish things up… We did a bunch of playtests with users when we had the game somewhat polished to gather feedback from aesthetics, gameplay, etc. 

We had some people complaining about how the progression felt slow. They played for a couple days and suddenly it took ages to progress. This created other problems such as “no content enough”, “music gets repetitive”, etc. 

The “game is too slow” problem was a huge hit to our balancing, since the game getting slower was due to a balancing problem with a bad curve, right?

Wrong. Another feedback that was not taken into account was that the passive skills screen was hard to find and not well explained. The late game progression is directly attached to players levelling up their passive skills to improve their gains, so the game would feel very slow, but not because of the curve of balancing, but rather because the players weren’t interacting with a crucial feature of the game because of UI and tutorial problems.

So before jumping out to your spreadsheets and serializable fields, check if the problem is really with your numbers or another problem is responsible for the “game is unbalanced” complaint. 

Conclusion

When it comes to balancing a game, things may get really messed up, especially if you’re dealing with a lot of numbers which impact on other numbers and they have no direct correlation to each other - like a skill that buffs damage vs a skill that buffs attack speed - and those other numbers also have to be balanced.

Charts, spreadsheets, formulas a deep knowledge of your game systems are the way to go. Not always things get a small unbalance and that’s okay, but you have to be careful, because the difference between a broken or just strong skill, character or item is a fragile line.

Of course we changed stuff in the game after this article was written, but we still kept these thoughts in mind when tweaking the game.

To close things up, remember that tips in this post are by no means a golden rule to follow whenever you’re balancing a game, they’re just lessons we learned while producing Idle Idol that made our job easier and we wished we knew it before. Use it as you wish! 

Idle Idol is currently on alpha and should be released soon!