With the explosion of Early Access and the philosophy of Games as Services, the lifetime of a game has changed dramatically in recent years.

In previous days, a fast internet connection was a given, games were delivered to the public in their final form. Expansions might add new content, but they generally wouldn't change what had previously existed. Nowadays however, players are faced with ever-changing games and have to adapt to this new trend.

When I last went back to my hometown, for the winter holidays, I was faced with a similar feeling while driving through the familiar landscapes yet experiencing something new.  Strangely this sensation made me think of my experiences developing games in Early Access and Post-release at Amplitude Studios.

Thinking about it, I was quite impressed by the commonalities between updating a game and urban planning. This might be because they share common attributes:

Now, let’s explore what we can learn out from that, how it can help us to approach the new life cycle of games.

Changing signals

There is this road in my hometown that used to be restricted to 90 km/h. I drove onit thousands of times while learning how to drive, and I’ve driven onit thousands more since then. However they’ve changed the speed limit now: it’s 70 km/h, and it is further reduced to 50 km/h at certain times of day.

Reducing the limit made sense, as shops and houses have been built along this previously deserted road. Even so it feels wrong to me: I’m so used to going down this road faster that being restrained feels unpleasant and unfair to me no matter how logical the limitations are. I’ve lost my freedom and can’t enjoy the same excitement as before.

This is what it can feel like for players when we change the game balance with updates. Players form habits while playing and build mental models of the game: which paths are viable, what is fun to do... The risk with updates that change gameplay values is that players need to rebuild their mental models following the update, and can get frustrated.

As designers, we need to refine the game by fixing flaws and adjusting the balance.  But when we do so we need to keep in mind the following questions:

For instance, let us imagine that the laser-gun weapon is really strong and used by all players. To fix it, you can either:

In the first case, you will certainly create frustration for players used to building their strategy around the laser-gun. Even if the change makes sense in terms of pure mathematics it will likely not be well received by the players: why did you just break my favorite toy?!

Still, if the decrease in effectiveness is low enough, it will not bother most of the players, who will probably not even notice the change.

In the second case you can decrease the effectiveness of the weapon just as much without vexing players by rendering their prior understanding of the item entirely obsolete. After all the weapon in isolation is just as strong as it always was, it’s only less strong in practice given the new context (new or stronger counters).

What’s more, encouraging players to use a strategy that counters an effective one, rather than discouraging the use of said effective strategy, provides opportunities for countering the counter and so creates new competitive play dynamics.

To balance a live game the key is rebalancing underused content to counter overpowered content, rather than directly reducing the power, or “nerfing”, the overpowered content to a level that fits the rest of the game.

You can also add new content instead of rebalancing the existing one, but beware of “content creep”.

Changing the layout

During my last visit in my hometown, I took time to visit a friend I had not seen for years. I passed my high school going towards downtown and got lost. Some roads appeared, new roundabouts, I had no idea where I should go. At that moment, I experienced an irrational feeling of fear and sadness: I was not at home anymore. The world had changed.

Many people experience a similar feeling  when the global layout changes: a road is removed, a bridge is added. When this happens you need to re-draw your internal maps, destroy and rebuild your mental model. The removal or addition of constraints can also trigger this need to rebuild: adding a “one way” sign, for instance, or transforming a yield sign into a stop sign.

As players dive into your game, they learn its rules bit by bit, completing their mental maps of your systems. This exploration is part of the pleasure, and discovering new connections, and unnoticed consequences to actions can be thrilling! But being forced to throw away this acquired knowledge is frustrating....

When updating a game system on a live game, I would recommend keeping in mind the following rules:

Early Access is meant to be a way of building up your game with the community, and should allow you to test options. While reworking game systems during Early Access is generally accepted by players, it becomes less acceptable to do so after the release - even if it’s for the greater good. There are plenty of examples out there of resistance to change from players post-release.

Here we can draw a parallel between urban planning and game development: accepting changes during Early Access is similar to accepting temporary constraints due to ongoing roadworks, whereas changes post-release are like a new change to road-signage which forces you to change your daily commute.

