Game economy design almost always starts the same way:
- You open a spreadsheet.
- You define a few currencies, maybe sketch a progression curve, add some reward tables — and things feel under control. At first. But as your game grows, the economy grows with it. And the tools you started with begin to show their limits.
The Standard Workflow Most Teams Use
If you’ve worked on a game economy, this setup will probably look familiar:
Google Sheets - balancing, numbers, simulations
Miro - mapping systems and flows
Notion - documenting logic and decisions
Each tool solves a different problem. Together, they form a patchwork system.
And that’s exactly where the issues begin.
The Hidden Cost of Spreadsheets
Spreadsheets are incredibly flexible — which is both their strength and their weakness.
1. Complexity Creeps In
What starts as a simple table turns into:
- Dozens of interconnected sheets
- Deeply nested formulas
- Hardcoded assumptions
- References that are hard to trace
At some point, the sheet stops being a tool — and
2. Systems Become Invisible
Game economies are systems:
- Currencies flow between features
- Sources and sinks interact
- Changes ripple across the entire game
But spreadsheets don’t show systems — they show data.
So designers compensate by building diagrams in tools like Miro.
Now you have:
- Data in one place
- System logic in another
And they drift apart over time.
3. Simulation Becomes Fragile
You can simulate an economy in spreadsheets.
But in practice:
- Simulations are hard to scale
- Small mistakes break large models
- Iteration becomes slow
This leads to a subtle but important problem:
Designers test less.
And fewer simulations mean more risk in the live economy.
4. Knowledge Gets Fragmented
When you split your workflow across tools:
- Sheets - numbers
- Miro - structure
- Notion - explanations
There’s no single source of truth.
This creates:
- Misalignment between team members
- Outdated documentation
- Repeated questions and rework
The Real Issue: Tools vs Systems
The core problem isn’t spreadsheets themselves.
It’s that general-purpose tools are being used to manage system-level complexity.
Game economies are:
- Interconnected
- Dynamic
- Continuously evolving (especially in LiveOps)
But the tools are:
- Static
- Isolated
- Not system-aware
That mismatch becomes more painful over time.
When Do These Problems Start Showing?
Not immediately.
Usually when your game reaches:
- Multiple currencies (soft, hard, event-based)
- Several progression layers
- LiveOps features (events, battle passes, offers)
- Frequent balancing updates
At that point:
- Small changes have large side effects
- Tracking impact becomes difficult
- Confidence in changes decreases
*What Teams Usually Do Next
*
Different teams solve this in different ways:
- Build more complex spreadsheets
- Add more documentation
- Create more detailed diagrams
- Rely more on experience and intuition
These help — but they don’t solve the underlying issue.
They just manage it.
Final Thoughts
Spreadsheets are an excellent starting point for economy design.
They’re flexible, fast, and accessible.
But as your system grows, the cost of maintaining that flexibility increases:
- More manual work
- More risk of errors
- Slower iteration
At some point, the challenge shifts from “how do we design this?”
to “how do we manage the complexity of what we’ve already built?”
And that’s where the real difficulty of game economy design begins.
Recently, while dealing with these exact issues, I came across tools like Itembase.dev that try to approach economy design as a system rather than just a collection of tables.
Not saying it’s the solution — but it did make me realize how much friction in our workflow actually comes from the tools we use, not just the design itself.
If you're working on game economies, I'd be curious:
At what point did your spreadsheet setup start breaking down?
Top comments (0)