How to tune your game progression with user experience in mind

The Ice Wizard has been in my Clash Royale deck for a long time. In the August 2017 balance update, the Ice Wizard got a +10% damage buff. A 10% increase in damage is not much: it meant the Ice Wizard would do an additional 6 or 7 damage points per hit depending on his level (for context a level 12 King tower has over 5000 points). But that small buff meant a gameplay change that proved pretty significant.

Clash Royale updates are framed in a quantitative way: +10% damage, deploy time from 4 to 3.5 seconds, range -11%, etc. But those updates provide a great window into what is guiding the game’s tuning philosophy. It’s not so much math, empiricism or a Goldilocks thing: +9% feels too weak, +11% feels too strong, +10% feels juuuust right. For the Ice Wizard, the tuning process was not an abstract process – what drove the balancing process was the desire to address a very specific and tangible situation. Up until that point, the Ice Wizard could not one-shot skeletons. With an additional 10% in damage he now could.

The framing of balancing changes in abstract, general and quantitative terms occults the fact that what was intended was changing a very specific situation. The goal of this specific balance update appears guided by a very qualitative consideration: to allow the Ice Wizard to one-shot skeletons (and by extension keep Skeleton Armies in check thanks to his AoE). Stated differently, +10% damage is the output, the consequence of a design decision. Namely to enable Ice Wizards to better deal with Skeleton Armies. And the same can be said for many changes. In the October 2018 balance update the Goblin Hut saw its spawn speed decrease from 5 to 4.7 second. What’s relevant here is not the fact that spawn speed decreased by 6%. It’s that the Goblin Hut would spawn one additional goblin. In that same update, the Ice Wizard’s slowdown duration increased from 2 to 2.5 seconds. That buff wasn’t implemented because a 25% increase in slowdown was optimal across the board. It ensures the Ice Wizard’s slowdown effect will be effective when facing the Electro Wizard. Things might not be formulated in a qualitative way, meaningful from a game perspective – but that’s undoubtedly what’s driving the change.


Tune to create a specific user experience

This example provides great insights into what should be driving the tuning process for your progression and/or engagement in any game. By progression I mean the time/effort/actions required to attain a specific level or unlock a specific feature via in-game actions. I addressed some ways to approach price tuning here.

It can be tempting to consider tuning as a numeric process disconnected from a real and tangible (read: qualitative) user experience. Although you are dealing with numbers, the balancing of your game should always be driven by very real, specific and tangible user experiences. You need to be tuning your game with very specific user experiences in mind – and find the numbers that will match that experience. Not the other way around. You can’t be approaching your tuning process as an isolated and ideal spreadsheet. You need to tune with user action, audience or game behavior in mind. You first decide what kind of experience you want to foster, what kind of action you want users to be able to do, and then find the values that will allow you to achieve that. The number can’t be disconnected from the desired experience – it’s driven by a desired/required experience.

Say for example you are setting up a limited time event: for one day users get points by playing missions (that makes for a slightly unoriginal event but a good example). What needs to be the guiding principle to determine how many points unlock the final reward? You are going to need to figure out how many missions users need to play to get the reward.

The main question has to do with determining the criteria for the required number of missions. You can start by saying you want users to play 10 missions to get the rewards because that number “feels right”. That’s not a great reason. Alternatively, you can choose 10 missions because it’s based in some game feature and economy limitations. For example, your game might be set up in such a way users can only play 8 mission a day for free. Setting the required number of missions at 10 would mean users will need to spend money to get the reward.

Another way – the one I think works the best – is to use the data you already have available to specifically target who you want to obtain the reward. If your game is live, then you already know how many missions users are playing and what that distribution of users looks like. And that’s also why when finding the values that will help you tune your game, you don’t want to be looking at average numbers. You are not in the business of reselling missions – you’re in the business of enticing user behavior (by means of missions played). So, when you have live data, you want to convert how much questions into who questions: what is the number that corresponds to the behavior of a given user segment? One way to do it is look at your player percentiles.



The point here is not you should choose the median, your top 10% or your top 1%. The point is you should start by identifying what user experience are you after – and no math will help you here; you need to make a judgment call – and then find the values that reflect that user experience. You need to tune knowing the segment of users you are targeting and want to influence – and what their default behavior looks like. The least ambitious – but most succesful – approach is to match as closely as possible the way users are playing (rather than trying to get them to change their play behavior).

In this case, if you wanted to reward most users for playing the way they usually do, you can decide the reward unlocks after 3 missions – and determine the arbitrary points/mission ratio that pleases you best. Alternatively, you might want to leverage your event to be enticing and make your top users play (slightly) more than they usually would. You might want to require your top 25% players to play 2 missions more than they usually do to get the reward: in that case you set the requirements at 10 missions (8+2).

Ultimately the numbers themselves are secondary. The real question you must start by asking is: who do you want to get the reward? Once you have data available, you are able to fine tune your game with a specific audience in mind. It’s not about the number, it’s about the segment of users you are targeting – and the number that matches their behavior.


Tune progression with your non-payers in mind

Any time you are working within an OKR framework and have measurable targets, you want to specify as precisely as possible what users you are considering. There are huge differences in behavior between a new game user and a tenured user, or between a non-payer, a user who paid once and a user who pays regularly. If you are not being specific, then you are at risk of not really measuring the impact of your feature or balancing – but rather measuring changes in your userbase. For example, targeting users with a minimal level of engagement – such as having returned to the game after a period of time following install – can ensure what you are measuring is not impacted by contingent changes in install volume.

When you are tuning progression, tuning with non-payer behavior in mind is important. By non-payer behavior, I mean looking at actual play patterns of non-payers. In other words, don’t look at play patterns of all your users (in the example above, the percentile of missions played), but specifically of your nonpayers.



One of the main reasons for that is that ultimately you don’t control customer behavior as much as non-payer behavior. Non-payers are constrained by the amount of resources they get from the game. Customers on the other hand can circumvent the in-game resource loop by making an IAP. From that perspective, an IAP is an external input of resources you don’t control. So, the first reason to focus on non-payer play patterns when tuning progression is that when you do that, you are actually tuning your game balancing – with no external inputs. So, you are tuning while considering what you have under your control.

The second reason you want to tune your game progression with your non-payers in mind is that you are setting up your IAP offers favorably. When you tune your game progression with your nonpayers in mind, you are automatically creating an environment in which IAPs are rewarding and help users progress. If you are selling only cosmetic items in your game, then clearly there is no room for advantage. But if what you are selling has even the slightest functional and instrumental value, then a customer will always have an easier, smoother or faster progression than a nonpayer. If you tune progression with your non-payers in mind, then you are by default setting up your IAPs as (optional) cherries on the top (that’s not always the best monetization option – but that’s another topic). Presumably one of your goals when setting your progession is to pace your users and the speed at which they unlock new levels and features – as well as create strategic friction points. When you tune with the experience of your non-paying users in mind, you are putting yourself in the best position to achieve that.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s