GDnD Wiki

GDnD Wiki

This site is for Ulster University students and staff. Enter the class access password to continue.

Game Balance

11 min read

Summary

Game balance is the process of adjusting the components of a game so that they produce the intended player experience — usually one that feels fair, challenging, and meaningful. Schell identifies twelve distinct types of balance, recognising that “balance” is not a single property but a family of related but different design problems.

This page now combines Schell’s broad balance lens, Adams’ difficulty model, Sellers’ systemic balancing methods, and Björk & Holopainen’s pattern language for the trade-off between accessibility and mastery. The twelve-types framework still needs fuller expansion from Schell’s original chapters.

(Schell, The Art of Game Design, see source-art-of-game-design)

Key ideas

Balance is not just fairness

The common intuition is that a “balanced” game is a “fair” game — no player has an unfair advantage. This is one type of balance, but not the only one. A game can be completely fair and still be badly balanced if it is too easy, too hard, produces dominant strategies, or fails to create meaningful choices.

Schell’s twelve types of balance

Schell groups balance questions into twelve categories. Abbreviated here; expand when source is re-read:

  1. Fairness — Is the game fair between competing players?
  2. Challenge vs. success — Is the difficulty well calibrated to the target player skill level?
  3. Meaningful choices — Do the player’s choices actually matter to outcomes?
  4. Skill vs. luck — Is the proportion of skill-to-luck appropriate for the target experience?
  5. Head vs. hands — Is the balance of thinking vs. physical execution appropriate?
  6. Competition vs. cooperation — If multiplayer, is the balance of competitive and cooperative elements right?
  7. Short vs. long — Is the session length right? Do short-term and long-term goals reinforce each other?
  8. Rewards — Are rewards proportional to effort? Are they timely?
  9. Punishment — Is punishment (failure, death) proportional and informative?
  10. Freedom vs. control — Is the player constrained enough to need skill, but free enough to express it?
  11. Simple vs. complex — Is the complexity of rules appropriate to the target experience?
  12. Detail vs. imagination — How much detail is provided vs. filled in by the player’s imagination?

Dominant strategies

A dominant strategy is one that is always better than all alternatives — a rational player will always choose it, making all other options irrelevant. Dominant strategies destroy meaningful choice, which destroys the game’s decision space.

Detecting dominant strategies: If players consistently make the same choices, that is evidence of a dominant strategy. Playtesting with expert players accelerates discovery.

Fixing dominant strategies: Either weaken the dominant option, strengthen alternatives, or add costs/risks that make the dominant option situationally sub-optimal.

Skill vs. luck

Games exist on a spectrum from pure skill (Chess) to pure luck (Snakes and Ladders). The appropriate mix depends on the intended audience and experience:

  • More luck → accessible, inclusive, comeback mechanics possible, outcome less predictable
  • More skill → mastery rewarded, dominant players win consistently, higher learning curve

Neither extreme is universally correct. Schell notes that even “pure skill” games often include hidden luck mechanisms to keep games interesting across sessions.

Björk’s balance-and-mastery trade-off loop

Björk & Holopainen add a very useful pattern view of balance. Instead of treating balance as one large tuning problem, they break it into interacting tensions:

This is one of the clearest ways to explain why balance arguments often become confused. Two designers can both care about “balance” while actually optimising for different things: one for keeping weaker players engaged, the other for making mastery visibly meaningful. See overview-bjork-patterns-balance-and-mastery. (Björk & Holopainen, Patterns in Game Design, see source-patterns-in-game-design)

Difficulty model (Adams)

Adams (Ch. 15) provides a precise model for managing perceived difficulty:

“perceived difficulty = absolute difficulty – (power provided + in-game experience)” — Adams, Ch. 15

TermDefinition
Absolute difficultyIntrinsic skill required + stress (time pressure). See challenge-types.
Power providedThe player’s avatar strength, equipment, army, etc. — under designer control
In-game experienceSkill the player accumulates playing this game
Perceived difficultyWhat the player actually feels; the design target

