Techniques for Achieving Play Balance
by Tom Cadwell

Abstract: There is not a large amount of information on play balance technique widely available. This article is intended to help fill this information vacuum by describing both the nature of play balance and imbalances, as well as a process by which play balance can be achieved. This process relies heavily upon existing systems engineering techniques, as well as accepted game design theory. Liberal amounts of case studies and anecdotes are used to help ground the process in real-world situations.

A lack of play balance often stands in between a great design and a great game. Most designers learn the fundamentals of play balance through trial and error. If they are fortunate enough, they might pick up a tidbit or two passed on by their co-workers. Those that do have expertise in game balance often guard their secrets jealously, or are in job situations where they have little incentive to share the details with others. As a result, while information on play balance does exist, there isn't a terribly large volume of good information available. This article attempts to convey a process with which play balance can be attained.

What is Play Balance?

Sid Meier once said, "A game is a collection of interesting choices". It follows that game elements being out of balance and thereby eliminating choices detracts from the gameplay. Ideally, a game should be a series of choices, ending with victory of defeat or some other end condition. Sometimes, some choices will become unquestionably the only choice, or definitely not a valid choice. If there is only one valid choice at some point, but the game hasn't ended, there is a play balance problem.

Nearly all situations commonly referred to as imbalances can be boiled down to a choice reduction. For instance, in a strategy game, if a particular unit is sufficiently over-effective for its cost, it could make another unit completely useless in most or all circumstances. Not only does this situation leave a player with one real choice (where's the choosing?), but it also leaves the player with numerous irrelevant distractions. These distractions actually detract from the gameplay further by obfuscating it and adding player frustration to the mix.

A good example of an imbalance is present in Monopoly. Late in the game, it is ALWAYS in the players' best interest to sit in jail as long as possible. The dominant late game strategy for players is to get into jail, then not pay their way out, in hopes that others will land on their properties and go bankrupt. Towards the endgame of Monopoly, there really aren't any choices being made - the game is just concluding. No one is choosing whether to buy property or not, seldom is anyone given the opportunity to build new property using tournament rules (because houses are all used up), and trades simply don't happen because property is lumped into monopolies across the board. Once this situation occurs, the game is basically some probability of each player winning that plays out to conclusion. Very little can be done by players (besides luck of dice) to win. This is a sharp contrast with the mid-game and early game of Monopoly, in which fierce politics go on, players attempt to realize strategic trades that subtly benefit themselves and backstab their opponents, and players must carefully decide whether or not to buy the "heavy" yellow/green/dark blue properties.

This illustrates just one type of imbalance. There are many types of imbalances that can exist in games. All imbalances involve choice elimination or a lack of choices in some form.

• Too Expensive/Weak vs Too Cheap/Powerful: Game choices usually have a game-cost associated with them, be it the loss of other choices, game money, or some other commodity. When one choice is either too expensive to be useful, or too cheap to not be the obvious choice, there is a clear imbalance, because one or more choices has been unintentionally nullified. Though his type of imbalance is by far the most common, it can usually be rectified by simple changes in either cost or basic effectiveness of the choice in question.
• Player-Time Imbalances: Most play balance comparisons are based on the cost of various choices in terms of what the player must give up to choose a particular path. It is very easy to overlook the fact that a player must spend time executing the choice. In a real-time game, the player doesn't have infinite time in the game, so not only is time a resource, but it is a limited resource. In a non-real-time game, time isn't limited, but the player's time is! This imbalances is essentially another version of the too expensive/too cheap imbalance, except the cost associated with the choice is less tangible. A good example of this imbalance is present in Starcraft with the Zerg race. Although the Zerg race units are more or less balanced by cost compared to other races, they are much easier to produce and use in terms of player time. In large part due to this characteristic, the Zerg race was the dominant race in tournaments and competitions for roughly 6 months following Starcraft's release.
• Imbalances Across Skill Levels: As players improve in skill, the relative effectiveness of game choices may change. If one choice is easy to use well, and another is extremely difficult to use well, then it follows that to an expert player, the relative effectiveness of the two options is very different than the same to a new player. This is a common trap for game developers, since most are closer to the "Expert" side of things, and as a result often lose sight of the new player. On the other end of this equation, is the fact that "evolving" gameplay with regards to skill is generally considered a good thing. It is important to be aware of this balance, and be aware of this phenomena in general.
• Forced Disadvantage/Advantage: In a player vs player game, some sequences of actions or choices can result in one player being guaranteed an advantage over the other. In addition to satisfying the traditional definition of imbalance (one choice is clearly best), this situation also isn't fair. In a multiplayer game, unfair situations are best avoided, and are a crucial piece of the play balance puzzle. All imbalances come back to the original essence of imbalance: choice elimination. When this is kept in mind, it becomes much easier to distinguish between situations that just need to be tweaked into balance, and situations that are fundamentally imbalanced.

Achieving Balanceability

Play balance is often considered an "alpha or beta thing", but the truth is that like any engineering task, good preparation is key to success in implementing good play balance. A good game design has strong balanceability, which can be defined as the relative ease with which a game system can be brought to a state of balance. If the system has no balanceability, all the tweaks in the world will not bring it to a state of balance.

A game is a system, and good systems engineering practices, when applied in the early design phase, lead to strong balanceability. The three core ideas that translate well from systems engineering to game balance are: game element modularity, consistency of design motivation and complexity control. When used in combination early on, they can save designers enormous amounts of time in the alpha and beta testing stages.

Game Element Modularity

Game element modularity boils down to an idea that each game mechanic should exist for a specific purpose, and if possible, a singular purpose. When this principle is adhered to, tweaking a mechanic only changes one aspect of the gameplay, rather than several aspects.

A good example of where this caused a developer unnecessary pain was during the beta testing of Starcraft. Blizzard (the developer of Starcraft) had a fairly straightforward damage system in which each unit did one of three types of damage, explosive, normal or concussive. Each of these damage types had a different damage multiplier against various unit sizes --explosive was good against large targets, concussive was good against small targets, and normal was good against everything. One unit, the Mutalisk, ended up being a constant hassle to balance in part because there were a lot more than three different types of units (i.e. large/med/small didn't really cut it) in terms of desired functionality. Setting the Mutalisk to the "medium" unit type classification made it far too resistant to explosive weapon-type units, while making it large made it too vulnerable to the same units (which were sometimes, but not always, its theoretical counters). Blizzard couldn't just change the coefficients of explosive vs. large or explosive vs. medium though, because that could've upset a bunch of other unit matchups that were not comparable to the Mutalisk vs. explosive damage-type unit matchup. They couldn't really change the attack values of the units using explosive weapons either, since that threw off other things as well!

This was further confounded by the fact that the Mutalisk had two strong roles - anti-air and anti-infantry (ground units without air attack), all with the same base damage, while other units similar to it (scout, wraith) had separate weapon systems, which could be balanced for their specific roles.

Due to this a lack of modularity in the damage system and the Mutalisk, Blizzard didn't manage to balance the Mutalisk until five months after the commercial release of the game. It wasn't that a fix was impossible, but rather that the fix was difficult to ascertain because of a lack of system modularity. The Mutalisk had a somewhat unique purpose in Starcraft, and if Blizzard had isolated its balance parameters from other unrelated units, they would've had a much easier time balancing it. The easiest solution would've been to simply add a unit type to hold the Mutalisk (Along with any similar units) with its own resistance to various types of damage. Had the designers made the Mutalisks air and ground attacks different, they would've also had an easier time.

Of course, for the most part, Starcraft did have a reasonable amount of modularity. One example of this, is the Spellcaster units, which tended to have a crisp definition of purpose, and relatively specialized roles. The fact that many spells, including Broodling and EMP Blast, had super-specialized roles, made balance much easier to achieve with these units.

Good system modularity isn't just preventative medicine for play balance, its actually a proactive step towards a solution. A system with strong modularity will have all the knobs and levers necessary to tweak very specific problems with exactly what is needed without side effects.

Consistency of Design Motivation

Consistency of design motivation is perhaps the most important principle to adhere to during the initial design phase, but it is easily ignored either for political reasons, carelessness, or a lack of good communication. The assumption behind consistency of design motivation is that if a game mechanic wasn't designed in sync with the greater whole of the game, the best case is that it will merely distract users from the "core gameplay" and the worst case is that it will actually damage the core gameplay in some manner. The best examples of this situation exist in games that either have no centralized control, or which have been developed over a very long period of time.

The somewhat known MUD Duris: Land of Bloodlust (which is the sister MUD to Sojourn, which Everquest was based off of) suffered from this several times. In one case, a programmer took it upon himself to implement a new character class that he wanted to play. Although the character class was fun in and of itself, it made several other classes far less useful, and was greatly overpowered. By merely existing with the ability set it had, this character class essentially broke a monopoly that several other classes possessed, and which in turn had made them useful and fun to play. This was of course, in addition to the more "mundane" play balancing problems that he introduced. His objective was at its core, to make a class he wanted to play. This conflicted with the greater MUD developer desire to create interesting, original classes that meshed well with the MUD as a whole. His class was neither unique (it had a little of this and a little of that from other classes), nor coherent with the rest of the MUD.

Complexity Control

Complexity control can best be summarized as "keep it simple, stupid". Excessively complex game systems are harder to understand, and thus, harder to balance. An overcomplicated system usually is developed either because an initial design that was poor was endlessly "patched" with design fixes (leaving an incoherent mess that in theory works) or because of the all-too-ancient "too many cooks in the kitchen" phenomena, which often also corresponds to a lack of consistent design motivation. An added advantage to complexity control is that it avoids a number of potential gameplay issues. In particular, just as complex game systems are hard to understand and in turn to balance, they are also harder for players to understand, and after a certain point, to enjoy. An all too common design mistake is to favor complexity over depth, which leads to extreme play balance difficulties, and confusing and difficult to understand gameplay.

The Basic Play Balance Process

With ground rules, and basic techniques aside, process is important. There are several steps in the play balance process, each of which have assorted techniques which can be used to enhance the balance of the game.

The first priority is always to get the game in a fun and playable state, and this requires macrocalibration, or getting the game in a state where most elements are at least vaguely balanced, and no element is egregiously imbalanced. Once this state is reached, it is possible to continue to hone the balance between specific instances of game elements, such as races or sides in an RTS.

Of course, since games are often macrocalibrated well before they reach alpha stage, it is possible that they may have to be recalibrated as new lumps of functionality are added to the game. Erin Daly, lead designer of Homeworld, suggests that adding groups of related functionality at the same time, and doing a macrocalibration when they are added, is generally the most effective way to keep the game playable throughout development.

Once the final macrocalibration has been achieved, hopefully in late alpha, the game can be microcalibrated, or "tweaked", to a perfectly balanced state.

Macrocalibration

Allowing for a balanceable game system is obviously only the first step towards a balanced game. Even the most immaculate design must be implemented, and just as error can seep into implementations, slight errors are often made in the initial design. In addition, many game values really can't even be effectively guessed until the game is implemented. In these situations, which generally occur during the pre-alpha and alpha stages, designers must use macrocalibration techniques or "get the balance values in the right ballpark".

Macrocalibration should always be completed before microcalibration is begun; small balance changes will be washed away and made into useless work if the foundation that the game rests on is still in transition. While macrocalibrating, the goal is to "find" the target gameplay that is described in the design document. Obviously, you can't polish the gameplay with small tweaks when you aren't even sure you've gotten the core gameplay to manifest!

In order to zero in on the core gameplay desired, it is important to explicitly define what the core gameplay is like and how it will manifest. Once this is done, it is possible to establish some sort of baseline, or "anchor" as Ensemble Studios calls it. For instance, for game pacing you might set a baseline of "roughtly ten minute-long games" or for the player character's toughness you might set a baseline of "three attacks from a dangerous monster should be deadly". Once you get an incarnation of each game element (ONE map, ONE character class, ONE dialogue, etc) that works satisfactorily well, it is easy to expand upon the game, using the baseline game element as a ballpark figure to start from.

Balance Math

Once you have a particular element macrocalibrated, balance math may be useful in some cases to "clone" the result to similar elements. Although balance math is of dubious usefulness in perfecting the balance of a system because it is hard for it to correctly take into account more subtle issues, it is still useful for applying a baseline to various game elements. One formula that is universally useful to almost every game is the cost effectiveness equation.

The cost effectiveness formula states that for a component, its:

Game Impact * Durability = Effectiveness

And it follows that:

Square root (Game Impact * Durability/Cost^2) = cost effectiveness

Game impact might be firepower (damage * Rate of Fire), or points. Durability might be number of uses, or hitpoints. Cost represents game resources, which are often gold, money or turns (e.g. the "actual" cost of a move in chess is a turn).

Another useful equation that is primarily suited towards strategy games and other "combat" situations is the fragmenation formula. Fragmentation simulates the fact that in a combat situation, swarms of small units with a sum effectiveness equal to a few larger units are not actually the same in effectiveness. The swarm of small units is always lower in effectiveness, assuming no other subtle factors (such as "overkill" when damage is lost to no useful means). This is because a swarm gradually loses power over time as individual units die, while a large unit or element lasts much longer, and hence, doesn't suffer from incremental loss of effectiveness. The formula for relative effectiveness due to this effect is:

Reduction in Effectiveness (to smaller units) = .5 + .5(Number of Large / Number of Small for the same cost)

The inverse of the resulting number is the effectiveness increase to the larger units.

These formulas and other "balance math" are typically best for ballpark balance. Attempts to reach perfect balance mathematically are best avoided, except with fairly simple game systems. For instance, balancing Risk isn't terribly difficult because the game rules are fairly simple, and player choices can be quantified very effectively. Balancing monopoly is doable, but trickier than risk, because the random element (dice rolling) can produce much more widespread effects than it does in risk, and also because monopoly has a much larger number of distinct game elements (chance cards, mortgage rules, jail, etc). More complexity, such as that in a modern RTS, creates a situation where a complete mathematical play balance solution is worth of a doctoral thesis.

Balance math is particularly potent when used in symmetrical games, such as games like Warcraft 2 or Homeworld, in which the opposing sides are more or less the same when it comes to game functionality. The more similarities two elements or groups of elements possess, the fewer hard-to-model variables exist to throw off balance math.

Microcalibration

Once a game is macrocalibrated, game balance must be fine-tuned. If the game is at least somewhat fun, without any huge glaring problems, then it's probably macrocalibrated and ready for the small details. Microcalibration is the process by which the game designer applies small tweaks in order to perfect the state of balance of the game. A tweak can be defined as the set of changes such that the change in value is less than 10% for a "global" value (something that effects many game elements) and less than 30-40% for a "local" value (a particular game element).

The biggest challenge in microcalibrating is simply identifying problems. Once a problem is identified, it is just a question of tweaking values slightly, and in such a way that one is not creating new problems. Good element modularity and pre-planning will really be a life-saver at this stage - without them, it may not be possible to balance the game in a reasonable time frame.

Identifying Minor Imbalances

There are several techniques with which a designer can identify minor imbalances. The most obvious of these is to simply test the game heavily, and watch for approaches that seem consistently favored or dominant, and to watch for approaches that are never used. Another common method is to simply argue hypothetical situations and counters with a tester or another designer, reach an agreement as to what is supposed to happen, and then test it to see if that is how things work out in the game.

If a designer is using the first method, of simply looking for dominant (or never used) strategies, it is important to determine exactly why the strategy is either dominant or never used, and furthermore, whether or not it is supposed to be that way. Additionally, classifying the imbalance as one or several of the typical types of imbalances is helpful as well in understanding the problem. Ultimately, the more certain one is of the imbalance and its characteristics, the more able one is to fix it.

In recent years, it has become increasingly popular to record game outcomes and statistics secretly without player knowledge. Age Of Empires, several games published by Sierra, and Strifeshadow have benefited from this technique. Sometimes such statistics can be enlightening, and sometimes they can be highly misleading.

All data must be taken with a grain of salt. In some cases, an immature testing population can give you very skewed results, simply because they aren't familiar with the game and haven't gotten around to trying things (or just rush to the easiest things to use). Similarly, an overly mature testing population can either be so set in their ways as to ignore the potential of other strategies, or get caught on a very advanced, obscure point that is indeed imbalanced, but perhaps less pressing than other, more obvious imbalances. One highly effective technique that Ethermoon Entertainment used with Strifeshadow was to overstate play balance changes in beta patches, so as to encourage players to actually try new strategies, as opposed to continue to "write off" changes.

The second method of spotting imbalances, which sometimes is referred to as "hunting for imbalances" is when a hypothetical situation is formulated, and the various possible responses and their outcomes are agreed upon. For instance, it might be agreed that a tank rush should beat a light vehicle rush, but with light losses, and at the same time lose badly to the anti-tank infantry counter. If in the actual game, the tank rush completely massacred a light vehicle rush, and broke even against anti-tank infantry, there would be a perceived imbalance of tanks being too strong. Hunting imbalances is very important, and if done rigorously, can easily spot 75%+ of minor balance problems. Just because a designer expects something to work a particular way, doesn't mean it necessarily does in the game - especially when a very small difference in a local balance value separates balance from imbalance in a competitive multiplayer game!

One thing to keep in mind whenever hunting imbalances is that game elements that come into play early in the game is always much more balance sensitive than late game elements, simply because an imbalance early game element will affect everything after it, while a late game element has much less of a timeframe in which to cause trouble. Just as one needs to macrocalibrate a game before one can do useful microcalibration, one needs to balance early game elements before late ones.

Fixing Minor Imbalances

Once an imbalance is identified and demonstrated, fixing it is a pretty simple thing... assuming the game is designed to be easily tweaked! A very balanceable game has the property that the designer can specifically attack an imbalance, without collaterally affecting other game elements.

The most important thing to keep in mind when tweaking is to keep it at a tweak level (think small), especially when an upgrade is involved. A game element that is too strong can easily make many other game elements useless, while a game element that is too weak is just ignored and impacts little.

It is also important to implement tweaks that do not cascade onto other values. For instance, consider a spell in a role-playing game called "fireball", which is a subset of fire spells. If fireball is proving too powerful, the options a designer has range from downgrading the potency of fire magic in general, to downgrading fireball in some manner. Clearly, you want to choose the localized solution, downgrading fireball, before tweaking fire magic in general. This is a highly simplified case, but in many situations there will be a certain level of interdependence between game elements. Carefully consider what impacts a change will have, and try to use the one that specifically attacks the problem without affecting other game elements.

Finally, avoid "Over-solving" imbalances. "Over-solving" an imbalance is when a designer applies multiple different types of tweaks at once to fix one particular problem. Over-solving makes it very difficult to determine the effects of the changes simply because you are using multiple independent variables to affect one dependant variable. Over-solving is also a recipe for trouble in terms of accidentally affecting other game elements.

Wrapping it up

When developing a game, it is easy to occasionally lose sight of the end-objectives when confronted with an enormous onslaught of details. Remaining true to the desired gameplay of the project, and to play balance theory in general at all times is quite trying, but ultimately necessary to ensure both high quality play balance and a beta period of appropriate duration. With multiplayer games becoming more and more popular every passing day, it is becoming increasing necessary for play balance to be as good as it can be. Too many promising multiplayer games have already been compromised by lackluster play balance.

About the Author

Tom Cadwell is the Lead Designer at Ethermoon Entertainment. Titles he has worked on include Strifeshadow, a multiplayer RTS (http://www.ethermoon.com), Dark Reign 2 and several web games and MUDs. Tom welcomes questions and comments regarding this article, and can be contacted at tcadwell@alum.mit.edu.

Credits and Thanks

Thanks to Erin Daly and his associates at Relic Entertainment for providing feedback on this article. Thanks also to Dave Custer, my college technical writing professor, and the members of my writing workshop.