In my few years working in mobile – on the business performance side of things – I’ve had my fair share of conversations about how delicate producing and monetizing content can be. One recurring (and valid) concern is the need to have your game systems balanced. However, the way you understand “balance” has a great impact on how you approach releasing new content – and monetizing that content. Perhaps paradoxically, it’s crucial to think about balance in a dynamic way. All games monetize content in one way or another (at different points on the direct/indirect spectrum). Mobile games – like all other forms of entertainment – need to periodically introduce change and novelty to keep users engaged. So, finding a way to keep your game balanced while introducing new content is key for its long-term success.

2 types of equilibrium

If you remember your physics classes, you might recall that being in equilibrium doesn’t mean being immobile. When a system is in equilibrium that means all the forces that apply to an object are balanced (you can check this random page on the internet to get a more detailed explanation – I’m no expert here).

What this means is that both a puck at rest on the ice and a moving puck are in equilibrium – but in different kinds of equilibrium

So how is this relevant to mobile games (and why it doesn’t really matter here that I’m not an expert)? The notion of equilibrium in physics is a good analogy for the notion of balance in your game. You need to make sure all the parts are interrelated, and that things don’t move apart over time. This is valid for both your core loop and your economy. For example, if it takes 90 days for a new user to complete a specific level the month your title is launched, and 14 days 2 years into the exploitation of your title, then your game is not balanced. And that’s not sustainable. In a similar way if players accumulate way more resources than they can spend (just think about all those games where you end up with millions of a given currency), then that currency loop is not balanced – and everything related to it becomes irrelevant.

Many conversations concerning game systems and balancing tend to associate equilibrium with something static. According to this view, you have the game’s core loop and the different systems that compose it. And balance refers to the equilibrium of that closed system. In this case, game systems are treated as something that must be balanced in themselves without any external input. This understanding of balance promotes a very specific ideal for game design. The goal is to have a game system perfectly self-sustaining and closed on itself: a game should be able to keep players engaged and monetize on its own, without requiring the input of new content (and in extreme cases of offers). The same core loop will be successful for years without altering the interrelation between the parts. Let’s take the example above about completing levels and assume the game is an RPG. The game will be balanced according to a specific power/level of the characters. If you have a static understanding of balancing, any feature that provides more resources/XP or introducing more powerful characters would break the balance you designed for the game.

The aspiration to static equilibrium is counter-productive for your game

Of course, just like in physics any concept of balance/equilibrium is ideal and theoretical – there is no perfect equilibrium on the hockey rink, just like there is no perfectly balanced game. It’s all about acceptable thresholds. That’s why a static definition of balance and equilibrium in game systems is counterproductive for a number of reasons. First, it tends to treat the game and game systems as an end in itself. I’ve written before how dangerous it can be to think about what your game is rather than the impact it has on player behavior (for example here and here). Building a core loop and the systems around it is not an end in itself – it’s a means to an end. When you lose track of that you’re building a game in the abstract – not a player experience (which is about players way they interact with the game). The second problem that derives from this is that the game is not designed to evolve and absorb new content without jeopardizing its balance. Every new external input (in this case external input is any new part of content – such as new characters for an RPG, new weapons for a sniper game, or even new levels) creates a strain on the game that worsens over time and impacts player behavior.

You can’t escape monetizing content

When you approach balance in a static way – and you design a game accordingly – you are leaving out a large portion of what makes a game a viable business product. Having a static understanding of balance could be fine if it were possible to operate and monetize a game over time without introducing new content. However, that’s usually not the case – expect maybe for hypercasual games or any game that has a very short user lifespan (as in, little monetization coming from users 30 days + after install).

There is an understanding of game design and monetization that pits them both against each other in a zero-sum game. What that means is that gains in monetization are assumed to be done at the expense of good gameplay and design – and vice-versa. This creates a false alternative (monetization or fun) that can be a very damaging for the game you build and operate. More importantly for the topic at hand, this assumption usually rests on a static understanding of balance (and also the idea that you monetize negatively – by creating friction and capitalizing on negative emotions).

This is counterproductive because the ideal of a self-sustaining game loop – while interesting from the point of view of design aesthetic – doesn’t really hold up when confronted to the reality of mobile gaming performance. Players consume your content one way or another: either they consume it by acquiring it (weapon, time-limited XP boost, character, space on the map, etc.), or they consume it by completing new levels or missions. RPGs constantly introduce new (and more powerful) characters, Clash of Clan introduces new troops and features, Slot games introduce new machines. Even Candy Crush is continuously releasing new levels. Even though the monetization of your title is front loaded – a significant portion of your revenue comes from users within the first 30 days of install – you need to make sure your fans keep engaging with your game long-term. And in order to achieve this, you need to be continuously providing your fans with new content.

Release content without breaking your game

For your game to continue performing long-term, you need to accommodate 2 different requirements. 1) you want your game to be balanced and 2) you want to be introducing new content at regular intervals. The best way to release content without breaking your game is to design your game and systems to accommodate this regular input. That means you need to be thinking about the content release pipeline while you are building your game systems: how will the system absorb the new content over time. You need to be designing your game with your events or content release strategy in mind. You can’t just design an isolated core loop in equilibrium and start pumping out new content after launch. That would effectively amount to slapping a live ops system on top of a static core loop.

If you think about your game systems in a static way, then you might face an important problem down the road: how do you make sure the game is still balanced once you introduce a bunch of content you didn’t build your game to accommodate? You need to design your game and think about how you will introduce new content over time, and how this new content will interact with older content and fit into the game loop. In simpler terms, you need to design your game with some kind of inflation in mind, and ensure over time the game can adapt.

It can be difficult to build a game where content is entirely dynamic from install day. That’s why it can be interesting in this case (as in most cases) to be more pragmatic than dogmatic. Just like static equilibrium should not be an end in itself, neither should dynamic equilibrium. It’s not easy to have a system where the latest new content released has an impact on early user experience. And rather than building a purely dynamic system, it could be better to segregate new game user loop and “elder loop”. Think of 2 relatively hermetic game loops that don’t interact with new content the same way. That way you can still hand craft your early player journey (which is critical to the good performance of your game) and have a separate loop in which the new content is pumped into and drives your business performance. You can then design 2 relatively independent tiers in your game – the “static” early game, and the “dynamic” elder game which interacts with the new content.