difficulty-and-balancing

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.