Author: by Pol Vilaseca, Pietro Guardascione

Pol Vilaseca is senior economy designer at King, and Pietro Guardascione is senior director of envelope design at King.

Hero was an action RPG that was developed by King and soft launched during 2016 in different countries in Asia. In the game, you could choose among three heroes (warrior, mage or archer) to play through levels that consisted of sets of successive combats against groups of enemies of various types. Although the game was cancelled before making it to a global release, the design challenges that we faced during its development gave us some valuable learnings about designing mobile RPGs. The purpose of this article is to collect our experiences while designing some of the systems in the game.

The main loop of the game was rather simple. By completing quests players accumulated gold that could be spent buying new items. Stronger equipment increased the overall power of the hero, which in turn allowed quests of increasing difficulty to be played.

With the simple main loop described above, the overall player experience was determined essentially by 3 game systems:

A combat system, consisting of all the elements that contribute to the outcome of a combat and their inter-relations. As in many RPGs, these elements include player stats like attack, health and defense, chance of dealing critical damage, elemental or splash damage etc.

The outcome of a combat is determined through the combat equations that relate the stats of heroes to those of enemies. For instance, given the attack power of a hero and a monster’s health, the equations of combat determine the number of hits it will take to kill that monster.

A progression system, which consists of the set of rules that determine how the different hero and monster stats grow as the player progresses through the game. In Hero, progression was mainly driven by gear. The stats of a character were determined by the gear he had equipped. The higher the level of an item, the more it would contribute to the character stats. The current level of a hero determined the level of the gear that the hero could equip, and hence the stats that the hero would have.

A chest system, which was a random reward system through which gear was delivered. The chest system consisted of the different types of chests present in the game and the rules to which they were subjected (drop rates, frequency, item probabilities). There were chests of many types, each of which had its chances of delivering items of a given rarity.

Each of the systems described here could be analyzed on its own. However, the three systems were highly interdependent on each other.

For example, since the progression system was essentially driven by gear and gear was obtained by collecting chests, this meant that the chest system was the core driver of progression. Setting up the right chest rules and their drop frequency was crucial to fuel an appropriate progression rate for the heroes.

On the other hand, the progression system determined how the different hero and enemy stats scale. These in turn determine the outcomes of a combat. Hence, the combat system had to be carefully designed to accommodate the specific character progression we had designed. 

Finally, the outcome of a combat determined the chests that a player was going to get, which again connects to the progression system.

Once we understood these interrelations, it became evident that we needed a way to explore the consequences on the overall player experience that arose from each game system and its impact on the rest of the systems. We achieved this through a combination of mathematical modelling, prototyping tools and simulations.

In the following, we’d like to review some of these approaches.

Scaling of Combat: a formal approach

Combat systems are at the heart of any action RPG. When a combat system is coupled to a progression system, they both need to be carefully designed to be compatible with each other. Otherwise, it is possible that a combat that seems to be balanced at some stage in the progression behaves in a completely different way at later stages.

To understand this, let's consider a minimal combat system in which a hero and a monster are characterized only by two stats: attack and health. During combat, the hero will have to attack the monster several times until it runs out of health and dies. The number of hits it will take for the monster to die is given by the ratio:

N = H_E / A_H

where N is the number of hits, H_E is the health of the enemy and A_H is the attack of the hero. The higher the enemy health, the larger the number of hits it will take to kill him. The stronger the hero, the smaller the number of hits it will take him to beat the enemy. 

Although health and attack determine the outcome of a combat, these stats are "hidden" to the user. The only variable that the user perceives in practice is the number of hits that it will take to kill an enemy (or to get killed by it), and not the attack or the health on their own. Hence, we can say that the sensation of combat is given by the number of hits it takes to kill or die.

On different lines, the hero and enemy stats evolve following the progression system. This means that the parameters A_H and H_E depend on the hero level and the enemy level respectively. Hence, the number of hits it will take for a Hero of level x to kill an enemy of level y will be a function of both hero level and enemy level:

N(x, y) = H_E(y) / A_H(x).

A main requirement in the design of the game was to preserve the experience of combat through the whole progression. This essentially meant that a Hero of level 5 fighting a monster of level 7 would have the same combat perception as if the Hero was level 65 and fought an enemy of level 67. As long as the differences in hero and enemy levels were equal, the combat experience should remain invariant. This requirement can be expressed in a mathematical way by demanding that the function giving the number of hits depends only on the difference in the levels x – y, and not on the levels themselves,

N(x, y) = N(x – y).

This requirement imposes strong constraints in both the progression and combat systems. For a combat equation based on the ratio between health and attack, scale invariant combat requires stats to grow at a geometric rate. This means that the functions that give the player and monster stats have an exponential form,

