game-balance

name

game-balance

description

Numeric balance across objects with stats: cost curves, transitive versus intransitive systems, payoff matrices, dominant strategy detection, power creep, and buff-before-nerf remediation. Use when pricing items, weapons, units or upgrades, designing counter relationships, or when playtesters say 'X is overpowered', 'Y is useless', 'one build always wins', or 'I never use Z'. Also when adding content to a shipped system and checking for power creep. This covers tuning numbers inside a system that exists; for designing a resource economy from scratch use economy-design, and where accumulation IS the game use incremental-design.

Game Balance

Purpose: Systematic tools for tuning numeric systems — items, economies, combat, progression — so that player choices remain meaningful and no single strategy dominates.

Sources: Cost curves and the transitive/intransitive split follow Ian Schreiber's Game Balance Concepts (2010 course) and Schreiber & Romero, Game Balance (CRC Press, 2021). "A negative benefit is a cost — keep all numbers positive and add" is a Magic: The Gathering design convention (Richard Garfield / Mark Rosewater). Dominant-strategy remediation and the buff-before-nerf preference follow David Sirlin's writing on competitive balance.

---

Core Tool: The Cost Curve

The cost curve is the fundamental balance instrument. Every game object in a transitive system should sit on a consistent curve of cost vs. total value.

Construction Steps

1. List every object in the system (weapons, units, items, spells)
2. Choose a baseline — the simplest, cheapest object
3. Identify all attributes that contribute to value (damage, speed, range, utility, special effects)
4. Assign relative weights to each attribute (this is the art — requires playtesting)
5. Calculate total value for each object: total_value = sum(attribute * weight)
6. Plot cost vs. total_value on a scatter chart
7. Fit a curve — linear, polynomial, or exponential depending on the system
8. Identify outliers — objects above the curve are overtuned; below are undertuned

Key Principles

• A negative benefit is a cost. Keep all numbers positive and add. Don't subtract. Easier math, same result.
• Intentional outliers create interesting choices. A cheap item that's situationally excellent is a feature, not a bug — but document it.
• The curve shape matters. Linear curves feel predictable. Exponential curves make high-end items feel dramatic but risk making low-end irrelevant.

Template: Balance Spreadsheet

| Object  | Cost | Attr_A | Attr_B | Attr_C | Weighted_Value | Delta |
|---------|------|--------|--------|--------|----------------|-------|
| Dagger  | 10   | 5      | 8      | 0      | 13.0 (baseline)| 0     |
| Sword   | 25   | 12     | 5      | 2      | 26.5           | +1.5  |
| Axe     | 30   | 18     | 3      | 1      | 28.0           | -2.0  |
| Staff   | 20   | 3      | 4      | 15     | 31.0           | +11.0 |

• Delta = difference from expected value at that cost point on the fitted curve
• Large positive delta = overtuned (too much value for cost)
• Large negative delta = undertuned (not enough value for cost)
• Flag any delta > 15% of expected value for review

---

Transitive vs. Intransitive Systems

Most games combine both. Know which you're building.

Transitive (Power Hierarchy)

Objects are strictly ordered by power, balanced by cost.

• A $500 sword is better than a $100 sword — that's intentional
• Balance question: "Is the power increase proportional to the cost increase?"
• Tool: Cost Curve (above)
• Risk: If cost is easy to acquire, the hierarchy collapses and only the top item matters

Intransitive (Counter Relationships)

No single option is best — effectiveness depends on what the opponent chooses.

• Rock-Paper-Scissors is the canonical example
• Balance question: "Is every option in a cycle? Does anything dominate?"
• Tool: Payoff Matrix (below)
• Risk: If one option beats 2/3 of the field, the cycle breaks

Payoff Matrix

For intransitive systems, build a matrix of every option vs. every other option:

         | Rock | Paper | Scissors |
---------|------|-------|----------|
Rock     |  0   |  -1   |   +1     |
Paper    | +1   |   0   |   -1     |
Scissors | -1   |  +1   |    0     |

Checks:

• No row sums to positive (no dominant strategy)
• No row sums to negative (no dominated strategy)
• Cycles are truly circular — trace every chain
• With more than 3 options, verify no subset forms a dominant cluster

At scale: Simulate 1000+ matchups per pair. Statistical win rates should converge near 50% for balanced intransitive systems.

---

Economy Design

Economies are third-order design: you build a system → players create emergent behaviors → the combination is the actual experience.

Four Mechanisms

Mechanism	Example	Balance Lever
Generation (sources)	Mining, quest rewards, loot drops	Rate, caps, diminishing returns
Destruction (sinks)	Crafting costs, repair fees, consumables	Cost scaling, durability
Trading	Auction house, direct trade	Transaction fees, trade restrictions
Zero-sum	PvP loot, contested resources	Risk/reward ratio

Health Check

generation_rate > destruction_rate → inflation (prices rise, currency devalues)
destruction_rate > generation_rate → deflation (hoarding, new players locked out)

• Every source has a corresponding sink
• Sinks feel meaningful (not just taxes)
• New player earning rate enables meaningful participation
• Veteran stockpiling can't break the economy for newcomers
• Rewards encourage intended play (not degenerate optimization)
• Extrinsic rewards don't displace intrinsic satisfaction (mastery, discovery)

---

Dominant Strategy Detection

A dominant strategy is any approach that's optimal regardless of context. It kills meaningful choice.

Warning Signs

• One option has the highest pick rate across all skill levels
• Community consensus on a "best build" with no viable alternatives
• Win rate for one strategy/character exceeds others by >5% at comparable skill
• Players feel punished for experimenting

Diagnostic Steps

1. Check the cost curve — is the dominant option above the curve?
2. Check for hidden synergies — does it combo with common elements disproportionately?
3. Check the meta context — is it dominant because alternatives are weak, or because it's inherently too strong?
4. Check skill floors — is it dominant because it's easy to execute, not because it's powerful? (This might be acceptable)

Fixes (in preference order)

1. Buff alternatives before nerfing the dominant option (preserves player investment)
2. Add a cost the dominant option doesn't currently pay
3. Introduce a counter in the intransitive web
4. Nerf directly as last resort (communicate why)

---

Tuning Workflow

When balance needs adjustment mid-development:

1. Identify the symptom — what feels wrong from the player's perspective?
2. Gather data — pick rates, win rates, churn points, player feedback
3. Locate on the cost curve — is the problem object an outlier?
4. Hypothesize a cause — overtuned stats? Missing counter? Economic inflation?
5. Make ONE change — isolate variables
6. Playtest at both novice and expert levels — balance is skill-dependent
7. Measure again — did the symptom improve without creating new ones?
8. Iterate — balance is never "done"

Common mistakes:

• Balancing for the "average" player (bimodal skill distributions mean the average doesn't exist)
• Changing multiple variables at once (impossible to attribute results)
• Ignoring emergent player-driven strategies
• Sequential content releases without power creep checks

---

Cross-References

Three tight links. Everything else routes through the map, so adding a skill touches one file rather than twenty: references/routing-map.md (in game-design).

• economy-design — Designing an economy rather than tuning inside one
• simulation-first-design — Searching the balance space with bots instead of playtests
• progression-systems — Power curves, which must agree with cost curves