Implications:

  • If power provided grows at the same rate as absolute difficulty, perceived difficulty decreases (player experience grows too). Raise absolute difficulty faster than power to maintain challenge.
  • Each new level should start slightly easier than the previous level ended — producing a sawtooth difficulty progression.
  • Never jump difficulty sharply between levels; the player may have been away since completing the prior level.

Difficulty modes

Offering easy/normal/hard modes broadens market by accommodating different skill levels and previous experience. Adams’ rule: Easy mode must actually be easy — do not assume designer instincts about “easy” match novice player experience. Play-test with inexperienced players.

Dynamic Difficulty Adjustment (DDA)

DDA systems detect player performance and adjust challenge automatically. Implementations reviewed by Adams:

GameDDA approach
Max PayneInvisible adjustment of enemy strength and aim assistance
Half-Life 2Crate contents adjust based on avatar’s current health/ammo
Burnout 2Rubber-banding: AI adjusts speed to keep race close
God of WarOffers difficulty reduction after repeated deaths (player-visible)

Adams’ DDA guidelines: keep it subtle (Max Payne is the positive example; God of War’s obvious prompt is the negative one); never take away earned resources; make it optional; don’t substitute DDA for normal difficulty modes.

Positive feedback

Positive feedback occurs when achievement produces rewards convertible into power that makes further achievements easier. The cycle: achievement → reward → power → easier achievement.

“In Monopoly, when a player achieves a monopoly, the player may charge higher rents — the owner’s reward for the achievement. The player may then use the money to purchase more property.” — Adams, Ch. 15

Benefits:

  • Prevents stalemate (a game that never ends)
  • Rewards success with meaningful (not cosmetic) power growth

Controlling positive feedback — seven methods:

  1. Don’t provide excessive power as a reward (shogi limits captured pieces)
  2. Artificially cap the player’s power (salary cap in NFL)
  3. Associate costs with achievements (territory = defensive perimeter in war games)
  4. Allow collusion against the leader (Diplomacy)
  5. Raise absolute difficulty to match growing player power (RPG level scaling)
  6. Define victory conditions independent of the feedback cycle (chess: checkmate, not piece count)
  7. Use chance to vary reward size (random loot amounts in RPGs)

Ideal game progression (Graph 6 in Adams): lead changes hands; both players have a chance; but eventually the better player’s lead becomes insurmountable through positive feedback.

In practice

Balance is discovered primarily through playtesting, not through mathematical analysis alone. Mathematical analysis identifies candidate problems; playtesting confirms whether they manifest in actual play and whether they feel like problems to players.

Common balancing process:

  1. Define the intended experience (target aesthetics — see mda-framework)
  2. Identify elements most likely to undermine that experience (fairness issues, dominant strategies)
  3. Adjust values iteratively; playtest after each significant change
  4. Modify only one parameter at a time and make large adjustments (halve/double values), then converge
  5. Keep records of all changes

Avoiding stagnation: Never leave the player not knowing what to do next. If a player must hunt randomly for the exit switch, that is a design flaw. Plant clues; if the game detects aimless wandering, provide gentle nudges.

Avoiding trivialities: Decisions with no real effect on the game — or where only one option is reasonable — should be automated or eliminated. Let the computer handle minutiae; keep the player focused on meaningful choices.

Sellers’ framework: four balancing methods (Ch. 9)

Sellers (Advanced Game Design, 2018) adds a systematic taxonomy of how balance is approached in practice. Four methods exist, all complementary:

MethodDescriptionPitfall
Designer intuitionHeuristic feel for what works; the oldest methodPersonal bias, team arguments, slow to resolve — replace intuition disputes with fast prototypes
Player-based (playtesting)Players interact with the game; designer observes and adjustsPlayers report what feels wrong but usually cannot prescribe fixes; feedback ≠ solutions
AnalyticalData from player behaviour: which paths are taken, win rates, level completion, drop-off pointsRequires sufficient player volume; can create the illusion that enough data removes creative risk
Mathematical modellingSpreadsheet-level attribute analysis, probability calculations, progression curve modellingMisses emergent and perceptual effects; must be validated by play

