game-balance-check

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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 rates:

```
[Source] --[rate/hour]--> [Currency Pool] --[rate/hour]--> [Sink]

Example:
Quest Rewards  --500g/hr-->  Gold Pool  --300g/hr-->  Equipment Shop
Monster Drops  --200g/hr-->  Gold Pool  --150g/hr-->  Consumables
Daily Login    --100g/day->  Gold Pool  --50g/hr--->  Fast Travel
                                        --100g/hr-->  Crafting
```

Calculate the net flow: Total Faucet Rate minus Total Sink Rate = Net Accumulation Rate. If net accumulation is positive, the economy inflates over time (currency becomes worthless). If negative, the economy deflates (players feel increasingly poor). Neither extreme is good -- target a slight positive accumulation that is periodically reset by major purchases (new gear tier, base upgrade, etc.).

**Earn-Rate Analysis by Player Archetype**

Not all players play the same way. Model at least three player archetypes:

| Archetype | Play Pattern | Earn Rate | Expected Behavior |
|-----------|-------------|-----------|-------------------|
| **Casual** | 30 min/day, focuses on main quests, skips optional content | Lowest | Should progress at a satisfying pace without feeling punished for limited playtime |
| **Average** | 1-2 hrs/day, completes main + some side content, moderate exploration | Median | The "target" player. Balance primarily for this archetype. |
| **Hardcore** | 4+ hrs/day, min-maxes everything, optimizes farm routes | Highest | Should have meaningful things to spend surplus on. Currency should never become meaningless. |

**Time-to-X Analysis**

Calculate how long each archetype takes to reach key milestones:

| Milestone | Casual | Average | Hardcore | Target Range |
|-----------|--------|---------|----------|-------------|
| First major upgrade | ? hrs | ? hrs | ? hrs | 1-2 sessions |
| Midgame gear plateau | ? hrs | ? hrs | ? hrs | 10-15 sessions |
| Endgame entry | ? hrs | ? hrs | ? hrs | 30-50 sessions |
| Max level/gear | ? hrs | ? hrs | ? hrs | 80-150 sessions |

If the casual-to-hardcore ratio exceeds 5:1 for any milestone, the economy may be too grind-dependent and too punishing for casual players.

**Premium Currency Fairness (if applicable)**

If the game has premium (paid) currency alongside earned currency:
- Can a free player access ALL gameplay-relevant content at a reasonable rate? ("Reasonable" means the casual archetype reaches endgame within 6 months of regular play.)
- Are premium purchases time-savers or power advantages? Time-savers are generally accepted by players. Power advantages create pay-to-win perception even if the math says otherwise.
- Is there a conversion path between earned and premium currency? If so, is the exchange rate fair or exploitative?
- Are loot boxes or gacha mechanics involved? If so: Are probability tables disclosed? Is there a pity system (guaranteed reward after N attempts)? Is there duplicate protection?

**Step 3: Progression Curve Analysis**

**Power Curve Mapping**

Plot player power (aggregate combat effectiveness, measured as DPS * survivability) against time or content progression. Categorize the curve shape:

- **Linear**: Power grows at a constant rate. Feels predictable and steady but becomes boring after the midpoint because each increment feels identical. Common failure mode: "I leveled up but I don't feel stronger."
- **Exponential**: Power grows faster and faster. Feels incredible early (every upgrade is huge) but becomes unsustainable -- either the endgame is trivially easy or enemies must scale exponentially to match, creating a numbers treadmill. Common failure mode: "The numbers are meaningless."
- **Logarithmic**: Power grows quickly early and then plateaus. Front-loads satisfaction but creates a feeling of stagnation in the midgame. Common failure mode: "Nothing I do makes me stronger anymore."
- **S-Curve (Sigmoid)**: Fast initial growth, gentle middle, satisfying mastery plateau. This is the target for most games. The early phase teaches and rewards rapidly. The middle phase deepens mastery. The endgame rewards optimization and expression rather than raw power. Common success indicator: "I'm not stronger, but I'm BETTER."

**Dead Zone Detection**

Scan the progression curve for flat sections where the player receives no meaningful power increase for an extended period. Dead zones cause churn -- players quit during the midgame slog more than at any other point. Every dead zone should either be eliminated (add a reward) or justified (narrative beat that intentionally strips power for dramatic effect, with a clear promise of restoration).

**Spike Zone Detection**

Scan for sudden jumps in power. A player who doubles in effectiveness by equipping a single item has just made every previous upgrade feel worthless. Spikes should be rare, earned, and narratively justified (legendary weapon, prestige class, transformation).

**Level-Gating Fairness**

For each level/tier gate in the game:

From AlterLab-IEU/AlterLab_GameForge, MIT.

More from AlterLab-IEU/AlterLab_GameForge