Creating a Mathematical Economy Model for Games

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

1. Identify the game's core resources and currencies. Minimum two: soft currency (earned) and hard currency (purchased).
2. Define progression curves for each currency: upgrade costs, item prices.
3. Set earn rates and burn rates for every source and sink.
4. Build a session simulation in Google Sheets with 10-minute steps over 40+ hours of gameplay.
5. Analyze imbalances: inflation, deficits, bottlenecks.
6. 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.

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. With multiplier = 1.15 and 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.

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

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.

What makes our game design services comprehensive?

Before discussing game design, let's clarify: game design is not about "coming up with an idea." Anyone can do that. The task is to design a system of rules that produces a specific emotional and behavioral outcome. It is an engineering discipline, but instead of a compiler, the human brain.

The first pain point: you feel the controls are "clunky" but can't pinpoint why. Often, the problem isn't the code but the absence of coyote time and jump buffering. Or linear acceleration that doesn't convey weight. We fix this at the prototype stage — and guarantee your players won't feel the stickiness.

Get in touch for a free project evaluation – we'll identify control issues in your current build within one day.

Game design services: from GDD to polished build

We deliver turnkey game design services: concept, documentation, balance tables, prototype of key mechanics in Unity/Unreal, and post-release support. Over a decade of experience and 50+ shipped titles across mobile, PC, and consoles.

Deliverables included:

• Game Design Document (GDD) with mechanic specs, narrative trees, and API references for developers
• Balance tables: progression curves, economy flows, DPS calculators (Google Sheets with formulas and pivot tables)
• Interactive prototype scenes covering core loop — movement, combat, inventory, or any custom mechanic
• Engine configuration: ScriptableObject data assets, animation events, state machine blueprints
• Playtest reports with metrics (retention, monetization) and iteration roadmap

Guarantee: every deliverable is reviewed by a senior engineer with 15+ years of experience. No template work — each solution is custom-fit to your genre and platform.

How do our game design services improve combat system tuning?

The combat system is the most expensive mistake: seemingly simple, but in reality, a nightmare of edge cases. Let's break down melee combat.

Choosing a hit detection method

Hitbox — colliders on weapons. Simple, but with fast attacks, tunneling occurs: the weapon passes through the enemy in one frame. Continuous Collision Detection (Physics.CCD) fixes this but costs CPU. Raycast/spherecast — cast rays along the weapon's trajectory. More accurate, less framerate-dependent. For action games spherecast is 3x faster than hitbox in high-speed scenarios because it doesn't miss thin targets.

Setting up attack windows

Each attack has three phases: startup, active, recovery. Long startup creates "heavy" hits. Short recovery gives an aggressive style. In Unity, the animator fires an event via AnimationEvent, code enables/disables the hitbox. Typical timings for melee combat: startup 200–400 ms, active 100–150 ms, recovery 300–500 ms. Tuning these windows reduces feel complaints by 60% in playtests.

Building the state machine

The character is a finite state machine. Basic states: Idle, Moving, Jumping, Attacking, Hurt, Dead. Business logic in C#, animator handles only transitions. Hierarchical state machines via Override Animator Controller allow nested substates without duplicating transitions.

Why is a mathematical economic model critical?

Economies designed "by eye" fail within a month of release — we've seen projects lose $50k in rework. Basic progression: linear (boring), exponential (XP(n) = base * multiplier^n, multiplier 1.5–2.0), polynomial (a * n^b, b 1.5–2.5). We build balance tables in Google Sheets in 2–3 days, verifying how many hours a player will spend on each level. Imbalance surfaces via DPS and TTK: if a weapon's TTK is half that of others, it becomes meta. Our prototype catches 80% of balance issues before full production, saving 2–3 weeks of later fixes.

Currency flows

Each currency must have a clear source (tap) and sink. Example of a two-currency system:

One-way conversion protects monetization. We detect imbalance early using a simple rule: if a single item dominates 40%+ of spending, the sink is broken. This approach reduces post-launch balancing costs by up to $15k.

How does environmental storytelling work in game design?

Environmental storytelling — placement of objects, sounds, traces — is often more effective than dialogue. For dialogue we use Ink (integration with Unity). Ink scripts are editable by a narrative designer without a programmer. Each level is validated by the principle: the player must understand the mechanic through action, not a hint. This approach improves first-time clarity by 30% in our playtests.

Our tech stack for game design

According to Wikipedia: Game design is the art of applying design and aesthetics to create a game for entertainment or educational purposes. We apply this principle from day one.

Process: how we work in 4 steps

1. Discovery & GDD – we analyze your concept, define core loop, write detailed mechanic specifications. (1–2 weeks)
2. Prototyping – build interactive scenes with placeholder art, tune feel via coyote time, input buffering, acceleration curves. (2–3 weeks)
3. Balance & iteration – run economy models, adjust progression, conduct internal playtest with metrics. (1 week per major mechanic)
4. Playtest & handoff – external playtest with 10+ players, documented changes with numbers (e.g., "startup 400ms → 250ms"), deliver final GDD and configuration files.

Iteration and playtesting: 2-week cycle

The first prototype is always uncomfortable — that's normal. Our cycle: playtest every 2 weeks. After that, a list of changes with numbers: "startup 400 ms → 250 ms". Opinions without numbers are not accepted. We record feelings, change numbers, repeat. Clients save 2 to 3 weeks on iterations thanks to this process.

Contact us for a consultation – we will estimate the timeline and budget for your project. Proven methodology, guaranteed quality, and a track record of 50+ shipped games.