Game economy review

Game Economy Review

Produce a Game Economy Specification whose fun, progression, scarcity, fairness, and monetization remain sustainable across launch, seasons, veteran accumulation, late joiners, refunds, and low population.

Atomic boundary

Own currency/inventory authority, sources/sinks, price/reward tables, pacing, chance/pity guarantees, purchase/ad/event projections, refund adjustment, inflation/concentration, simulations, applicable tuning controls, and economy observability selected for the actual authority and business model. Do not own the complete core game, provider payment ledger, one daily loop, one campaign, or release/distribution program.

Use a draft artifact ID, named assumptions, and explicit sibling handoffs while designing. Let deterministic delivery tooling seal serialized versions and digests later; never invent a digest or proof state.

Agent-first invariant

For every selected economy capability, build the full versioned model, deterministic simulator, authority-appropriate value history, migration and recovery contract, and bounded controls now. A locally authoritative offline premium game may satisfy this with deterministic local history, save migration, backup/restore, and corruption recovery. Purchased, shared, remote-authoritative, tradable, or live-tuned value additionally requires an append-only server ledger, fraud/abuse controls, kill switches, canaries, and cohort readback. Mark non-applicable machinery with the exact authority/business-model reason; do not invent a service merely to complete a checklist. Use verified slices and exposure gates for safety, not a thin launch economy followed by manual hardening. Autonomous tuning may act only inside declared bounds; prices, odds, pity, entitlements, grants, and material value semantics require an independently validated candidate.

Workflow

1. Define genre, core/session/meta loops, mastery/fantasy promise, audience and age modes, business model, content cadence, progression horizon, baseline access without optional paid acceleration, and ruin boundaries.
2. Read references/game-economy-patterns.md. Inventory every durable, seasonal, premium, earned, purchased, social, event, and ephemeral value; name its authority, transferability, expiry, refund treatment, and recovery.
3. Map sources and sinks by loop, cohort, payer state, progression, season, and time. Quantify faucets, drains, stock, velocity, concentration, unmet demand, and dead/mandatory currency.
4. Model price/reward/pacing curves, upgrade/crafting/repair, duplicate items, caps, exchange, gacha odds/pity/guarantees, battle-pass reachability, advertisements, offers, events, and comeback/catch-up. Calculate distributions and sensitivities using the equations and fixtures in the reference rather than supplying one average path.
5. Define the value-history authority and projections for every applicable grant, spend, transfer, reserve, expire, convert, refund/revoke, chargeback, rollback, restore, migration, compensation, and support correction. Use an append-only server ledger with idempotency for purchased, shared, remote-authoritative, or tradable value; use deterministic local save/history and migration/recovery invariants for a strictly offline local economy.
6. Simulate day-0, day-30, year-1, late-joiner, returning, baseline/non-payer, payer, high-skill, low-population, concentrated-wealth, exploit, and content drought cohorts. Include stochastic uncertainty and sensitivity ranges.
7. Set bounded tuning parameters and independent validation. Add anomaly/fraud detection, canaries, pause/rollback/forward-fix, and live readback wherever remote, purchased, shared, or live-authoritative effects make them applicable; otherwise define deterministic local validation and recovery.

Source verification

Retrieve current store/payment, chance-based item/odds, child/age, advertising, promotion, refund, virtual-currency, marketplace/trading, territory, and tax authority for the exact platforms and audience modes. Unknown authority blocks the affected exposure, not construction of the dormant adapter.

When not to use

• Use game-design-blueprint when core play, progression, challenge, social, content, retention, feel, and platform experience must be designed together.
• Use daily-reward-and-streak-review for one recurring calendar/streak state machine and its economy handoff.
• Use payment-platform-readiness for checkout, receipts, provider events, settlement, entitlement projection, reconciliation, and finance close.
• Use promotion-campaign-review for one time-bounded offer/event and its audience/placement/fulfillment experiment.

Guardrails

• Fun and meaningful choice come before extraction; monetization cannot repair weak gameplay or make the baseline path non-viable.
• Publish exact odds/pity where required and never use fake scarcity, hidden odds, misleading value anchors, or loss threats.
• Bound vertical dominance; give veterans horizontal identity/mastery/social value while keeping newcomers contributive and late entry viable.
• Ordinary refunds enter declared value adjustment/reconciliation; automatic bans, surprise debt, and deletion of unrelated progress are forbidden.
• Never tune from aggregate ARPDAU alone. Track progression, scarcity, inflation, concentration, completion, fairness, support, churn, abuse false positives, and long-term retained value by cohort.

Output contract

Return one typed Game Economy Specification containing:

1. draft artifact ID, economy thesis, loops, audiences, baseline reachability, horizons, and ruin boundaries;
2. asset/currency/inventory authority map and value-history/projection state machine, using a server ledger only where the authority model requires it;
3. sources/sinks/stock/velocity/concentration matrix by cohort and season;
4. progression, price, reward, gacha/pity, battle-pass, ad, offer, event, catch-up, duplicate, expiry, and conversion tables;
5. refund/revoke/chargeback/restore/migration/support rules;
6. deterministic simulation fixtures, equations, distribution/quantile results, sensitivities, invariants, and limits;
7. tuning/admin authority and the applicable anomaly/fraud controls, event schema, dashboards, canaries, rollback/forward-fix, live readback, or deterministic local validation/recovery, with explicit non-applicable dispositions;
8. payment, campaign, daily loop, analytics, and game-blueprint handoffs with draft IDs, required inputs, acceptance questions, and no fabricated proof.

Complete only when the selected value history can be deterministically replayed or reconstructed at its declared authority, simulated cohorts remain viable, every tuning parameter has bounds/authority, and the system can pause or recover without corrupting durable player value. Server-ledger and live-cohort proof are mandatory only for the economy classes that require those surfaces.