Players stop spending gold three hours into a session — not because they don't want to, but because hoarding is more rewarding. This isn't a coincidence but a broken inflation curve. We encounter this on every project: the point of accumulation shows up in the income/expenditure ratio table across progression levels long before release. With over 7 years of experience in game development and more than 50 completed projects, our team helps developers avoid such scenarios using a mathematical economy model. Our clients save an average of $15,000 on post-release balance fixes.
A mathematical game economy model is not just formulas in a vacuum. It's a tool to simulate thousands of players' behavior before any code is written. In a typical F2P project, the earn rate is 50 gold/minute and the burn rate is 60 gold/minute, creating a deficit of 10 gold/minute. After an hour, the player is in the red — necessitating additional income sources or increased accumulation limits.
Creating a Mathematical Economy Model: Algorithm
- Identify the game's core resources and currencies. Minimum two: soft currency (earned) and hard currency (purchased).
- Define progression curves for each currency: upgrade costs, item prices.
- Set earn rates and burn rates for every source and sink.
- Build a session simulation in Google Sheets with 10-minute steps over 40+ hours of gameplay.
- Analyze imbalances: inflation, deficits, bottlenecks.
- Export the table to CSV and integrate it into Unity via ScriptableObject.
This algorithm delivers a working economy in 2–4 weeks. Detailed formula documentation is provided.
What Is a Mathematical Game Economy Model?
It's a set of formulas, tables, and simulations that describe how players earn 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 by simulation before these numbers enter ScriptableObject or a 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, and inflation index (ratio of early resource value to late resource value). As noted in F2P monetization analytics reports, to maintain player interest, time to next milestone should not exceed 20 minutes. In practice, this means the progression curve must be tuned so that every 15–20 minutes the player feels a noticeable improvement.
Example: XP progression curve calculation
Base XP per mob: 100. Need 500 XP for level 2, 1000 for level 3, 1500 for level 4. Linear progression with step 500. For a level-up every 30 minutes at an earn rate of 200 XP/minute. Simulation shows that at level 30, time to next level exceeds 2 days — so switch to an exponential curve.How Are Progression Curves Built?
Three basic 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. Withmultiplier = 1.15and 100 levels, the last upgrade costs 1,174 times the first. Without late-game income sources, the player hits a paywall. - Polynomial:
cost(n) = a * n^2 + b * n + c. The sweet spot for PC/console: growth accelerates, but not exponentially. Coefficients are tuned to the desired time between upgrades.
| Curve Type | Growth | Application | Risk |
|---|---|---|---|
| Linear | Constant | Early levels | Quickly becomes uninteresting |
| Exponential | Accelerating | Mobile F2P | Paywall without late sources |
| Polynomial | Moderate | PC/Console, long progression | Requires precise coefficient tuning |
In practice, upgrade costs rarely come from a single formula — we use a stepped model: first 10 levels linear, then switch to polynomial, after a 'prestige' point — reset with a bonus multiplier. This creates perceptible 'chapters' of progression.
Session Simulation — Building the Model
A static table isn't enough. Simulation brings dynamics. In Google Sheets, we build a 'bot' that, every 10 minutes of in-game time, calculates resources earned, purchases made (based on optimal player behavior), and the current balance. Run it for 40 hours of gameplay.
Typical simulation findings: Resource B accumulates faster than it's spent starting at hour 8 — so either add a sink or reduce the earn rate. Or: the player reaches the upgrade ceiling at hour 12 when planned for 20 — the cost curve is too flat. Fixing imbalance after release can cost $20,000–$50,000, far exceeding the cost of a preliminary model.
How to Mathematically Describe Monetization?
F2P games build economies around two currencies: hard currency (purchased with real money) and soft currency (farmed). Critically, the hard-to-soft conversion must not break balance for free players. This is verified by the paying player advantage index: if a paying player for $10 gets the equivalent of 40 hours of farming, that's aggressive monetization; 10–15 hours is moderate.
Energy/stamina systems are mathematically described as a leaky bucket: filling at rate regenRate to maxEnergy, consuming on actions. Optimal maxEnergy is such that an average session (20–30 minutes) consumes 70–80% of the maximum. Less — the player ends with surplus and returns less often. More — the session cuts off mid-stream, which annoys players.
Which Tools for Integration?
The final value tables are exported to CSV and imported into ScriptableObject via a custom AssetPostprocessor or Editor script. This eliminates manual data transfer and related errors. When balancing changes, the designer edits the table, exports CSV, and Unity automatically updates assets. Learn more about ScriptableObject.
For runtime analytics, we integrate logging of key economic events: ResourceEarned, ResourceSpent, UpgradePurchased with metadata (player level, resource source, session time). The data goes to an analytics system (GameAnalytics, Amplitude, or a custom pipeline). One week after soft launch, we compare real player behavior to the simulated model.
What's Included in the Work
- Development of the mathematical model in Google Sheets/Excel
- Session simulation over 40+ hours of gameplay
- Economy documentation with formulas and settings
- CSV export and Unity integration via Editor scripts
- Recommendations for analytics setup
- Team training on working with the model
Estimated Timelines
| Task | Timeframe |
|---|---|
| Basic progression model (one currency, XP, 30 levels) | 3–7 days |
| Full model (multiple currencies, crafting, monetization) | 2–4 weeks |
| Model + session simulation + analytics integration | 4–8 weeks |
Why Economies Break: Common Mistakes
- Symmetric sources and sinks. If every quest gives 100 gold and every upgrade costs 100 gold, the player has no reason to prioritize anything. Diverse sources and sinks create interesting resource allocation choices.
- Unaccounted accumulation effect. Players who skip a few days return with full resources and multiple upgrade levels at once. If this isn't built into the model, their rapid progress breaks multiplayer economy balance.
- Inflation without resets. In long-running online games without sink mechanics (taxes, item decay, consumable crafting), soft currency accumulates among veteran players to levels that make farming pointless for newcomers. Periodic event sinks or seasonal resets are standard solutions.
Contact us to evaluate your current economy. Order a model development and get a consultation on balance improvements. We guarantee optimization of your economy within 2–4 weeks.