/game-balance-check

name: "game-balance-check"
description: >
  Invoke when the user needs to validate game balance, tune economy systems, analyze
  progression curves, evaluate difficulty scaling, or check reward pacing. Includes
  Monte Carlo simulation and statistical validation. Triggers on: "balance", "economy
  tuning", "progression curve", "difficulty scaling", "reward pacing", "Monte Carlo",
  "fairness check". Do NOT invoke for economy/monetization design (use
  game-economy-designer) or code review (use game-code-review). Part of the AlterLab
  GameForge collection.
argument-hint: "[system to analyze]"
effort: medium
context: fork
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion
version: 1.3.0

AlterLab GameForge -- Economy & System Balance Validation

Balance is not about making everything equal -- it is about making everything feel fair while keeping decisions meaningful. A perfectly balanced game where every option is identical is a game with no interesting decisions. Into the Breach achieves near-perfect balance not through symmetry but through information transparency -- every option is viable because every consequence is visible. Slay the Spire achieves it through controlled variance -- any card can be powerful in the right deck, and Jorbs' statistical breakdowns prove the math holds across thousands of runs.

The goal is controlled asymmetry: every choice has a trade-off, every path is viable, and every player feels their preferred playstyle is respected. This workflow provides formal models -- including statistical validation and simulation -- for validating economy, progression, difficulty, and reward systems.

Purpose & Triggers

**Invoke this workflow when:**

• An in-game economy is producing unintended inflation or deflation
• Players are gravitating toward a single dominant strategy and ignoring all alternatives
• Progression feels too fast (trivializing content), too slow (creating grind walls), or uneven (dead zones followed by spikes)
• Difficulty scaling needs calibration -- either players are breezing through or hitting walls
• Reward pacing needs analysis to sustain engagement through the mid-game and endgame
• A new item, character, ability, or system is being introduced and needs integration with existing balance
• Free-to-play monetization fairness needs auditing -- the gap between paying and non-paying players must be reasonable
• Pre-release balance pass is needed before a playtest or launch

**Do NOT use this workflow when:**

• The game has no systems to balance (pure narrative games, walking simulators with no mechanics)
• You are still in the prototyping phase and systems are not yet defined (use `game-prototype` first)
• The balance problem is actually a design problem -- if the system is fundamentally broken, tuning numbers will not save it

Critical Rules

1. **Balance is relative, not absolute.** A weapon that deals 100 damage is not overpowered or underpowered in isolation. It is only meaningful relative to enemy health pools, other weapon options, ammunition scarcity, and player skill ceiling. 2. **Dominant strategies kill games.** If one approach is strictly better than all alternatives in all situations, you have a balance failure. Dead Cells handles this by making every weapon viable through situational DPS curves -- a slow broadsword outdamages daggers against single targets but fails against swarms. Every viable strategy must have at least one situation where it is suboptimal. 3. **Perception matters more than math.** A system can be mathematically balanced but FEEL unfair. Player psychology (loss aversion, anchoring, confirmation bias) must be factored into balance analysis. A player who loses a rare item to a 5% failure chance remembers that loss far more vividly than the 95 successes. Balatro understands this -- its pity system and score multiplier transparency make variance feel fair even when the math is brutal. 4. **Never balance in a vacuum.** Every system interacts with every other system. Changing the warrior's damage output affects healer balance, enemy design, level pacing, and economy. Map the dependency graph before touching any number. Factorio's developers famously trace every balance change through the entire production chain before shipping it. 5. **Data over intuition.** When you have telemetry, use it. When you do not, use Monte Carlo simulation to generate synthetic data. "It feels about right" is not a balance methodology. 6. **Reference `docs/game-design-theory.md`** for Flow Theory (challenge-skill balance), SDT (competence feedback loops), and MDA Framework (how balance affects target aesthetics).

Workflow

**Step 1: System Inventory and Dependency Mapping**

Before you can balance a system, you must understand what the system contains and how it connects to everything else.

Create a complete inventory of:

• **Currencies**: Every resource the player can earn, spend, trade, or lose (gold, XP, stamina, gems, reputation, crafting materials, etc.)
• **Sinks**: Every place currency leaves the economy (shops, upgrades, repairs, consumables, taxes, etc.)
• **Faucets**: Every place currency enters the economy (quest rewards, loot drops, selling, daily bonuses, etc.)
• **Progression tracks**: Every axis of player growth (level, gear score, skill tree, reputation tiers, collection progress, etc.)
• **Difficulty variables**: Every parameter that affects challenge (enemy stats, spawn rates, AI behavior, environmental hazards, time limits, etc.)
• **Reward mechanisms**: Every system that gives the player positive feedback (loot, achievements, unlocks, cosmetics, narrative progress, etc.)

Build a dependency graph showing how these systems connect. When system A changes, which other systems are affected? This graph is your guard rail -- before changing any number, trace the ripple effects through the dependency graph.

**Step 2: Economy Validation**

**Faucet/Sink Analysis**

Map every currency source and sink with flow