Creating Mathematical Models of Game Economy
When a player in the third hour of a session stops spending gold—not because they don't want to, but because saving is more profitable—it's not chance. It's a broken inflation curve. And it's discovered not in playtesting, but in a spreadsheet: if you calculate the income/expenditure ratio across progression levels, the accumulation point is visible long before release.
What Is a Game Economy Mathematical Model
It's a set of formulas, tables, and simulations describing: how the player earns resources (gold, XP, materials, energy), how they spend them, and how this dynamic changes with progression. The model is built in spreadsheets (Google Sheets or Excel) and verified via simulation before these numbers go into ScriptableObject or database.
Key parameters the model must describe: earn rate (resources per minute of active play), burn rate (spending on upgrades, purchases, losses), time to next milestone (how long until next significant improvement), inflation index (ratio of early resource value to late).
Formula Base: Progression Curves
Three basic curve types for XP and upgrade costs:
Linear: cost(n) = base + n * step. Predictable, but quickly becomes insignificant—the difference between levels 50 and 51 feels the same as between 1 and 2.
Exponential: cost(n) = base * multiplier^n. Typical for mobile games. At multiplier = 1.15 and 100 levels, the last upgrade costs 1174 times more than the first. Without late-game income sources, the player hits a paywall.
Polynomial: cost(n) = a * n^2 + b * n + c. Sweet spot for PC/console: growth accelerates, but not exponentially. Coefficients a, b, c are tuned to desired upgrade timing.
In practice, upgrade costs rarely come from a single formula—a stepped model is used: first 10 levels linear, then switch to polynomial, after "prestige" point—reset with bonus multiplier. This creates felt "chapters" of progression.
Session Simulation
One table is static. Simulation is dynamic. In Google Sheets a "bot" is built: cells that every 10 minutes of game time calculate earned resources, what's been purchased by optimal player algorithm, what balance is. Run for 40 hours of gameplay.
Typical simulation findings: resource B accumulates faster than it's spent starting at hour 8—meaning we need to add a sink (spending) or reduce earn rate. Or: player reaches upgrade "ceiling" at hour 12 vs. planned 20—cost curve is too weak.
Monetization Mechanics and Math
F2P games build economy around two currencies: hard currency (real money) and soft currency (farmed). Critical that hard→soft conversion doesn't break free player balance. Verified via paying player advantage index: if $10 spending equals 40 hours of farm, it's aggressive; 10–15 hours is moderate.
Energy/stamina systems are mathematically leaky buckets: fill at regenRate up to maxEnergy, spend on actions. Optimal maxEnergy is such that an average session (20–30 minutes) uses 70–80% of max. Less—player ends with reserves and returns rarely. More—session cuts short, frustrating.
Tools and Game Integration
Final value tables are exported to CSV and imported to ScriptableObject via custom AssetPostprocessor or Editor script. This eliminates manual digit transfer and errors. On balance change, designer fixes the table, exports CSV, Unity automatically updates assets.
For runtime analytics, key economic events are logged: ResourceEarned, ResourceSpent, UpgradePurchased with metadata (player level, resource source, session time). Data goes to analytics system (GameAnalytics, Amplitude, or custom pipeline). A week after soft launch, real player behavior versus modeled is visible.
Timeline Guidelines
| Task | Timeframe |
|---|---|
| Basic progression model (single currency, XP, 30 levels) | 3–7 days |
| Full model (multiple currencies, crafting, monetization) | 2–4 weeks |
| Model + session simulation + analytics integration | 4–8 weeks |
Common Design Mistakes
Symmetric sources and sinks. If every quest gives 100 gold and every upgrade costs 100 gold, player has no reason to prioritize. Diverse sources and sinks create interest in resource distribution.
Unaccounted "accumulation effect." Players who miss several days return with overflowing resources and several upgrade levels at once. If not built into the model, their progress severely breaks multiplayer economy balance.
Inflation without reset. In long-lived online games without sink mechanics (taxes, item decay, crafting with spending), soft currency accumulates in old players to levels making farm meaningless for new. Periodic sink events or seasonal resets are standard.