5 rules of game balance: analysis of cases from Rocket Jump

Konstantin Sakhnov

In this article, I want to share the approach to game balance development that we use in our daily work.

The term “game balance” has a number of definitions. In practice, it is convenient to consider a system of rules and restrictions aimed at creating engaging gameplay as a balance. In this definition there is an indication of the key elements of balance. So how to approach its development in practice?

I have determined for myself the sequence of steps and questions that need to be worked out to create an in-game balance. In the future, they formed the basis of simple rules.

Rule #1: Game balance is a system of restrictions

When we develop a game economy, bring together characters or their abilities, the first thing to do is not calculations and not playtests. First of all, you need to decide on the concept, logic and rules that will form the basis of the game. And any rules are just a system of restrictions, boundary conditions that the player will not be able to violate.

For example, when creating a strategy like StarCraft, it is unrealistic to check all the cases and development options that players will have. But you can set limits — the speed of development, the maximum level, etc.

In World of Warcraft there is a very explicit and clumsy example of this approach to restrictions, which, however, works fine. The developers had a task — to give players the opportunity to master the content of raids for the right and convenient time. This time is dictated by many factors, one of them is the speed of entering fresh content into the game. To solve this problem, the developers have introduced systems of boundary conditions:

The player‘s goal is to collect all the equipment necessary for his class in the raid, including a unique set (shooting range), the collection of which gives additional bonuses to abilities and characteristics. The number of items is known. They fall for killing bosses. We also know the number of bosses in the raid and the number of actual raids available.

The first limitation is that things fall only when the boss is killed for the first time during the week (a few years ago, raid content was divided into “normal” and simplified, where the raid is collected from “random” using the Looking for Group system, but we will take the classic rules as a basis). In other words, a player can get no more than one thing from the boss per week.

The second limitation is that the probability of the desired item falling out is not equal to 100%. The player may get a duplicate, an item for another class. Or maybe you won’t get anything at all.

Result: using the basics of probability theory, we can calculate the minimum time when a player will collect all the equipment items he needs, and the average time to collect a full set.

After thinking through the restrictions, calculations usually take place. Let’s estimate the probability of collecting all the items we need in World of Warcraft raids.

Let’s say you need to wear 10 things for full equipment. For simplicity, let’s say that each of them falls from one of the 10 bosses. Remember the limit — one thing per week from one boss. If an item falls with a 10% chance, then the probability of not getting the item by killing the boss is:

The probability of not getting any of the 10 items is calculated by the formula of the sum of the probabilities of independent events, i.e. as the product of the probability of each of them:

Accordingly, the probability that we will knock out at least one item we need from 10 bosses in the first week will turn out:

That is 65%, which is quite a lot! What if we want to get all 10 items in 10 weeks? The chance of such an event will be equal to:

Only 1%.

In fact, the situation is a little more complicated. It should be taken into account that in the case of receiving one item in the first week, the second one will already have 9 out of 10 necessary things, and the drop of what fell before can no longer be considered a positive outcome. And if a different number of things fall from different bosses, the model becomes even more complicated.

In the presented model, there is a probability of 0.00000001% that the player will collect a full set of things in a week. And there is a non-zero probability that he will never collect it. To avoid such situations, random is often made manageable. For example, in Heroes of Might and Magic V, ghosts that have a 30% chance of dodging a blow are guaranteed to take damage after two turns.

Another example of the use of strict restrictions, which are easy to see without a detailed analysis of the game, is card games. In Hearthstone, we are faced with a fixed number of daily quests that limit the maximum inflow of gold per day. We see limitations on the number of legendary cards in battle, which allows us to give them more complex mechanics, a double combination of which will not break the game. We find restrictions on the class composition of the decks, which allows us to make cool cards that could become an imba in combination with cards of other classes.

Rule #2: The basis of balance is an accurate calculation

Very often we balance entities “by eye”. This approach in most cases leads to a big problem — the lack of control and predictability of changes. Yes, there are cases when the balance “from the head” can be applied in practice. But in such cases, the game logic has a shaky foundation. To play with five entities, you can combine them with playtests and a “developer’s vision”. But when a game designer is faced with the task of developing a system and prescribing all the content of subjects in an MMO or a set of studies in a 4X strategy, it is dangerous to approach such a task without a system.

A good balance should have a solid foundation, backed up by logic and mathematics. This will allow:

• introduce new content systematically;
• predict its consumption by players;
• set rules for entering and outputting entities;
• anticipate some problems in advance even before the support writes to you about it;
• reduce the probability of error.