The same negative feeling often occurs when developers remove content. Adding content is a normal thing to do as game development progresses, though we’ll still need to discuss adding content a bit later. For now, let’s focus on the removal of content as part of the life-cycle of a game.

Game systems can be invisible for players, thus they will not build a strong attachment to them. It can be hard to differentiate the deletion of a system from the modification of an existing one, or even the addition of a new one. Players will have their own mental model of the game and might have their own vision of what systems make up the game, and this vision can deviate wildly from the designers’. And, let’s face it, players can even have a better idea than the designers of how the game really works (we designers are often more concerned with how it should work than how it actually does). But anyway, this doesn't really matter for us.

On the content side, however, it’s more delicate. Content is the fixed, physical reality that players interact with. Deleting it is immediately visible and loss aversion means that it will essentially always be missed. When a player launches a game and can’t find his or her favorite weapon, their emotional reactions can be irrational and strongly negative, even if the change actually improves their game experience.

During the Early Access periods of our games we often removed technologies, as the Tech Tree of a 4X game evolves a lot as player feedback is collected and new features are introduced. As it’s the foundation of the 4X game experience we’ve always spent a lot of effort making it as good as possible. In the end, the conclusions we drew were the following.

Do not remove content from your game. It’s better to either:

Loss aversion might still hit players, but it will be partially compensated by what they gain. We can bet on the renewal of the experience and the joy of the discovery to lessen the frustration.

The second option is useful when you need to change an element with a strong connection between lore and gameplay.

The danger of such a solution is that players can miss the change and keep playing as they previously did. This might seem like a good thing except that when they finally do notice the change it will be in a context of failure, when an unexpected outcome occurs. This can be avoided by using dedicated signs (highlighting with an exclamation mark the element that has been updated for instance).

The other challenge is the acceptance of the new effects. Players need to agree that the new effects make sense and are a good substitute for the previous ones. To support this process you can play around with:

I would recommend using this option where possible, notably where the effects are disconnected enough from the element’s identity or where the new effects still make sense with the original identity.

Let’s have a look at a concrete example now!

Endless Space: Disharmony, the beginner’s mistake

When we started designing the first expansion for Endless Space 1, we listed the biggest issues reported by the community, and prioritized them. One of the concerns was the depth of the battle system: players found it too bland, with a clearly identified dominant strategy.

As a good designer, I tried to think about how to solve the issue efficiently. The battle system is built on key features:

