Image by Michał Parzuchowski.

There are many types of game designers. There are many areas of our discipline which you can specialize in. When asked, what kind of a game designer am I, usually I tend to define myself as a systems designer. Making long term retention features is my specialty. Perhaps my engineering background prepared me for this role, or maybe I just had such luck to work on a lot of such features over the years.

One of the questions that I get asked very often is how do you approach balancing the economy in a complex free to play game. Especially, how do you balance features that are intended to keep players engaged for a long period of time, weeks, months, or in some cases, even years.

Quite recently, I had to do this same exercise all over again. Fortunately, this time I remembered to put my thoughts on the paper. This text describes the methodology I tend to use. It may not be the best, but it has served me well so far. To seasoned designers this might seem trivial, but I decided to share it in hope that someone might find it useful.

I will use a very simple example to illustrate my methodology. However, this approach forms a basis for balancing more complicated stuff. I will also use an example of an imaginary feature for an imaginary game, but I’ll use a type of game that each game designer should be pretty familiar with.

Let’s imagine that we are doing feature balancing for a real time PvP game. For example something that plays like Clash Royale. Players play 1 on 1 matches and gather some points, let’s call them Trophies, as rewards. By collecting these trophies players can travel down the so-called Trophy Path. You should be familiar with this type of feature as it is common in many games. Bawl Stars by Supercell is a good example of this.

Battle Legion by Trap Light has one of the pretties implementations of the Trophy Road.

A Trophy path is a relatively simple feature. It is a ladder of reward tiers. To reach each subsequent tier in the ladder, the player needs to collect a certain amount of trophies. Our objective is to balance this feature. In other words, we need to come up with a set of values, one for each point threshold, i.e., how many trophies in total a player needs to collect in order to unlock a particular reward tier.

The tool that we are going to use is a spreadsheet software, Excel or Google Sheets. It helps if you are familiar with those, but you can always use pen and paper.

The first important thing that we need to understand is that our job is to actually model the player’s time!

Time and not the points, the trophy count, is the key to understanding the balancing of such features. A Trophy Road is a long term retention feature and the player is expected to be engaged with it for a very long time, as I already mentioned, weeks if not months or years. Balancing such a feature might seem daunting, but it is a rather straightforward exercise.

KEY IDEA: Do not fear the large numbers!

In order to proceed we are going to need to make some assumptions on how a player spends his time. If you are designing a new feature for an existing game, collected telemetry data might help you make you do this. If you are making a brand new game, benchmarking the competition titles can help. Some of these assumptions will prove to be wrong. This is expected and unavoidable. I will try to teach you how to err on the safe side and minimize the impact of errors.

We begin our exercise at the source, at the source of Trophies that is. The first thing we need to determine and fix is the way the player obtains the Trophies.

We are working with a 1 on 1, real time PvP game. For each player an outcome of a single match can be a victory, a tie, or a loss. Naturally, players will expect to get Trophies for every victory that they achieve. At least this is simple. However, in free-to-play games, if we want to achieve long term retention, it is good to reward the player’s persistence and not only the player’s skill.

KEY IDEA: Reward persistence and not only the skill.

The player should be able to advance along his progression vectors even if he is not particularly good at the game. The player should not get stuck. Having a skill should make the player progress faster. Therefore, I would also give a certain amount of trophies to players even after losing a match as a form of a consolation prize.

You can decide how you want to treat ties. You can treat them as victories and reward the full amount of trophies to each of the players as if they both have won, or you can give some fraction of that number, i.e. 1/2 as if they have split the prize.

In general you are free to come up with exact numbers for both victory, loss, and tie. You can decide to give fixed numbers of trophies for each of these events or have some formula to calculate the appropriate amount. Elo score can be used for this, and it has an advantage that it is actually made for this type of games. I promise I will make a text only about Elo score at some point in the future.

As I said, what we are doing is modeling the player’s time. What we actually want to do is to predict where along the Trophy Road our player will be at a certain point in the future, or if we put it the other way, how much time will it take for the player to reach a particular reward tier on the Trophy Road. The distance here is equivalent to the total accumulated Trophy Count. In order to do this, we need to make some assumptions.

Above all, we need to somehow estimate the speed by which the player will accumulate the trophies. Obviously, this depends on the number of matches that the player is willing to play in the given amount of time. You are likely going to have a huge spread of values as players differ significantly in their engagement level. Some will play like crazy day and night while others will play only a couple of matches per day. In order to deal with this spread, it is useful to make a couple of scenarios.

The first scenario I like to call Insane Scenario. It usually assumes the theoretic maximum of points that anyone can accumulate by an insane amount of engagement. Let’s assume that some imaginary absolutely crazy player would spend 12h each day playing our game. I usually chose 12h instead of 24h because it is reasonable to assume that even such a player has to eat and sleep during the day. 16h is also a good choice sometimes.