As an example, we can cite the development of a balance of equipment items for games of the popular Battle Royale genre. Solving such a task, we first of all determine the archetypes of future items: pistols, shotguns, machine guns, rifles, melee weapons, etc. Next, we need to write out all the characteristics that the items have. The task of the mathematical part of the balance in this case is reduced to the use of the method of basic characteristics.

We introduce a certain parameter: the power, the level of the thing — it can be called anything. The essence of this value is that two types of weapons can be compared by one digit. The one with more power is cooler. All parameters of the weapon will be included in the formula for calculating its power. If the weapon is fired within the cone in front of the player, then one of the parameters involved in the calculation of power will be the area of this cone (or its other characteristic).

The rate of fire, the strength of the weapon, the number of rounds in the magazine, the damage from one shot, etc. will be taken into account. The screenshot shows a weapon balance calculator that calculates power. Its goal is not to generate a large number of items for the game, but to balance a limited number of weapons among themselves. Boundary conditions were set: the coolest weapon should not have a DPS more than 2 times higher than the DPS of the weakest weapon.

Link to the table

In this example, DPS is calculated as a function of the ratio of the amount of health to the time of killing the enemy and the parameters of a specific weapon. The final DPS is multiplied by a small bonus, which increases depending on the type of weapon. It creates an increase in damage within one type of weapon and ensures the presence of stronger and weaker submachine guns, pistols, etc. in the game.

After calculating the damage per second for each weapon, we will calculate its power, taking into account other parameters of the gun as well.

It is important to remember that, as in many other cases, when balancing Battle Royale, not only the power of the weapon plays an important role, but also its applicability in various situations. You can try to take this into account by making different coefficients before the power value for different archetypes of weapons. However, this is still not enough. Without checking for extreme situations in a real game, it is impossible to answer the question of how balanced the system turned out to be.

Rule No. 3: Tools are the key to the reliability of the balance.

When you are engaged in theoretical game design, everything can be very beautiful and concise in calculations. But in practice, there is always a need to transfer the calculations performed to the product. This process, often called configuration, involves writing XML code, JSON and SQL scripts for a database of a different method of data creation.
Having learned from my own experience, now I start developing any product by creating a set of tools that allow me to get rid of the need to write code manually. Why is this so important?

• All people make mistakes. Excel is more reliable.
• A good toolkit will check the types of data entered for you, whether they fit into the specified framework, and show how the entire system will change when one parameter is changed.
• Automation of work. No more running through hundreds of XML files and writing regular expressions.

It is difficult to overestimate the usefulness of automated tools for any large project. The main thing is not to get carried away with rampant automation where it will not bring real acceleration of work or reduce the influence of the human factor.

In one of the products I worked on, there was a system of offers — in-game offers to buy a particular set of products at a discount. Offers were entered into the SQL database. They had the following parameters:

• visual part (title, description, art and interface);
• conditions of appearance (lack of a certain resource from the player, level, cascade, solvency and a number of other factors);
• settings (cost, discount, cooldown, connections with other offers, time of activity, method of appearance in the game, etc.);
• reward (resources, troops, currency, buffs, paid services, etc.).

A number of tables described this logic. In the process of implementing the database, server and client code of the feature I am developing, I prepared an Excel spreadsheet with the calculation of the content and the cost of offers. When it came time to transfer hundreds of offers to the database, I realized that I would spend several weeks on it. What if I make a mistake in the process? Who will test the functionality of several hundred offers?

There was only one answer to these questions — to refine my calculator by implementing in it the creation of SQL queries that remove old offers from all tables and insert new ones there. With automatic checks for data consistency. Examples of checks that saved both my nerves and the nerves of the QA team:

• all required fields are filled in;
• the cost, reward, discount and other values do not go beyond the predefined limits;
• the content of the offers really corresponds to the cost, taking into account the discount with a given degree of accuracy;
• appearance conditions and cooldowns do not generate offers that will never appear.

Link to the table

If certain data is entered incorrectly, the corresponding cells will be highlighted in red.

Link to the table

Guided by the same principles, I created simple Excel calculators for all aspects of the game. This approach allowed not only to get rid of unnecessary manual labor, but also in combination with autotests on the client to significantly reduce the testing time.

Link to the table

Summing up this point, I summarize the main goals of the toolkit:

• speed up calculation and content creation;
• reduce the probability of errors caused by the human factor;
• provide an opportunity to promptly make changes to the balance sheet based on the results of analytics;
• simplify the formation of product configuration files;
• see the picture of the game balance as a whole and the impact of its individual parts.

