In the world of video game development, there are certain words that really should be four-letter words. Invoked on forums or uttered in whispered voices in the halls of game studios, these are the utterances that make the blood of designers and producers alike run cold with dread.
One of the most feared of these words?
- To arrange, adjust, or proportion the parts of symmetrically.
- To have an equality or equivalence in weight, parts, etc.; be in equilibrium
- The act of weighing factors, quantities, etc, against each other
- To assess or compare the relative weight, importance, etc, of
The first problem with balance is that perfect balance is, in a word, boring.
This was, in fact, probably the primary undoing of the 4th edition of the popular pen-and-paper game Dungeons & Dragons. The result of well-meaning design by a group of very sharp designers, this edition deviated sharply from the path of previous editions. Classes were placed in strict balance using common mechanics that resulted in the difference between a wizard’s spells and a rogue’s combat maneuvers being essentially aesthetic.
In an MMORPG such as Guild Wars or ARPGs like Diablo III or Marvel Heroes this presents a particular challenge to a designer: How do you architect character design that both presents interesting and differentiated tactical options that maintains a sense of equality between characters?
The second problem with game balance is that balance is ugly and messy precisely because by its nature it must incorporate a multi-dimensional matrix of playstyles, skill levels, and philosophical design preferences.
Because some players are expecting a game to reward character effectiveness based on progression time while other players are anticipating a game to reward character effectiveness based on player skill, for example, at aiming, or more esoterically, by dint of tactical decision-making, problems can readily arise in a game design.
If the design opts for consistency – for example, philosophically always focusing on player skill as the primary determinant – then there is a risk of significantly limiting the types and variety of game mechanics available for a designer to differentiate characters.
Even in the case of such a design decision the ground can quickly become muddied, however. Different skill mechanics will inevitably be picked up faster or slower by different players – what one player finds an intuitive, effective skill mechanic may seem hopelessly obtuse by another player.
True, some mechanics will tend to require a higher degree of learning time by most players, but this is far less true then is commonly presumed.
All of which is a long way of saying:
Players will generally assume balance is objective, when balance is in fact almost always subjective.
How, then, can a designer approach this with a minimum of collateral damage?
The first tool at a designer’s disposal is simply math.
While it is true that perfect balance has a dangerous tendency to be boring, the methodical use of standardly-applied formulas. The initial formula – whatever it is – is, however, ultimately less important than the twining of that formula directly into the damage, health, resistances, and other attributes for player’s characters and any enemies or allies they interact with.
For example, most of Cryptic Studios‘ games’ power systems are based on an especially elegant set of spreadsheets that link all of these attributes together in a network of explicitly defined relationships.
A designer can define, say, the number of basic hits a particular class of enemy should fall to, and this will automatically reverberate throughout the attributes of friends and foes alike. Health and damage are automatically shifted based on the defined relationships between these various factors.
While this is, to be sure, useful in the initial design, the real benefit of this approach is that it creates a long-term system that can be adjusted and modified based on feedback.
The second tool at a designer’s disposal is the creation of explicitly defined playstyle schemas.
While it is possible to haphazardly assign power and ability availability to characters, categorization of powers can make it much easier to identify significant imbalances.
For example, categorization could be explicitly defined by speed of effect (instant, damage/healing over time, instant plus over time, delayed). Categorization might also be defined by type of effect (damage, healing/recovery, crowd control, resistances/control breaks).
This all might seem obvious, but the reality is that whatever the initial implementation there is a real tendency in the furor of operating in a live development environment for this kind of explicit categorization to be forgotten.
(It should also be noted that I am not saying what types of categorization one should group together or even have – just that defining these explicitly, and establishing how and when these are used, can help with not only the players’ understanding of the way the rules in your game work, but in maintaining internal designer consistency.)
The third tool at a designer’s disposal is the iteration loop.
No matter how skilled a designer is, no matter how big your studio’s QA team is, no matter how many internal playtests your studio runs, the fact remains that the moment a game hits the battlefield – meaning a live environment – a design’s assumptions and expectations for normative behavior will be fractured.
Some elements will, to be sure, survive this process. Some will not. Predicting which is which is problematic, to put it very mildly. The solution is the iteration loop.
Iterating rapidly (and safely) requires, first, effective internal tools that have been proven to work with the game design that has actually been built. Far too often, the game one winds up building is not the game one originally expected to be built, and a common casualty of this is ill-fitted tools.
Internal testing, both by design teams themselves (a practice sometimes termed “eating your own dogfood”) and by QA teams can allow a team to reach a reasonable level of polish. Once that level of polish has been achieved, focus groups of white listed players and, eventually, beta tests on test servers can garner a great deal of subjective feedback.
Subjective feedback is, to be honest, a rat’s nest beset with several problems:
- Players, whether internal or external, are generally very good at defining what they don’t like, but notoriously uneven in their ability to accurately define why they don’t like something.
- Players without access to the internal workings of game mechanics can become subject to what I call “the Joseph Campbell effect”, where functionality that doesn’t in fact exist is assumed to exist despite claims to the contrary, creating a kind of mythos of the way the game works. Many claims of improper random number generation fall into this category. (This is one of the reasons I am a fervent advocate of transparency to players with game mechanics, as that reduces this particular issue).
- Most people have trouble separating their own aesthetic preferences from an objective analysis of the strengths and weaknesses of a system as it relates to accomplishing an identified design goal.
Metrics are the final tool at the disposal of a designer seeking game balance by means of iteration. Different studios have different standards and place different priorities on how important metrics will be.
My own experience is that while dedicating committed engineering and design resources to the gathering of game metrics is, yes, expensive, it pays for itself with a lot left over in the area of long-term community satisfaction and retention.