A_H(x) = A • exp(a • x), and H_E(y) = H • exp(a • y),

where A and H are the base values for the hero attack and enemy health respectively. The parameter a sets the scale for the growth of stats from level to level.  Plugging the previous expressions for A_H and H_E into the formula for N(x, y) we obtain

N(x – y) = H / A • exp(–a • x – y)),

which clearly depends on the difference of levels x – y and not on the levels themselves. This ensures that the combat experience of a player will remain balanced at any scale.

More realistic combat systems include aspects like damage mitigation, critical hits or elemental damage. Special care has to be taken when setting up their corresponding equations of combat such that they depend only on the difference x – y.

Once we had a robust model for combat that would ensure the right scaling, we built a combat simulator in Python that calculated the number of hits it would take to kill a given enemy or to get killed by him. We used the tool to explore different values of the hero and enemy stats appearing in the combat equations. For each set of values, we visualized how the combat experience scaled when facing enemies of higher or lower levels. This allowed us to balance the hero and enemy stats and ensure that the combat experience satisfied all design requirements. Moreover, any new enemy type or item could easily be incorporated into our model and the tool allowed us to produce its corresponding stats with no cost at all.

Figure 1: snapshot of the combat simulation solving the combat equations.

Simulating the Chest System

Chests were the main element of the random reward system that deliver items from an item pool with a given probability. In many games, the pacing at which players progress is determined by the inflow of items. In these cases chests become core elements in the progression. It is then crucial to understand and control the rules of the chest system.

Roughly speaking, one can think about a chest as an abstract function that maps all possible items available in a game to a probability of dropping them. Different chest algorithms would be different mappings from the item space to the probability space.

After a large number of drops, the chest algorithm will be responsible for how the distribution of items in player inventories looks like. A variation on how items are mapped to probabilities can lead to very different player experiences.

When designing the chest system in our game, we created a simulation tool that would allow us to explore the evolution of player inventories after opening a given number of chests. In the tool one could set up different drop rules by fixing the mapping between items and probabilities of dropping them. For each rule we thought about, we could perform multiple runs in which several chests were opened and the status of the inventory was saved at every step.

The simulations allowed us to measure concepts such as the amount of chests that would be required to complete a section of the inventory, the number of chests needed to level up an item to a specific point, or the amount of in-game currency that a player needed to spend to obtain at least one legendary weapon. 

Having a clear way to explore how the chest rules impacted the player progression was crucial for determining the details and parameters of our random reward mechanics. We used the simulation to iterate the design of our chest rules until they delivered the player experience we wanted to provide.

Figure 2: Snapshot of the random reward simulation tool.

Metagame exploration

Once we had explored the dynamics emerging from the relations among different systems in the game, we wanted to have a global view on how they all fitted together and on how they impacted the player progression. For this purpose, we produced a tool to simulate the whole metagame and its mechanics in complete absence of gameplay.

The tool consisted of two parts:

Every time an action was performed (opening a chest, equipping an item, upgrading an item) the state of the player evolved according to the game rules in the engine. Data on the player state was collected at every step of the progression to visualize the evolution of the state.

This allowed the designers to manually play around with the metagame and get understanding and feel on how the different systems of the game were working together and impacting the hero progression. We could explore the long term progression allowed by a given set of rules in a matter of seconds. Moreover, we were able to add new metagame features to the simulation tool and understand how these interacted with the rest of the components already present in the game.

Figure 3: snapshot of the Hero metagame simulation tool.

Although we conceived the tool as a way to manually interact with the features of the metagame, once it was ready it could also be used to plug in automated agents programmed with different behaviors. By running simulations with millions of agents interacting with the metagame we could gather valuable information on different aspects ranging from distributions of times to achieve certain states in progression to the presence of potential loopholes in the chest system.

Concluding remarks

Metagames with many systems and complex economies lead to behaviors that are very difficult to anticipate. In these situations, game systems often require a considerable amount of mathematical modelling.

In our experience, simulating game systems is a very useful approach to understand how the different components of a game will behave and impact each other. New features can be added into the simulation for evaluating their effect on the player experience before implementing these on the real game. Building a simulation can help to validate, iterate and even reject the design of a system. Moreover, playing around in a simulation environment allows designers to build intuition on the emergent behaviors arising from each game rule.

We find Python to be a very appealing language for this type of approach, mainly due to its ease of use, its human readability and due to all the statistical and data visualization libraries it has available.

Overall, we believe that any game can benefit from the right combination of mathematical modelling and simulations during all phases in the design, from the validation of high level ideas to the tuning of the low level details when balancing the game systems.