Sellers’ key point: “You cannot let the data (or the playtesters or your own feelings) overrule everything else.” All four methods are checks on each other. No single method is sufficient.

The Tumbleseed case study (Sellers, Ch. 9): Tumbleseed shipped with steep difficulty ramping. Analytics showed 59% of players never reached the first checkpoint; 99.8% never completed the game. The game required players to simultaneously master a new control scheme, new rules, new terrain, new enemies, and new powers from the start — overloading interactivity at every timescale simultaneously. This was a balance failure detectable by analytics but preventable by earlier playtesting.

Sellers’ framework: transitive and intransitive balance (Ch. 9)

Sellers (following Schreiber 2010) provides a structural distinction between the two main types of systemic balance:

Transitive balance

In a transitive system, parts beat each other in a cycle — no part dominates all others.

The canonical example is Rock-Paper-Scissors:

  • Rock beats scissors; scissors beats paper; paper beats rock
  • No one choice is dominant across all matchups
  • The system has a dynamic equilibrium: if any one choice becomes overwhelmingly common, the counter to it becomes advantageous

Requirements for transitive balance:

  • An odd number of interacting part types (each must beat exactly half and lose to exactly half)
  • Clear dominance relationships (probabilistic dominance is acceptable, but must be consistent)

Example from wargames (Sellers, Ch. 9): Infantry–Cavalry–Archers form a transitively balanced combat ecology. Infantry beat Cavalry (higher attack closes before cavalry can escape); Cavalry beat Archers (speed closes before archers can kite); Archers beat Infantry (range keeps archers safe from infantry’s high attack). Each unit type is built from the same total number of attribute points, distributed differently across Attack, Defence, Range, and Speed.

Why transitive systems avoid dominant strategies: A well-constructed transitive system tends toward dynamic balance — if one faction or unit type becomes overrepresented, the factions that counter it gain advantage, pulling the system back toward equilibrium. This is the same principle that governs evolutionary ecology (see the real-world side-blotched lizard example in Sellers).

Pitfall: If external factors (terrain, a specific strategy) make one type of the triad invincible in practice, the transitive balance collapses to a single dominant strategy. Playtesting must verify that transitive balance is robust under realistic play conditions.

Intransitive balance

In an intransitive system, some parts are simply better than others — but they cost proportionately more.

This is the structure of progression systems: a rusty dagger costs little and is weak; an enchanted greatsword costs much and is powerful. Neither is “wrong” — their costs and benefits are proportional. The balance question is whether the proportionality holds across the full range of the progression curve.

Intransitive balance requires defining a progression curve (also called a power curve): the mathematical relationship between cost and benefit as parts increase in power. See Sellers, Ch. 10 for the practice of creating and maintaining progression curves.

Why most games combine both: Most games with meaningful content have intransitive progression (things get more powerful over time) nested within a transitively balanced ecology (no one build or strategy dominates at any power level). A fighting game where a low-tier character can never defeat a high-tier character at equal skill is intransitively unbalanced. A fighting game where every character is identical is transitively unbalanced.

Open questions

  • Mathematical balance (equivalent expected values) and perceptual balance (feeling fair) often diverge. Which matters more?
  • Live games (service games, MMOs) face ongoing balance challenges because the player population improves in skill over time, making original balance obsolete. How do designers manage this?
  • DDA systems remain contested. Some designers argue no automated system can accurately predict desired difficulty. Is there a principled way to evaluate when DDA is worth the cost?
  • Transitive balance requires an odd number of part types. In practice, most strategy games have many more than three factions or unit types. How do designers maintain transitive-like balance at scale?

Graph View

Backlinks