(complete info can be found here: http://endlessspace.wikia.com/wiki/Combat)

The issue with the system was the players’ focus on long range: if you can destroy enough ships before they get close you needn't invest in defenses that work against short- and medium-ranged weapons. To avoid stalemates weapons necessary need to be cheaper, in terms of tonnage, than defenses. As a result, if you spend all your tonnage on long-ranged weapons an opponent attacking at a different range will first need to survive your attacks, and doing so won’t leave them enough available tonnage to properly counter-attack.

When I designed the Disharmony extension, my objective was to solve this issue. Even if the battle improved overall, and there was no more clearly dominant strategy, I made two big mistakes.

The first one was to consider that all our players were interested in the battles and wanted a deeper system. Some of them were happy to have a simple system they could play with, without investing too much effort. By deepening the system, adding new concepts and layers, I forced them to relearn a part of the game they were not interested in to begin with.

The second mistake was not the update of the game system in itself, which our players accepted quite quickly, but the change of ship design interface. In order to clearly communicate the changes and help players with the design of their ship, we completely revamped the ship design UI and our players were lost. They’d spent dozens, even hundreds of hours with a given UI. They’d formed habits and we had “ruined” everything. It was not a matter of any objective measure of quality, but rather an emotional relationship with the game that turned against us.

A similar situation occurred during the Early Access of Endless Space 2 with the technology tree: we decided to build upon what we had learned from Endless Legend. Thus the technology tree looked and behaved similarly to Endless Legend’s.

When the game hit Early access and the players tried it they were surprised by our choice as they expected Endless Space to have a stronger legacy in the game: ultimately they wanted to go back to a similar tech tree.

They did not really care about the intrinsic quality of this new technology tree, for them it simply wouldn't be an Endless Space game if the good old tech tree was not there. In the end, we spent months revamping the tech tree, and ended up with a shape that suited both players and designers. :)

Dead Cells: how to do it properly

During the early access, Motion Twin updated the upgrade system of their game Dead Cells, which had been in Early Access for a few months already.

Initially, players could choose between 3 upgrades:

However, a dominant strategy emerged: most of the players were focusing on damage (red) upgrades only (as killing monsters as fast as possible in a Metroidvania game is often the best way to survive).

They thus changed the system to:

It’s a clever way of dealing with the issue as it opens the possibility for more combos without breaking previous player habits. Focusing exclusively on red upgrades is no longer a dominant strategy, but if someone comes back to the game and does so out of habit the life and damage provided by certain items will still increase, so they will still enjoy their playthrough.

Cultural shifts

When driving we tend to forget that we have internal constraints derived from our cultural background and from local laws.

For instance French and German drivers don’t use the same signaling system on roundabouts. In France, you indicate left if you plan to exit on your left, and then indicate right just before the exit. German drivers only simply indicate right when they are about to leave the roundabout.

As a French driver in Germany it’s quite surprising at first, as other drivers are confused and make false assumptions about where I want to go.

Another example is the difference in passing cars on highways between France and the US (as a French person, it’s easier for me to compare France to other countries). In the US you can apparently passa car either on the left or on the right, while in France you can only pass on the left. Indeed, passing on the right is illegal and you can be fined for doing so!

When I drove in the US, this difference  forced me to form new habits. Luckily while passing on the right felt unnatural, doing so on the left would be insane on the 5-lane highway: changing your habits is easier when what is expected of you makes sense, and when your surroundings push you towards the new behaviour.

I could give other examples, like how a different side of the road is used in France and the UK or the law allowing right turns at a red light in the US... But let’s instead look at the game side of cultural shifts!

A cultural shift can occur in the foundations of your design, as players might have different habits and expectations from yours. These expectations might be related to the color-code you develop, the symbols you use for signs and feedback, the layout of your UI,… etc.

I would stress the importance of identifying your audience and looking for what its members have in common : what assumptions and what common ground can you build on? Hopefully, a positive side effect of globalization for game developers is the weakening of culture divergence.

The shift can also happen when you break the code of a game genre. Players will judge your game by its cover. When the mechanics unfold, they will develop expectations (about required inputs, signs and feedback) based on similar games they have played before. As Brian Upton says, they will develop a default “horizon of intent” based on what they could do in other games. This doesn’t mean that we are obliged to follow the code of our predecessors, but it does mean that if we don’t, we need to clearly communicate to players how we’re diverging from the norm.

For instance, I recently tried a student project that looked like a “Roguelike” game: it had perma-death, character progression during the run and a high difficulty. My initial working assumption was therefore that the level was procedurally generated and that it was changing every run. In fact the game is built around the fact that the level will always be the same: players can thus iterate on their exploration with each run. The designers broke a convention but didn’t insist enough on communicating it, which led to a “wrong experience”: I didn’t play the game as they wanted me to play it.

A similar criticism can be applied to the Heavy Rain character controller. In such a game, players are used to using the left stick (whether the referential is the camera or the character) to move around. In Heavy Rain they instead used a car controller and applied it to a human character: it instinctively creates a dissonance for long-time players. But with time, and for newcomers, this control scheme works pretty well and serves the overall gameplay.

When you break a convention you destroy players’ assumptions, so be sure that the change will benefit your game and that you communicate it well!

Another concept I’d file under cultural shifts is how we’ve changed our way of thinking cities and roads: how trade, industry and technology have forced us to rethink our urban plans. It’s easy to tell an old city from a recent one, as they are structured quite differently.

Throughout History some cities have been modernized, such as Paris which was adapted by Haussmann in the 19th century to improve navigation and to adapt it to a new technology, the car. Still, cities can reach a point where they cannot be renovated anymore: either it would be too expensive or the public opinion would be against it because of cultural and emotional attachments.

We face similar issues with games in Early Access, or even during Live development. The common issue with continuous development is how new features interact with past content.

For a game in Early Access developers have to add new content for each update. As discussed earlier, profoundly modifying this content with later updates can cause a ruckus. Hence there is often a weak relationship between content added at the beginning of Early Access and features added for release: editing the old content might be possible but it could cause frustration, because player would be losing a beloved toy, forced to break a habit, … etc.

The same questions arise when designing expansions and DLCs: how do we deliver refreshing new content while keeping the feel of the initial experience intact?

When dealing with the design of systems, there are 3 main approaches:

This is the panacea for early access and DLCs! It changes the experience with an additive approach: players will need to add to their mental models, which is engaging, but won’t suffer the frustration of having to tear down their previous assumptions.

The downside of such systems is that, by being autonomous, they require higher cognitive load from players, and adding too many will make the game overly complex.

As such, thinking in terms of autonomous systems is a powerful tool, but it needs to be used parsimoniously!

The biggest advantage of such systems is that they reinforce the value of dedicated entities, pushing players to pay more attention to them, and to diversify their approach to them. Moreover, if several entities are embedded in the system it can change (or create) relationships, opening new ways of playing. Learning can also be easier if players already understand the basics. This can be interesting and even fun, but only if the changes are limited to a few entities.

However, there are risks in production:

Parameter-based systems are a really good approach for live updates, in order to push expert players and break their habits, but be careful with scope!

The immediate benefits of this approach are huge:

The biggest downside of this approach is the way it diminishes the value of the older content. It is so accepted that disparities between old and new content are unavoidable that many TCGs have embraced the “active expansion pattern” to ensure that old content does not distract players. This can mitigate the issue and, as an added bonus, makes balancing a hell of a lot simpler in the long term :).