This is not something that any actual living person would do, but it is useful to make this analysis as a sort of the upper limit, theoretic cap on player’s speed. Let’s assume that there are no limits on the number of matches, beyond the actual length of the match. You can estimate the average length of the match based on your core game. Your game can also implement explicit match duration, e.g., each battle lasts for 2 minutes, etc. Dividing the number of hours played per day will give you the number of matches played per day.

You might want to implement some restrictions on this. Your game might have an energy mechanic or some other feature that limits the number of matches that a player can play during the day. If so, you need to take this into account also.

Assume that this insane player is also extremely extremely good at playing the game, and that he will win each match he ever plays. His win/lose ratio is 100%. Multiplying the number of matches per day with the number of trophies awarded for each victory will give you the number of points that this player collects per day.

You may also want to limit this number by some external means. Maybe you can implement a cap on the number of trophies that a player can win per day. Playing additional matches after the cap has been reached, might not give any additional points.

You can now calculate the total number of points that the player will have at each day of engagement with the feature. This scenario gives us the upper limit of player’s velocity. It has its use, but it is not very realistic. It largely serves as a sanity check.

In order to make the actual balancing, we should make another more realistic scenario. I like to call it the Engaged Player scenario. Assume more realistic session length and session count. Again if you are building a feature for an existing game, you are likely to have such data at hand. If you are working on a new title, you might try to obtain such data from some online source, such as SensorTower, AppAnnie/Data.ai, or GameRafinery.

Divide the total average playtime with the average length of match to determine the number of matches that the player plays during each day. Assume some win/lose ratio. In a properly balanced PvP game win/lose ratio should, in the long run be for each player R=50%. You can also assume any other ratio, for example R=75%. Use this ratio to calculate the average amount of points the player is expected to take out of each match, whether he wins or loses, R*V+(1-R)*L, where V are points awarded for each victory, and L are points awarded as a consolation for a loss. Multiply this number with the number of matches played per day to obtain the average number of points that the player is expected to collect each day.

Similarly as in the Insane Scenario, we can now calculate the total accumulated number of points that the player is expected to have at the end of each day!

Finally, it is good to make another scenario. Obviously, the polar opposite of Insane player, with the maximal engagement, would be someone with the minimal engagement. By definition such a player would have 0 matches played during the day and 0 collected trophies. This is not really useful for us.

The third scenario would be someone that plays the game only casually. Casual player would play only a fraction of matches that an engaged player would play. We can therefore just divide the number of played matches by some number and obtain what we need for this player. It is reasonable to assume that a Casual player would play 3 or 4 times fewer matches per day, and that he will accumulate trophies 3 to 4 times slower.

It is good to take a look at implied session length and session count of such players.

The calculations we just did are basic mathematics, as dry as bones. The next part is much more fun. It is where the rubber hits the road. It is where psychology meets mathematics.

Sure, the player will be grinding trophies and moving along the Trophy Road, but we also want this activity to feel as pleasant and as rewarding as possible. This is a game and it should provide entertainment. This is the only way to ensure the long term retention which is the purpose of this entire feature.

Linearity is predictable and boring. Curves are much more fun. What we want to do is to allow players to unlock new tiers relatively quickly at the beginning of their journey. We want to let the unlocking of the tiers fall in a steady rhythm later on. By letting players unlock a lot of tears quickly at the start, we help him get emotionally engaged with the feature and the game more quickly. Later on when the player is already committed and has already established his gameplay routine, we can make this rhythm slower and more predictable.

It would seem unusual if a player would unlock more than one reward tier after playing a single match. The number of points that a player earns for a single victory, or the average expected number of points that the player earns per match, provide us with the first building block.

What I usually do is let the player earn the first reward after playing one, maximally two matches. I also make sure that the player actually wins those matches. The trophy threshold for the first reward tier I typically set, is the number of trophies that the player gets for a victory.

I set the number of additional trophies that the player needs to earn for the next following tiers using the same value. I then gradually increase the trophy gaps between tiers until I reach a particular steady value which I then repeat for the remainder of the trophy road.

When the rhythm settles, I like that my Engaged players are able to unlock a new reward tier at about once per day. In other words, a day of relatively engaged gameplay should earn you a new Trophy Road reward. Casual players would of course move through these tiers 2 or 3 times slower, meaning that a casual player would be unlocking one reward tier every 2 to 3 days, which is still not too bad.

Of course, depending on your preferences, and the nature of your game, and the audience you can make this rhythm faster or slower. You can use the velocity of the casual player as guidance. You can make it so that your Casual player unlocks one tier reward per day and that your Engaged player gets to unlock 2 or 3 tiers per day. There are two things to consider though.

