Difficulty & Balancing

The discipline of ensuring no single option dominates and every player stays in the flow channel — made rigorous by encoding balance as testable invariants and verifying them through simulation, not intuition alone.

Tier: universal craft (→ gamestack-core). Applies across all genres and multiplayer contexts. The encounter-difficulty application lives in combat-design; economy and loot power-budget live in rpg-systems.

When to use this

• Auditing a system for dominant strategies (God-tier lock-in, degenerate meta, solved builds)
• Verifying cost-curve balance across a weapon, card, or unit roster
• Designing or tuning a difficulty curve — encounter sequence, wave rhythm, spike detection
• Specifying or auditing a DDA system (target metric, adjustment range, visibility decision)
• Designing difficulty settings and per-axis accessibility assists
• Building a pre-ship balance spreadsheet or instrumenting post-ship telemetry

Scope

This skill owns the balance and difficulty of game systems — option viability, cost curves, difficulty curves, DDA, and accessibility. Adjacent concerns live in sibling skills:

• The "interesting decision / no dominant option" principle as a design foundation → game-design-fundamentals (this skill operationalizes that invariant)
• Encounter difficulty, enemy telegraphing, and encounter feel → combat-design
• Economy tuning, loot tables, and power-budget math → rpg-systems
• Macro difficulty pacing across a session arc → pacing-and-the-player-journey
• Procedural content gating and generation constraints → procgen-review
• Fairness and player expectations under permanent death → permadeath-and-lethality

How the pieces fit

• GUIDE.md — the cited why, in five sub-domains: dominant strategies & degenerate cases; balance structures (symmetric/asymmetric/intransitive + cost-curve/power-budget); difficulty curves & DDA / hidden directors; difficulty settings & accessibility; metrics-driven balance (spreadsheets, simulation, telemetry). Each rule carries an exemplar + source, a test-for criterion, the named failure mode, and the procedural/headless implication.
• CHECKLIST.md — Do/Don't + machine-checkable Test-for criteria, grouped by sub-domain. Written to be enforced as automated validators in a generation or build-gate loop.

The one idea to anchor on

Balance exists to ensure no single option dominates — and this is the most machine-checkable discipline in game design. Sid Meier's rule (GDC 2012): a choice with an obvious correct answer is not a decision. Encode the invariant ("no option's expected value exceeds all others in >80% of game states"), then simulate to enforce it. A human team can feel a broken meta; a headless generator cannot — it must measure it. Build the payoff matrix, run the dominance check, and gate every content ship on the result.

Start with GUIDE.md, then apply CHECKLIST.md.