Rule #4: Mathematics is not enough, playtests are needed

This rule applies both ways. The absence of a mathematical and logical model is the absence of a base, a reference point, relative to which balancing will be carried out. But to describe a complex game completely mathematically is like developing a “theory of everything” for physicists. The task is not trivial. Therefore, in practice there is always room for exceptions and deviations from accurate calculations.

After the release of the legendary Clash of Clans, I deconstructed it to better understand the principles of this game. Then I noticed that the cost of improving buildings and the gold and elixir produced by them deviate from the exponent and the straight line at large values, respectively. The reason for this discrepancy turned out to be simple: the developers strongly rounded the parameters to the nearest “beautiful” numbers: 1 day, 2 days, 3 days, etc.

In any sufficiently complex gaming product, there is always a place for unpredictable interactions. Situations when a combination of abilities gives an unexpected multiplicative effect are constantly encountered in games. Such problems are solved by playtests. A good game designer is constantly playing his project. It sounds corny, but it is this simple truth that employees of gaming companies constantly forget. High development rates are customized, allowing you to forget how important it is not just to do your job, but also to see its results with your own eyes. Apart from the author of the feature, no one knows how it should actually work. And even the best QA department will not be able to conduct full-fledged game design testing for you. I’ll give you an example.

While working as a producer on a social strategy game, I estimated the volume of content being sold and decided to introduce a new unit into the game to increase the revenue of the project. We have implemented a very cool mercenary with inflated characteristics and interesting game logic. The created unit – a group of three fighters in protective suits – moved slowly across the field, burning everything in its path with streams of toxic acid. He had a lot of health points, was protected from many types of attacks, and even left behind poisonous puddles after death. Toxicity became an interesting mechanic — the unit inflicted damage to itself with a certain frequency until its health reserve dropped to 20%. In combination with the initially huge reserve of health, this made him a good tank, which, however, lost its potential after some time, when he brought himself to low health. The unit had a powerful defense against poison and was conceived as a countermeasure against the most powerful mercenary of the game, burning opponents with poisonous damage.

Having implemented a new unit, we conducted playtests. A well-balanced combat unit proved to be useful in a number of game situations. What could have gone wrong? One of the game designers of the project team treated the new content with due attention. He was worried about the product and how the players would perceive the innovation.

He released a mercenary against ordinary troops. Excellent result! The game is interesting. Against unique event armies — everything is great. And now it’s time to check how the new infantryman copes with the main enemy of the game, because he was made just to fight him.

The first fight — and failure. The new squad is dying too fast. Its characteristics are increased by game designers, and testing is carried out again. And again failure. In a calculator designed to calculate the combat power of mercenaries, a novice is not inferior to the leader. What is the problem? We checked if the poison resistance works. Works. Increased the health of the unit again and conducted repeated tests. To no avail. The old leader smashes the newcomer, without a chance.

These playtests allowed us to realize the real reason why the old unit was so invincible. His mechanics “poisons the infantry under attack, removing 15% of its maximum health for N seconds” worked in a cunning way. Everything was implemented correctly and corresponded to the documentation. But the imposed DoT effect (damage over time) accumulated over time — in game jargon, “stacked”. And therefore, after several volleys of our elite on infantry, several “pillboxes” were hanging on the infantrymen at once, causing percentage damage. Naturally, nothing can save you from a situation where the percentage of damage adds up many times and grows exponentially.

There were many such examples in my work. And the key conclusion that I made for myself is that you need to play your own games. You can’t just calculate the “perfect” balance, just as you can’t do without accurate calculations. A good product is born in the great efforts that are invested in it. And it is absolutely necessary to check every little thing. This rule applies not only to game designers. All specialists working on the product should see it through the eyes of the end user.

The main thing in the balance is the impression. And sometimes you can neglect the harmony of formulas and the beauty of mathematics for the sake of the sensations of the game. A good example is the development of tutorials and the first steps of users. They very often violate the logic of general calculations in order to create the right impression of the first minutes spent in the game.

Rule #5: Nothing lasts forever — work with statistics

One of the most popular mistakes in the development of online games is the tacit agreement of the team that it is most important to make a product here and now, invest all efforts in the development of new features, give the content to the players and … forget about it.