One is the content amount that you need in order to make these rewards feel meaningful. This is up to your production pipeline and its capacity.

Another tithing to consider is directly related to learning how to err on the safe side. We made a lot of assumptions about players’ behavior. By definition these are unreliable. It might be the case that your assumptions are widely wrong and that you would need to rebalance your Trophy Road after it goes live. You are free to make things easier or harder for the player. However, making things easier always feels better than making them harder. Err on the safe side. Make the Trophy Road thresholds as high as you dare. Later on you can always make them lower! This is far more preferable than having to make them higher because most of your players are blasting through it at a too fast pace.

Finally, plotted on a graph your point thresholds should form a nice S-shaped curve. This curve matches the shape of the proverbial learning curve of an average player, i.e., the way how a player’s skill improves over time. In this way it corresponds to the player’s expectations.

Chart of additional trophy count needed to reach a particular tier.

Chart of cumulative trophy count needed to reach a particular tier.

Now that we have the Trophy thresholds determined and reward tiers distributed, it is time to finally do the fun part and place the actual rewards in those brackets. This is the icing on the cake. One thing to note here, is that you must have rewards that seem attractive to your player. Second, you need to have diverse rewards. This can be harder than it seems.

Assume that you have a relatively simplistic metagame. One that revolves around character collection and nothing additional. Typically, this type of games are focused on the character collection and deal with only a handful of resources, such as character shards and soft and hard currency.

You can use a bit of smoke and mirrors to create variety in your rewards. You can use character unlocking as a reward itself. You can give out bundles of several character shards for each individual character. In addition you can give piles of soft currency and bits of hard currency. You can also take two or more of these resources and pack them in a loot chest. Further, you can create different sizes of loot chests. In this way, you can create an illusion of the variety in rewards you place along your trophy road. This is just a guideline and not a rule. Some games get away by simply placing gacha boxes on such features.

Variety of rewards in Zooba Trophy Road

In general, I like to think about rewards by dividing them in two categories:

Prime rewards are the stuff that are attention grabbing. These are the things that any player would want to have. In our example, unlocking a new character would be one typical such reward. These are rewards whose value can be easily perceived at the first glance. Bits of hard currency are also a good example of such rewards. Big gacha boxes can also act as such. These rewards will act as short term aspirational goals. On the other hand, the filler rewards are not simply a stocking stuffer. They are a foil for the prime rewards. They are there to serve as a contrast, underlying the value of the Prime rewards.

Calculate how many primer rewards you have, or can afford to produce. Place them in a steady simple pattern onto the Trophy Road. Every 4th or 5th tier can be a good rule of thumb. Ideally, an engaged player would be at the beginning unlocking one such reward each day, and once a week later on. In this way these rewards can really serve as midterm aspirational goals.

I like to place the first prime reward into the second or the third tier of the trophy road. I place some filler reward as the first one that player wins. This is deliberate. I want to reward a player for the first victory. The act of collecting any reward is in itself rewarding. The first juicy reward should require some persistence and repeated effort. Not too much of it, as I want it to be within reach for even the Casual players.

Since a trophy road typically has a lot of tiers, you will likely implement it using some scrollable UI. When designing it, make it so that the player will always be able to see at least one prime reward on the screen. In other words the relative distance between two tiers offering prime rewards should not be bigger than one screen.

Prime rewards on display in Trophy Road in Brawl Stars.

Once you have the prime rewards placed in this pattern, fill in the remaining tiers with filler rewards. Scatter them around to make the trophy road feel rich and diverse.

An important thing to consider, when rewarding out bundles of soft and hard currency, is the amounts that you are giving.

As always in free-to-play design, you do not want to inflate the currencies by giving out too large amounts. Also, any reward system is by definition an extrinsic reward. Players should play your game because the game itself is fun, you should not bribe them to play it.

To determine the right amount of currencies to give, it is good to again think of time. Player’s progress through the Trophy Road is effectively a measure of his effort, i.e., it reflects the amount of playtime. Use the velocity estimates to decide how much of each currency you are willing to give to a player for a specific amount of playtime.

In this way you are establishing a correspondence between each of the currencies and the play time. If you are making a feature for an existing game, you most likely already have these ratios already established. Furthermore, you can use your telemetry data to derive understanding of player spending patterns. If you are building a new game, take this new source into account when designing currency sinks. Player should be expected to spend all the currency he gets in the same amount of time.

The methodology I have described focuses on one type of feature in one type of game. It is however applicable more or less directly to other similar types of features, such as premium pass or limited time event tracks. The general approach which takes into scout gameplay time and velocity of point grinding is applicable to a much bigger variety of features.