But for some games this approach cannot be taken, thus you should carefully weight how the new content will feel compared to the existing. In addition to adding something new, you should find some way to reinject value into the existing rules!

Think in modular terms as much as possible and be careful not to fall into the complexity trap with the accumulation of updates.

Preparing users for what’s coming

Drivers are informed months prior to any major change to a city’s urban plan, so that they have time to accept the changes before they come face to face with them.

Even if this doesn’t change how they feel at the beginning, having time to digest the proposed changes can make it easier to change your habits when the time comes. Some drivers will even begin to adapt their behaviour before the changes actually occur.

As a result, those who really suffer from the changes are those few people who, like me, come back to an area with no awareness of what has changed since they left.

When we update our games, we often rely on the release notes (which are very detailed) to communicate with our players. However, we forget two important things:

To improve the communication with players we could:

Hearthstone is doing a great job by showing cards that changed after the update directly in game, but there’s no way of comparing the current version to previous iterations. As a result, it’s nice for expert players but less useful for casual players. Moreover, you don’t know if you have to update your decks unless, again, you’re already an expert player. The next step would be to streamline this process and provide signs telling players that their decks contain cards which have been modified since they built their deck.<

End of the road

It’s only recently that I’ve realized how powerful metaphors can be. I’ve noticed, having read many design articles and having had many wonderful discussions with different designers and developers, that metaphors were the key to communicating complex notions.

What is fascinating is that metaphors can be used for expressing a global concept, as above, but they can also be used to build an entire methodology as Daniel Cook did. In addition using metaphors is a simple way of starting down the road of thinking in systems.

UX uses the notion of engageability, “Teach the why” as Celia Hodent would say. Metaphors are engaging when they are easy to grasp, and if the person you’re talking to can project themselves into the picture you are describing.

To go further, beyond metaphors, in order to improve the onboarding of your communication, you should use stories to communicate your knowledge. But that’s another topic.

To summarize, I extracted these lessons from the previous games I worked on:

To conclude, we should always look at what’s happening in other fields and which lessons we can take from them. Keep your eyes and your mind open, and share your conclusions with as many people as possible! Do not hesitate to comment, to share your stories, tips or if you feel something might be done in a better way!