The content of this website is licensed under a Creative Commons CC BY-NC-SA 4.0 Attribution–NonCommercial– ShareAlike 4.0 International License. You can freely use and share everything non-commercially and under the same license as long as you attribute it to and link to:
Why DriveThruRPG? It’s the largest download store for role-playing stuff in existence and you’ll probably end up buying much more than just your copy of Ludotronics. Which would benefit game designers everywhere!
Why not Amazon? For one, illustrated non-fiction isn’t well-suited for the Kindle format. Also, at a €14.99 price point, Amazon’s cut amounts to €9.75. Well, no.
Level One: Prototyping
Beat 3. Adjust
For the probability of any given event to occur, you can always substitute numbers for time. Suppose your game has a very rare imbalance that makes the red team invincible once every ten thousand years. With several hundred thousand active players, the red team will be invincible about once a week. Hence, in our definition, balancing is everything you carry out to lower the probability of undesired events in your game.
If this sound ominously abstract, it should! Let’s have a look at how a more tangible definition fares, and a very good one at that. For Morgan McGuire and Odest Chadwicke Jenkins in Creating Games, for example, the goal of balancing is to make a game fair, stable, and engaging—a succinct, comprehensive description that should universally apply. The two latter properties are largely uncontested, and they’re also covered by our more abstract definition (both an unstable game and a bored player qualify as undesired events, for sure). But there’s a surprisingly wide range of objections against the notion that a game needs to be “fair,” which McGuire and Jenkins define as “an equal chance of winning.” Certainly, most of these objections are based on interpretations of fairness. What, how, and when something could be called fair in a game, and on what level or meta-level, can be legitimately disputed. Quantities of unfairness that conform to the rules, it is argued, can make a game more tense and suspenseful, or more realistic, for example. Or even make it appear more fair! What’s more, cheating can be an intrinsic part of the game, as in the pen & paper role-playing game Paranoia, and might even willfully provide some agents or players with more opportunities to cheat than others.
To sum it up, a lot of definitional clarity needs to be achieved before fairness can be accepted as a universal balancing goal. Thus, notwithstanding the indisputable usefulness of McGuire and Jenkins’s balancing triad, we’ll stick to our more abstract definition introduced above. Also, this definition has the added advantage that there’s room for other types of undesired events that are not covered by stability or engagement.
For obvious reasons, this beat can’t tell you how to balance your prototype and later your game. Balancing depends on such a huge range of individual factors that any attempt at aggregating them would become encyclopedic. Instead, this beat will give you a basic overview with regard to what might need balancing in your game, structured into four neat categories:
These four categories are not carved in stone—you can make up your own categories any time. It’s just a map, again, and we shouldn’t confuse it with the territory. Your game might have particular balancing questions that resist being defined by any of these, or by one category alone. But these categories are a good place to start, and they cover a lot of ground. We will go through them one at a time, each with select examples.
Let’s start with a small, but fairly typical, selection of rule balancing cases. Certainly, your rule system shouldn’t create unintended advantages or disadvantages for any game world agent, including players, in any situation. The operative word is unintended—of course you can lavish advantages or disadvantages on your game world agents and players at will to make your game more enjoyable! Unintended advantages are another matter, and they’re often hard to detect. And when you detect them, they’re often hard to eradicate. A good example is the notorious “first move advantage” in turn-based games and particularly combinatorial games, i.e., turn-based games without randomness (no luck involved) and with perfect information (no hidden moves), as discussed in the Process phase in Level Two: Interactivity and elsewhere. It can take years to find out if the opening move confers an advantage, how strong that advantage is, in statistical terms, and how it can be balanced. In some cases, a handicap rule will solve the problem, or compensation points, like in the game of Go. In other cases, a rule that puts a clever constraint on the first move will do the trick. But every game needs its own solution.
Another typical problem source are rules in asymmetrical games like StarCraft or baseball, also discussed in the Process phase in Level Two: Interactivity. In any game, new strategies are being developed all the time. But in asymmetrical games, new strategies almost always cause problems. Here, new strategies cannot simply be mirrored by the other party or parties during a match. The new strategy soon becomes dominant, everybody uses it, and matches become predictable. For asymmetrical games, as long as that game has a substantial player base, the need for balancing never stops. No problem is predictable, every solution is unique.
A third classic in this category, equally touched upon in the Process phase in Level Two: Interactivity, is balancing luck and skill in a way that will make the game enjoyable for a wide range of players from your target audience. If a game is only about skill, beginners and casual players are rarely able to enjoy it. But the more luck is involved, the less enjoyable it becomes for advanced or more ambitious players. In a way, the luck component imposes an unwanted “handicap” on more advanced players, and a handicap problem cannot be solved with a handicap. Multiplayer arena shooters are a good example, and we discussed this in a different context before. The more precise the weapons are, the more skill they will require, and the game becomes less enjoyable for beginners or casual players. And vice versa. The less precise and more “spammy” the weapons are, the less incentive the game provides for more ambitious players to practice and become better players. One solution would be to introduce a new rule that only players of roughly equal ability are allowed to compete in any given match, and then introduce a matchmaking system to enforce this rule. Another option would be to tweak the values instead, with a well-balanced combination of precise and spammy weapons that enables weaker players to get lucky from time to time, but without taking away anyone’s incentive to learn and become more proficient. Solutions based on one or the other principle can also be applied in strategy games, racing games, and many other game types where skill and luck need to be balanced.
The biggest issue in this category is emergence. Emergence is both a boon and a curse. It makes a game more interesting, but also very difficult to control. As again discussed in Level Two: Interactivity, if you want to build a complex system of interacting subsystems with emergent properties you should always start from simple beginnings, add one subsystem at a time, and increase the degree to which these subsystems interact with one another very carefully. Should your game have emergent properties, you need a much higher number of test runs than you can achieve with playtesters alone; what you need are simulations, a topic we will discuss further below. Emergence, moreover, can itself create a particular variant of luck that we haven’t mentioned so far, which Cameron Browne calls a failure of “resilience” in his catalog of viability criteria in Evolutionary Game Design. A game with emergent properties that is not resilient, following Browne’s definition, has become so opaque that the probability of gaining an advantage or winning by random moves matches or exceeds the probability of gaining an advantage or winning by skilled play. So that’s another property that you might need to balance and test for, that your game is resilient to random play!
A final example that almost appears trivial in comparison is the matter of match length. But this problem isn’t trivial at all. Match length has to align with the target audience’s playing habits. A game that is enjoyable but drags on past concentration levels, or past bed time, isn’t well-balanced at all. What needs to be balanced here, first and foremost, is the game loop, another topic that we discussed in-depth in Level Two: Interactivity. Match lengths for multiplayer games can last, e.g., from around ten minutes in traditional arena shooters to about 30 to 45 minutes in MOBAs, or be as short as 30 seconds in casual free-to-play online games (whereby the latter often feature game loops with one shorter and one longer path, precisely balanced with the target audience’s playing environments). For single player PC or console games, it’s different. Here, the length of a level or the whole game is determined not by the game loop, but by completely different considerations. Basically, it’s how much you crammed into it along your three development arcs. But it’s a balance problem nevertheless. A level or a game that is too short or too long with respect to its target audience’s expectations isn’t well-balanced, after all.
These examples don’t cover all possible rule balancing problems, far from it. But they’re fairly typical. And common enough that, in all likelihood, you will encounter at least some of them.
Next, let’s have a look at value balancing situations. Mostly, this is about balancing values from and between interacting subsystems, like the health packs/ammunition example in our Shroom! shooter from Level Two: Interactivity, back in the Process phase, where interacting values from different subsystems enabled a lock-on-victory strategy. For example, it comprises balancing player character levels and equipment upgrades against the capabilities of game world agents. It comprises balancing non-transitive relationships between three or more competing game elements, based on the rock-paper-scissors mechanic. All in all, everything that has values needs to be balanced against everything else that has values. Damage values, health values, armor values, range values, unit capabilities, character classes, how fast anything can move, how high and how far anything can jump, and much, much more.
The more elements are involved, and the more values these elements are endowed with for competing advantages and disadvantages in different contexts, the more tricky and time-consuming it becomes to make them less vulnerable to exploits and dominant strategies. Some value balancing problems are more treacherous than others. Consider, for example, the frequent complaint that this or that value in a game (a weapon, a unit, a spell, an ability, and so on) is “overpowered.” Maybe that’s not the problem at all. Maybe that element merely looks overpowered because it’s too easy to learn or too easy to acquire, or something along these lines, in comparison to all the other elements.
Again, your particular game treatment will generate its own individual problems for which you will need to find your own individual solutions. But to set you up for value balancing success, the path to follow is Tynan Sylvester’s “key property” design approach from Designing Games.
According to this approach, every element should have a key property, and the value of that key property should be set as high as possible. If the key property of an element is speed or jump-height or protection or ground combat, this element then should be designed by default to move spectacularly fast, jump spectacularly high, be spectacularly impenetrable, or be unbeatable in infantry engagements, respectively. To begin with, every element will be distinctly valuable. Then, level designers can incorporate them with a clear purpose. Next, players can easily remember them and apply them in appropriate situations. Finally, and that’s our critical aspect for balancing, you relegate value balancing to each element’s ancillary advantages and disadvantages and leave their respective key values alone, which saves you time and headaches.
As a real-life example, let’s look at Unreal Tournament 2003/2004 and the sniper rifle, the eternal bone of contention in multiplayer arena shooters. There, the classic sniper rifle from the original Unreal Tournament game was turned into a “Lightning Gun” that signaled the shooter’s position visibly across the map. Later, the classic sniper rifle was reintroduced, but now it triggered conspicuous puffs of smoke with each shot. While neither solution was particularly satisfying, you can see the “key property” principle at work: the developers didn’t tweak long-range lethality, the rifle’s key property in an arena game. What they tried to tweak instead was its ancillary advantage of being hard to spot. (Trained and clever shooters are always hard to spot, but it’s amplified with distance.)
This approach has another benefit, as Sylvester points out. If all your value balancing attempts come to naught and the only option left is to lower the value of an element’s key property, then that’s an indicator, a warning sign even, that you should throw that element out. Besides being of questionable usefulness, elements that have their key properties nerfed are neither distinct nor interesting.
A real-life example for this, again from the transition of the original Unreal Tournament game to its successor games, is the notorious “ripper.” The ripper’s primary fire mode fills a room with razor-sharp discs that ricochet uncontrollably six times from walls and obstacles before disappearing, indiscriminately killing enemies, friends, and more often than not the shooter as well. It is perhaps the most spammy non-nuclear weapon ever devised in any game, and that is certainly its key property. Instead of nerfing its key property for later incarnations of the franchise, the developers took it out of the game altogether. (But it saw a comeback later in community contributions.)
If you follow this principle, you can create complex non-transitive sets of elements in your game without confusion or overlapping values. Still, details are important, and there will be no shortage of demanding value balancing tasks despite following the key property path. Many of these tasks, again, cannot be accomplished with playtesters alone, and we will come back to that.
There’s one more major value balancing area that needs your attention, and that’s terrain, or maps. Terrains must be designed in a way that all territories or positions have a balanced mix of advantages and disadvantages, so that no territory or position is more valuable than the others and vulnerable to being exploited for a dominant strategy. This applies to practically every multiplayer map in strategy games, 4X games, arena shooters, tactical shooters, MOBAs, and so on. It involves the clever distribution of resources and also the prevention of areas conducive to camping or spawnkills, where applicable. Depending on your game type, you might even be able to apply the key property rule for your terrain and map design!
Again, as a caveat, all this doesn’t cover every possible problem associated with value balancing. But again, they’re typical, they’re common, and you will most likely encounter some of them.
Then, the matter of resource balancing, which applies to the virtual economies of a huge range of game types from business, management, or life simulation games to shooters to racing games to role-playing games to strategy games to 4X games, and so on, and especially free-to-play games with in-app purchases. Virtual economies, moreover, often generate player-controlled real-world economies, or the game itself has a real-world economy attached to it that turns real-world currencies into in-game currencies. Resource balancing warrants its own book-length treatise, so we will keep it brief by providing a structural framework without pursuing the details. For the latter, good places to start are Christopher Wolf’s Case Histories and Analyses of Synthetic Economies or Vili Lehdonvirta and Edward Castronova’s Virtual Economies.
In Fundamentals of Game Design, Ernest Adams breaks virtual economies down into four principal drivers which he calls sources, drains, converters, and traders. This makes good sense, and we will adopt this principle with a slightly different nomenclature: source, sink, switch, and swap. These four drivers keep virtual economies running in the following ways:
Thus, resource balancing comprises two different tasks. Both are demanding. You have to balance the quantities and qualities of all the resources in your game with respect to their specific functions in the game world and for your game loop. Then, you also have to balance your economic system as a whole by balancing your source, sink, switch, and swap dynamics. Within these parameters, there are hosts of problems to solve and factors to balance, notably those related to player behavior in multiplayer games. The most damaging factors among them are overproduction; hoarding and other forms of manufactured scarcity; supply and demand manipulation; hyperinflation as has happened in Diablo 3; bugs and exploits like those that almost broke the economy of GTA V early on; or emerging black markets that almost invariably form around MMOs, from Ultima Online to Lineage or World of Warcraft and beyond. For a more in-depth introduction, Alexander Wolf’s already mentioned Case Histories and Analyses of Synthetic Economies is recommended reading. As a warning, everything comes down to math at the end of the day. And unless you hire an economist, this particular kind of math falls squarely into your responsibilities as a game designer! Later, in the development phase, and this is especially true if your game is an MMORPG or any persistent multiplayer game, you will need to create an integrated system that collects, prepares, and stores data points representative of what’s going on in your in-game economy on the one hand, and metrics and analytics to interpret these data points on the other, to counter detrimental developments and keep your game’s economy balanced in the long run.
Finally, agent balancing. As defined back in the Process phase, the term “agent” comprises simple processes, complex in-game AI, and players. Once more, let’s create a basic structure first.
Roughly, we can differentiate four typical areas for agent balancing: actions, challenges, rewards, and AI/NPCs.
Beginning with actions, agent balancing is about what players are allowed to do and when, so that they can enjoy playing without gaming the system, dominating other players, or dropping out of the flow channel as discussed in the Process phase in Level Two: Interactivity.
Next, challenges must be balanced toward your intended share of physical, cognitive, and empathic tasks, both for the game as a whole and as a balanced cocktail in any given dramatic unit larger than a beat. This has been discussed in the Process phase in Level Two: Interactivity and Level Five: Architectonics, respectively. Closely related, as a kind of subcategory, are challenges balanced for different player types. This can be Richard Bartle’s killer, achiever, socializer, explorer model or any other player type model, which we touched upon in the Process phase in Level Six: Integral Perspectives II. It should keep certain player types from dominating other player types, but you can also adopt it to make your game more attractive to a wider range of players.
The third area that needs your attention is rewards, a topic we also examined in the Process phase in Level Six: Integral Perspectives II. Like your challenges, your rewards need to be distributed in well-balanced proportions over the whole game and within every dramatic unit. But that’s not all! You must also see to it that extrinsic rewards don’t seep into the player or character development arc, as discussed, and that’s no small feat.
The fourth area is AI/NPCs. Your game agents should neither serve headshots from the far end of the map nor get stuck in every other doorway. They should neither take the action out of the player’s hands nor run helplessly into enemy fire. Balancing game AI is hard—it’s for a reason that escort missions are among the tasks players loath most. Balancing AI/NPCs also comprises balancing the “computer player” in games like Pong, chess programs, and similar.
In all four areas, unsurprisingly, specific demands that require specific solutions are attached to different player/agent configurations from single-player to coop, multiplayer, and MMO.
Certainly, many challenges in this agent balancing category can and must be solved by tweaking rules or values or economic conditions. Yet, it’s not a particular rule, value, or economic condition that’s causing you problems, but matters related to agent activities and behavior. Still, all four superordinate categories—rule balancing, value balancing, resource balancing, and agent balancing—are malleable enough and permeable enough that you can shift types, tasks, or areas between categories and accommodate the balancing demands of your game.
Luckily, the demands imposed on your proof of concept–prototype are far less severe than on your pre-production prototype later on, not to speak of your actual game. During development, you will also have a lot more tools at your disposal. For example, you might be able to balance your game through A/B testing with very small, very controlled changes that affect one particular aspect of your game. Or, on the contrary, you can make huge, sweeping changes and split-test both versions, which is fairly typical to mobile game development. And so on. But there’s something you can do to make all this much less forbidding: by co-designing testing and balancing mechanisms right from the start. In other words, for every function you implement during development, for every rule, for every feature, think about how you would later be able to test and tweak that particular item or event—and don’t forget to sketch your corresponding benchmarks. This might not sound like the most attractive and most desirable job for a game designer. But if you do that, you will be rewarded later by achieving much better quality with less time, effort, and torment.
As announced earlier, and to conclude this beat, let’s have a look at one of the most powerful balancing tools you can wield later during development. It substitutes numbers for time through automated simulations that run millions of players or matches or both. The most popular tool to run such simulations is the common spreadsheet.
In a nutshell, for any function you want to test, you determine the numerical values, probabilities, and dependencies of all elements involved; put these values and the formulas that connect these values into a spreadsheet; and define the number of iterations. When you’re done, fire it up and see what happens. How many resources of a certain type will players have accumulated after a certain time on average? Will some players have accumulated much more of that resource than other players? How will the game’s experience/leveling-up curve turn out for huge numbers of players over time? How many game world agents or players would have to repeat or avoid certain activities until the associated system breaks down? What’s the average lifetime of a resource or a game world agent under certain circumstances? Do the probabilities of your non-transitive relationships behave as expected? If two different units duke it out that are not part of the same non-transitive relationship, who wins more often in the long run? How are match lengths affected if you increase or decrease the spawning frequency for a certain resource? And so on.
For a more in-depth introduction, you might want to consult Jeremy Gibson Bond’s already mentioned Introduction to Game Design, Prototyping, and Development. It starts from easy beginnings like the probability distributions you’re already familiar with from the Process phase, especially Level Two: Interactivity, and proceeds from there to more challenging methods and all the wonderful things you can do with a spreadsheet.
For your proof of concept–prototype, again, that’s a bit early, but you should have made yourself familiar with this powerful balancing tool by the time your game treatment enters the development phase. Undesirable results in terms of clustering, run-away effects, curious convergence patterns, and many more, all these become visible, and you can try and correct them by either tweaking your values or your formulas, or by introducing new elements or removing others. In this one case, you are indeed a god, and your spreadsheet will become your own private universe to play with.
Now that you created a decent prototype for your proposition and did some preliminary testing and balancing, you have to make a momentous decision: to proceed with your project toward preparing, polishing, and presenting your pitch, or to abort. Did you, and did your playtesters, enjoy the prototype less than expected? Were there insurmountable balancing problems that gave you pause? Did all the elements that constitute your game fail to come together and form a coherent whole? Did it, despite all your efforts during the preceding phases, feel derivative instead of fresh and exciting? Should it be the case that you have to answer any of these questions or similar questions with “yes,” then you should abort. And be honest about it. Always remember Richard Feynman’s first principle, way back from the Preparation phase at the very beginning of our journey: that you must not fool yourself, and that you are the easiest person to fool.
To that effect, here’s a lesson for you from the field of writing, notably the screenwriting profession, that you should take to heart as a game designer. Don’t pitch a game treatment that isn’t good enough. It will tarnish your reputation. If you have to lose a pitch, lose that pitch in style with a crackerjack treatment. There are many reasons why treatments fail to win a pitch—too many similar games in the pipeline, incompatibility with recent brand decisions and the company’s future plans, market forces and developments you couldn’t possibly predict, financial or capacity constraints, and many more. All that shouldn’t bother you as long as you delivered a top-notch treatment. Because that will earn you reputation and future invites! In the long run, it’s not a game treatment that you pitch but your abilities as a game designer. In the long run, your game treatment is not the commodity. You are.
Thus, if there’s anything wrong with your game treatment that became visible during prototyping, testing, and balancing, go back to the Process phase, or the Procedure phase, or even back to the Preparation phase if need be. Or, if its flaws seem irredeemable, cut yourself loose from it and start from scratch. Create something new and exciting, building on everything you’ve learned.
However, if your proof of concept–prototype does knock your socks off, and if it knocks your friends’ and your playtesters’ socks off as well, then go ahead! Put on your boots and prepare for battle.