| name | game-balance |
| description | Numeric balance across game objects with stats — cost curves, transitive vs intransitive systems, dominant strategy detection, sandbagging signals, and anti-degenerate-strategy levers. Use when designing item or weapon stats, pricing storefronts, combat damage/HP/range numbers, upgrade trees, character classes, faction asymmetry, or anywhere two objects have numeric attributes that should relate fairly. Apply when playtesters say 'X is just better,' 'one path always wins,' or 'I never use Y.' Pairs with economy-design (currency flow) and progression-systems (curves over time). |
Game Balance
Purpose: Systematic tools for tuning numeric systems — items, economies, combat, progression — so that player choices remain meaningful and no single strategy dominates.
Influences: Frameworks here draw on systematic game balance methodology, iterative design practice, and experience engineering theory.
When to Activate
Use this skill when:
- Designing item/weapon/unit stats and pricing
- Building or tuning an in-game economy
- Players report "X is overpowered" or "Y is useless"
- Adding new content to an existing system (power creep risk)
- Designing rock-paper-scissors or counter relationships
- Setting up resource generation/consumption loops
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
- List every object in the system (weapons, units, items, spells)
- Choose a baseline — the simplest, cheapest object
- Identify all attributes that contribute to value (damage, speed, range, utility, special effects)
- Assign relative weights to each attribute (this is the art — requires playtesting)
- Calculate total value for each object:
total_value = sum(attribute * weight)
- Plot cost vs. total_value on a scatter chart
- Fit a curve — linear, polynomial, or exponential depending on the system
- 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:
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)
Dominant Strategy Detection
A dominant strategy is any approach that's optimal regardless of context. It kills meaningful choice.
Warning Signs
Diagnostic Steps
- Check the cost curve — is the dominant option above the curve?
- Check for hidden synergies — does it combo with common elements disproportionately?
- Check the meta context — is it dominant because alternatives are weak, or because it's inherently too strong?
- 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)
- Buff alternatives before nerfing the dominant option (preserves player investment)
- Add a cost the dominant option doesn't currently pay
- Introduce a counter in the intransitive web
- Nerf directly as last resort (communicate why)
Tuning Workflow
When balance needs adjustment mid-development:
- Identify the symptom — what feels wrong from the player's perspective?
- Gather data — pick rates, win rates, churn points, player feedback
- Locate on the cost curve — is the problem object an outlier?
- Hypothesize a cause — overtuned stats? Missing counter? Economic inflation?
- Make ONE change — isolate variables
- Playtest at both novice and expert levels — balance is skill-dependent
- Measure again — did the symptom improve without creating new ones?
- 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
- game-design — 5-Component Framework for evaluating if balance changes serve the player experience
- economy-design — Deep economy architecture (sink/source modeling, currency design, inflation). This skill covers balance within economies; economy-design covers designing economies from scratch
- systems-design — Balance changes in one system ripple through connected systems
- progression-systems — Power curves interact directly with balance; changes in one affect the other
- motivation-design — Reward psychology that drives player perception of "fairness"
- experience-design — Balance exists to serve engagement, not mathematical purity
- encounter-design — Enemy balance and encounter composition
- playtest-design — Methods for gathering the data that informs balance decisions
