I’ve been spending all my free time lately working on my GDC talk. So, if you’re at the conference, come see me play career roulette on Friday afternoon. And if you aren’t in SF this week, I should resume posting when I get back with lots of new material from the talk.
Running is risky. Your center of mass is so far in front of your feet that you are constantly falling forward, catching yourself with each stride. You appear to be in control and stable, but in reality you are always one misstep away from catastrophic failure. (Thoughts like this are why game designers are rarely world-class sprinters.)
During development, a game can appear to be balanced, but is actually just being carried along by momentum; the instability is masked by constant change. Releasing the game at this point is like tying a runner’s shoelaces together.
When the designers cede control to the community, they quickly find the truly balanced state. Unfortunately this often results in a degenerate or random experience where entire gameplay modes are untouched, fundamental mechanics no longer have an impact, and usually the game becomes too simplified to remain interesting. Even worse, developers are often forced to incorporate the broken mechanic into a sequel or risk alienating their fan community.
How does this happen? Often it is a result of a flaw in the development process.
Early in development, when the game is being prototyped, it seems inefficient to rigorously encode the game mechanics. It is easier to just ask playtesters to refrain from using certain tactics, ignore logical loopholes, and pretend the game works in a different way than it actually does. After all, the playtesters are usually on the development team, and the prototype changes faster than the code can be updated.
The problem comes when these conventions become so firmly established that the designers start making assumptions about what the community will do based on those (false) expectations. When the game is released, the community does not respect conventions, they will exploit any tactic or loophole the game allows, ultimately breaking the balance.
Isolated Game Systems
A common production tool is to organize features into prioritized lists, with the understanding that everything below a certain line has a chance of being cut. This encourages designers to create isolated game mechanics, parallel systems that do not interact with one another, so that the inevitable cuts have less impact on the surviving mechanics. These layers are frequently worked on by different designers with different goals and ideas about what the game should be.
This leads to the situation where game systems are individually balanced, but in differing, or even conflicting ways. The progression mechanics that keeps player invested in the community might break the competitive multiplayer game. Or large sections of an environment may go unused because of the way the mission objectives are placed. Usually, the most poorly balanced aspects of the game drag down the other systems, leveling any interesting nuance they might have had.
Ignoring the Skill Zenith
Designers are rarely as good at the games they develop as the people that play them. (They tend to spend more time building them than mastering them.) It is often their ability to sympathize with the “average” player that makes them good at their jobs. Unfortunately, this means that they have a blind spot and cannot always predict how the game will be played at the very highest level of skill.
Nothing wrecks game balance as fast as a community that is more skillful than the developers anticipated. Actions that were meant to be impossible or happen only through luck become fundamental to the game. The community is split between those that can execute the “impossible” tactic and those that cannot, and are no longer competitive.
No game ships with flawless balance, but by avoiding these pitfalls your game community may last long enough for you to tweak it.