balance-check

Port provenance: adapted from the pinned upstream source at 984023ddac0d5e27624f2baacde6105e45de375f under MIT; see the repository parity ledger for the exact path and blob.

Phase 1: Identify Balance Domain

Determine the balance domain from the first invocation argument:

• Combat → weapon/ability DPS, time-to-kill, damage type interactions
• Economy → resource faucets/sinks, acquisition rates, item pricing
• Progression → XP/power curves, dead zones, power spikes
• Loot → rarity distribution, pity timers, inventory pressure
• File path given → load that file directly and infer domain from content

If no argument, ask the user which system to check.

---

Phase 2: Read Data Files

Read relevant files from assets/data/ and design/balance/ for the identified domain. Note every file read — they will appear in the Data Sources section of the report.

---

Phase 3: Read Design Document

Read the GDD for the system from design/gdd/ to understand intended design targets, tuning knobs, and expected value ranges. This is the baseline for "correct" behaviour.

---

Phase 4: Perform Analysis

Run domain-specific checks:

Combat balance:

• Calculate DPS for all weapons/abilities at each power tier
• Check time-to-kill at each tier
• Identify any options that dominate all others (strictly better)
• Check if defensive options can create unkillable states
• Verify damage type/resistance interactions are balanced

Economy balance:

• Map all resource faucets and sinks with flow rates
• Project resource accumulation over time
• Check for infinite resource loops
• Verify gold sinks scale with gold generation
• Check if any items are never worth purchasing

Progression balance:

• Plot the XP curve and power curve
• Check for dead zones (no meaningful progression for too long)
• Check for power spikes (sudden jumps in capability)
• Verify content gates align with expected player power
• Check if skip/grind strategies break intended pacing