Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
How we experience cities can provide meaningful insights into game balance, managing content and onboarding when updating games.
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:
There is a desire to build the best possible experience for users, considering the available resources.
They are both subject to subjective criticism built on personal experiences.
Both games and city plans need to evolve to answer not the issues raised, but the true underlying causes.
Now, let’s explore what we can learn out from that, how it can help us to approach the new life cycle of games.
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:
How will the changes be perceived? Will they completely change the feeling of playing the game or will they be small enough that previously valid patterns of behavior still work (albeit more or less effectively).
How will it affect player’s behaviors? Will it reinforce existing behaviors or will it encourage new ones?
For instance, let us imagine that the laser-gun weapon is really strong and used by all players. To fix it, you can either:
Decrease the power of the weapon itself,
Add counters (say, an energy shield) or improve the effectiveness of existing counters.
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”.
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:
Don’t increase the level of complexity! To fix a system that does not work properly you shouldn't add layers that will make it harder to understand; the new system should impose a similar cognitive load on the player. Otherwise, you might draw undue focus to the system and change the overall game experience by shifting the relative importance of the different game systems. Obviously you can break this rule if you want to give more importance to a system on purpose.
Don’t deviate from your intention! When reworking a system that is not as interesting as planned, it’s easy to move beyond the boundaries you initially defined. Still, it’s important to use these constraints to be creative and to find a solution that will serve the game instead of starting again from scratch. Try to keep as many elements as possible, and focus on how to rework them elegantly, to either modify the input or the output (Ideally, you modify only one of the two for a given iteration).
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:
Replace it: the old content is gone, true, but something new is unlocked / placed exactly where previous content was.
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.
Revamp the element completely: keep the name but drastically change how it behaves in order to reach your objective.
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:
the values: raising the values, even if in practice this doesn’t mean this piece of content will actually be better.
the quantity of effects: having 2 effects instead of 1 will often be seen as an improvement, even if each effect is less powerful.
freshness: adding something the player didn’t previously encounter will give them a nice feeling and be accepted easily. Add an exotic rule, a new type of effect that was not used before.
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!
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:
The battle is divided in 3 rounds: 1 long range, 1 medium range and then 1 short range, always in this order.
There are 3 weapons, each of them best at a given range.
Each weapon is countered by a specialized defense. Missiles are countered by Flak, Lasers by Shields and Kinetics by Deflectors. Each of these defenses however is built around its unique mechanics.
Flak: we roll a die to see if they manage to intercept a Missile.
Shields: they absorb X damage from Lasers, regardless of laser power.
Deflector: they counter X Kinetics projectiles, regardless of the amount of damage dealt by each projectile.
Players can design their ships from scratch. A ship has a tonnage value, and each module has a tonnage cost.
(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. :)
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:
Red = damage increased
Green = life increased
Purple = support efficiency increased
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:
keeping the same 3 color upgrades but,
each game item is now associated with one of these colors,
upgrading a color increases both the life of the character and the damage provided by items with the corresponding color
bonuses to life are smaller and smaller as the player accumulates upgrades of the same color.
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.
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:
Building autonomous systems that will modify the game dynamics indirectly. We consider the Weather system of Endless Legend: Tempest to be in this category. We added modifiers on ocean that will influence unit movements and apply bonuses / penalties in battle. They move each turn following the wind direction, pushing players to anticipate their journey through oceans. It’s a new layer which modifies how players approach navigation on the maps without adding new parameters to the existing content.
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!
Building parameter-based systems.These systems use dedicated parameters attached to game entities to interact with them. It can be illustrated by systems such as the Spying of Endless Legend. Heroes can now infiltrate city to sabotage an opponent, while new options in the city allow to capture them. We built this around a set of new parameters added to the Heroes and the Cities.
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:
Don’t underestimate the workload required to update a large number of entities, and the resulting balancing work. Also, the new system will probably require specific signs and feedbacks, maybe even changes to 3D models!
Don’t write yourself into a corner! Be sure that the modified entity will be able coexist with later content, and that it won’t be touched by later systems. If you have several DLCs adding different parameters to the same entities, and if you want players to be able to activate different DLCs independently, data management can become a mess. If you don’t have a modular approach to your data you will end up crying a lot.
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!
Building content-based systems. Here the system is reinforced through the addition of new content or new rules. This is common in TCG (Trading Card Games) or puzzle games. The battle system in Endless Legend works the same way: new units bring new abilities with them, changing how players must approach the resolution of battles.
The immediate benefits of this approach are huge:
It’s easy to add content and to scale what you can do depending on the scope of the update.
It immediately gives a feeling of novelty! Content is easily noticed by players.
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.
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:
Only a small portion of players actually reads the release notes.
We only describe what changed between the current and previous update, so if you skip even one set of release notes you might miss valuable information.
To improve the communication with players we could:
Put the release notes in-game in a more condensed manner (Paradox prefixes its release notes with a “Developer’s Intention Note” for instance).
Provide the information to players when they need it: for instance when they first interact with an element that changed since their last session.
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.<
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:
Changing your game balance will have emotional consequences that shouldn’t be underestimated.
Never remove content, but try to refine it to improve your canvas!
Onboarding is not only for how the players discover the game, it also needs to be considered for updates
Think about how you convey changes to your audience. Release notes are a classic, but we should move forward and go further.
Consider how new systems affect the existing content and habitual play-style of the players. Reflect on how much changes will force players to forget and relearn, and how their value will be perceived.
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!
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