Freeplay games are a very subtle system that requires constant tuning. The introduction of new content can radically change not only the game, but also all its metrics. Including financial ones. We need to constantly keep our finger on the pulse and understand the state of the in-game economy, engagement indicators, balance and other aspects of the game. The best assistant in this matter is analytics. Each feature that you introduce into the product must be backed up by collecting statistics and tracking key indicators. It would be a big mistake to think that it is important to look only at monetization indicators. When you see a clear drop in DAU, revenue or ARPPU, it may be too late.

Recently, at Rocket Jump, we introduced new gaming activities into the Under Control project, which has been in operation for four years and still enjoys the interest of the audience. It was a new regular mini-event “Cold Watch”. In its mechanics, it is close to our other events. But with the introduction of the watch, gaming activity and, as a result, audience engagement and retention has increased significantly. I’ll explain how we came to this.

One of the indicators that are monitored on the Under Control project is the number of fights of different types (PvE, PvP, clan) per active player per day. This figure to a certain extent reflects the interest of players in the product, showing when players begin to get bored with the current battle modes, and the introduction of new ones is required. But statistics alone are not enough. It is important to be able to interpret it correctly. So, in the example given, a decrease in the number of fights per player per day quite clearly means that players are losing interest in the game. But why? Are they facing technical problems? Is there an imbalance in the game? Bored of the gameplay? Irrelevant rewards?

An analyst and a game designer are people whose joint work can give an answer to these questions. In solving such problems, I adhere to a simple algorithm:

• analyzing statistics, the presence of deviations is a sign that it is worth delving into the search for possible problems;
• if there is a problem with an unexpected change in metrics, we put forward a set of hypotheses that can explain the reason;
• we go through the list and formulate for each problem how to technically test it, excluding incorrect hypotheses.

In the example above, it looks like this:

1) In the regular review of reports, we found a drop in the metric “number of fights per player per day”.

2) Fixed a list of hypotheses: bugs, imbalance, bored gameplay, irrelevant rewards.

3) Check each one. We look at the support tickets and see that the number of requests is within the norm. We don’t find any critical bugs. We look at the awards for relevance: we download statistics on the use of mercenaries and other awards by players from the analytics database and understand what is in demand and what is not. Seeing that not all awards are relevant, we conclude that this thesis worked. We check the feedback from the community on the gameplay and understand that there is not much excitement or irritation. This means that this item cannot be discarded either. The absence of negativity in this case is not an indicator. In the next update, we are releasing a new battle mode with new rewards, which shows good results both in increasing the activity of players and in increasing the spending of in-game entities.

Another example where analytics helped us a lot in the balance is the optimization of awards at the game fair. In the same Under Control there is a weekly fair in which powerful random rewards are dropped out, which are available for use only for a week. In it, you can open chests for two types of game money and for real currency. Analyzing the activity of players at the fair and listening to feedback from the community, we regularly change its composition to give people what they really need. The task of recalculating the probabilities of thousands of entities in three types of chests, deleting something, adding something, putting it all into configs and testing it looks very time-consuming. In practice, the fair chest calculator developed by our team does all this work for us.

Link to the table

The fair (or trophy sale, as it is called in the game) is a source of valuable rewards, which, however, exist for a limited time. In different periods of the game’s life, the value of game entities changes. Depending on the offers offered by the developer, the state of the game economy and other factors, players are in demand for different rewards at any given time. When developing the fair, we wanted it to offer players exactly the rewards they need. This means that we must regularly review statistics and change the composition of awards so that the fair remains interesting for our audience.

***

Let’s summarize the results. When working on the game balance, it is important to have the principles on which it will be based, to own a mathematical apparatus, to create tools that automate the work, because you will return to rebalance more than once, check the results with the help of playtests and do not forget that the game product is a dynamic system that needs to be monitored constantly.

Perfect balance is not the goal. You can endlessly improve it on the framework of playtests, statistics and deeper models. It is important what sensations your balance provides. Moreover, many developers intentionally introduce unbalanced elements into the game and periodically “shake up” the game, rebalancing entities. Take, for example, strategic games like Warcraft III. The balance of units, heroes and races in them periodically changes if the product is in active operation. This allows you to break the established optimal strategies, generating new research and new impressions of the gameplay.

Conclusions:

• any balance does not start with calculations, but with rules and restrictions;
• the system of restrictions must have a mathematical justification;
• the most important role for the quality and speed of work is the toolkit that allows you to change calculations quickly and without errors;
• mathematics is not enough to create a strong balance, you can’t do without playtests and make a product without playing your game;
• no system lasts forever. You need to have tools to check its current state.

A source: Rocket Jump