/game-balance-check

name: game-balance-check
description: >
  Validates and tunes game balance: economy faucets and sinks, progression and difficulty curves,
  reward pacing, win rates and dominant strategies, using agent-runnable simulations (Monte Carlo,
  AI-vs-AI) and telemetry. Use for "balance", "tuning", "difficulty spike", "Monte Carlo", "win
  rate". Not for designing currencies or monetization (use game-economy-designer).
argument-hint: "[system to analyze or tune]"
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion, Bash(npm run balance*), Bash(npx vitest *), Bash(node tools/balance/*), Bash(python3 tools/balance/*), Bash(godot --headless *), Bash(git log *), Bash(git diff *)
effort: high

AlterLab GameForge -- Balance Check

Balance is not making everything equal. It is making every choice feel fair while keeping decisions meaningful: every option has a trade-off, every intended playstyle is viable, and no single strategy is best everywhere. A perfectly symmetric game has no interesting decisions.

This workflow validates economy, progression, difficulty and reward systems with explicit models, then checks those models against evidence: simulations an agent can build and run in minutes, playtest observations, and telemetry from real players. The math tells you what the system does. Playtests tell you how it feels. You need both.

Purpose & Triggers

**Use this workflow when:**

• Currency inflates or deflates; players hoard or are always broke.
• One strategy, build, weapon or character dominates and the rest go unused.
• Progression feels too fast, too slow, or uneven (dead zones, then spikes).
• Players breeze through or hit walls; deaths cluster at one encounter.
• A new item, character, ability or system must fit into existing balance.
• Reward pacing sags in the mid-game; retention drops at a recognizable point.
• You need a simulation harness, a Monte Carlo run or an AI-vs-AI tournament.
• A pre-playtest or pre-launch balance pass.

**Do NOT use this workflow when:**

| Need | Route to | |---|---| | Designing currencies, pricing, monetization ethics | `game-economy-designer` | | Designing or redesigning a mechanic | `game-designer` (if the system is broken, tuning will not save it) | | How the balance *feels* to players | `game-playtest` | | Bugs, crashes, exploits caused by code defects | `game-qa-lead` | | Building the analytics pipeline and dashboards | `game-analytics-setup` | | Systems not defined yet | `game-prototype` first |

Inputs I Read First

• `.gameforge/project.json` (engine, phase), the GDD and economy model in `design/`

(`${CLAUDE_PLUGIN_ROOT}/templates/economy-model.md` is the expected shape), prior reports in `design/balance/`, tuning data files, and any playtest or telemetry exports.

• **Genre templates**: for run-based games read

`${CLAUDE_PLUGIN_ROOT}/genre-packs/roguelike/balance-template.md` (run economy, damage curves, rarity and pity, floor scaling, synergy scoring, Monte Carlo setup). For story-driven games read `${CLAUDE_PLUGIN_ROOT}/genre-packs/narrative/balance-template.md` (pacing, branch budgets, choice-consequence weight, playthrough length). Use them as the checklist for that genre.

• Ask up to three AskUserQuestion items, with defaults:

1. **System and symptom** (default: "the one players complain about most"). 2. **Evidence available**: none (spreadsheet and simulation), playtest notes, live telemetry. 3. **Target player**: session length and archetype mix (default: 30-60 minute sessions, average player as the primary target).

Critical Rules

1. **Balance is relative.** 100 damage means nothing without enemy health, alternatives, ammo scarcity and skill ceiling. 2. **Dominant strategies kill decisions.** Every viable strategy needs at least one situation where it is the wrong choice. 3. **Perception beats arithmetic.** A mathematically fair system can feel unfair. Losses weigh roughly twice as much as equal gains (Tversky and Kahneman's 1992 estimate of the loss-aversion coefficient is about 2.25); streaks feel rigged even when they are random. 4. **Never balance in a vacuum.** Map the dependency graph before changing a number; trace every change through it. 5. **Evidence hierarchy**: live telemetry > playtest observation > simulation > spreadsheet > intuition. Simulations validate the math, not the fun; a playtest closes the loop. 6. **Numbers live in data, not code.** Tuning constants sit in data files with units, ranges and a change log, so designers and agents can change them without touching logic. 7. **Reproducible or it did not happen.** Every simulation result cites its seed, build commit, config file and iteration count. 8. **Ground the analysis** in Flow, SDT and MDA from `${CLAUDE_PLUGIN_ROOT}/docs/game-design-theory.md`.

Workflow

**Step 1: Inventory and Dependency Map**

List every:

• **Currency**: gold, XP, stamina, crafting materials, reputation, premium currency.
• **Faucet**: quest rewards, drops, selling, daily bonuses.
• **Sink**: shops, upgrades, repairs, consumables, fees. Mark **hard sinks** (currency destroyed)

versus **soft sinks** (currency changes hands or form). Hard sinks control inflation; soft sinks only slow velocity.

• **Progression track**: level, gear score, skill tree, unlocks, meta-progression.
• **Difficulty variable**: enemy stats, spawn rates, AI behavior, timers, hazards.
• **Reward mechanism**: loot, unlocks, cosmetics, narrative beats, achievements.

Draw the dependency graph (Mermaid is fine). It is your guard rail: before changing any number, trace which systems move with it.

**Step 2: Expose Tuning Constants**

If balance numbers are scattered through code (common in agent-built games), the first deliverable is moving them into one data source the game, the simulation and a debug panel all read:

• Godot: a custom `Resource` (`.tres`); Unity: `ScriptableObject` assets; Unreal: Data Assets or

Data Tables; web: a typed `tuni