💡 This post was originally published on the Leap blog. Cross-posted here for the dev.to community.

Excel, Machinations, custom code, or an integrated engine: a comparison of approaches.

You've designed the economy. The currencies are defined, the progression curve is drawn, the loot tables are balanced on paper. Now comes the uncomfortable question every designer eventually asks:

Will it actually feel right when a real player plays it?

This is the hardest moment in economy design. You can't ship and find out. Re-balancing after launch costs you retention, monetization, and player trust. You can't rely purely on playtesting, your testers play for days; your real players will play for months. And you can't just trust your intuition, because game economies are emergent systems, and emergent systems surprise everyone, including the people who designed them.

So designers simulate. The question is how.

Over the past decade, four approaches have emerged, each with a different cost, a different ceiling, and a different failure mode. Three of them, spreadsheets, dedicated simulation tools, and custom-coded stacks, share a single, structural weakness that's worth naming before we look at any of them in detail.

The gap between designed and live. In all three of these approaches, the economy you design lives in a different artifact from the economy that runs in your game.

A spreadsheet isn't the game. A Machinations graph isn't the game. A Python simulator isn't the game. So every iteration requires a handoff: someone has to take what was designed, translate it into production code, ship a build, wire up A/B testing somewhere else, and pipe the analytics into yet another tool.

Every handoff is a place where time is lost, meaning is lost, and trust between simulation and reality slowly erodes.

That gap is the through-line of the first three approaches. The fourth approach exists because someone asked whether the gap had to be there at all.

Approach 1: The spreadsheet

Every economy designer starts here. You open Excel or Google Sheets, build out your progression curve, layer in drop rates, and trace a hypothetical player through the first 30 days of play. You tweak numbers until the curve looks right.

What it's good for. Early ideation. Sanity checks.

Where it breaks. A spreadsheet models one player, on one path, making one set of choices. Real economies have thousands of players making different choices, with random drops, with variable session lengths, with social dynamics. A spreadsheet can't tell you what happens when 5% of your players skip the tutorial, or when the top 1% of spenders saturate the inventory cap, or when a rare drop feels rare enough at level 10 but oppressive at level 40.

Where it fits. Essential, but not sufficient. Every designer needs one. No designer should stop here.

Approach 2: A dedicated simulation tool like Machinations

Machinations deserves credit for being one of the first tools to take game economy simulation seriously. You model your economy as a visual graph and watch it run. For a designer who's been living in spreadsheets, the first time you see your economy simulate visually is genuinely revelatory.

What it's good for. Thinking in systems. Catching feedback loops you didn't know were there. Teaching economy design, probably the best pedagogical tool now in the industry. Validating the shape of an economy before you commit to implementation.

Where it breaks. Machinations is a simulation engine, and that's where it stops. Once you've validated your design, the gap reasserts itself in full force: the design has to be re-implemented in your actual game, A/B testing has to be set up separately (IE: Firebase), analytics have to be wired up separately (IE: Firebase & BigQuery), and any post-launch tweak means filing a ticket and waiting for a build. The simulation and the live game are two different artifacts. Every change has to be made twice. Every number has to be trusted on faith because the thing you simulated isn't the thing that's running.

Where it fits. A fantastic thinking tool. Not a production path.

Approach 3: Custom-coded simulation

Larger studios, that usually have dedicated economy teams and the engineering headcount to back them up, often build their own simulation frameworks. A few senior engineers write a simulator in Python or C++. Designers hand over specs; engineers translate them into simulation parameters; the team runs thousands of virtual players and analyzes the output.

What it's good for. Historically, this has been the path for studios with mature economies, deep pockets, and long product lifecycles. When you're operating a top-grossing live-service title, the depth of control a custom stack gives you has been worth the cost.

Where it breaks. Building and maintaining a custom simulator is a full-time job for multiple senior engineers. Every time the design changes, the simulation has to be updated: by engineers, not by designers. Iteration slows to a crawl. And the same re-implementation gap from Approach 2 still exists: the simulator and the live game are separate codebases, and they drift.

In practice, studios taking this route spend months setting up the workflow: logic in Excel, custom coded simulations, separate coded logic for the game runtime, A/B testing wired up in another tool, analytics ending up in some other place.

The engineering cost is real, and so is the opportunity cost: every hour a senior engineer spends maintaining simulation infrastructure, the glue code between all the tools, another change in the logic implementation, is an hour they're not spending on the game itself.

Where it fits. Until recently, this was the only serious option for studios operating at scale. It's still a valid path if you have a genuinely unusual economy. But for most studios, including the biggest ones, the question is shifting from "should we build this in-house?" to "should we keep maintaining what we built?"

Approach 4: An integrated engine (what we think is coming next)

The pattern across Approaches 1–3 is that the design lives somewhere different from the game. A spreadsheet isn't the game. A Machinations graph isn't the game. A Python simulator isn't the game.

So every iteration requires a handoff, a translation, a re-implementation, and every handoff is a place where time is lost and meaning is lost.

This is the assumption worth questioning.

What if the economy you designed was the same economy that you simulated, and was the same economy that ran live and was the same economy you analyzed? One artifact, four uses. No handoffs. No drift.

That's the bet we're making with Leap. A game designer builds the economy visually. The same logic simulates against thousands of virtual players. The same logic deploys to production: no engineering re-implementation. The same logic emits analytics that map back to the original design, so you can compare what you expected to what actually happened. When you want to change a drop rate because a LiveOps event is underperforming, you change it in one place, and it's live.

Who it's for. Anywhere a studio wants designers in the driver's seat and doesn't want to pay the tax of maintaining simulation and runtime as separate codebases. That's a small indie team that can't afford a four-engineer economy stack. It's a mid-size studio that wants to iterate in hours instead of months. And increasingly, it's also the large studios operating top-grossing live-service games, who are starting to ask a harder question: why are we maintaining all this infrastructure ourselves?

The answer, for a long time, was that nothing off-the-shelf could match what a custom stack could do. That assumption is worth revisiting. A well-built integrated engine can give a AAA team the same depth of control they built in-house, without the headcount cost, without the drift between simulation and production, and with design and engineering working on the same artifact instead of translating between them. The studios that figure this out early will spend their engineering budget on the game, not on the tooling around it.

Where it's still new. This category is young, and honesty matters here. Machinations is more mature as a pure visual simulator. PlayFab has well tested, traditional backend features, but no simulation nor logic. The integrated approach is a bet that over the next few years, studios of every size, from indies to the teams running the highest-grossing live-service titles on the planet, will want one system that handles design, simulation, runtime, and analytics as a single workflow. We think that bet is right. But it's still a bet, and the category is being built in real time.

Where it fits. If you're starting a new game today and you want to move fast, this is the path. If you're running an established live-service title and your custom stack is starting to feel more like a burden than an advantage, it's worth a serious look. The ceiling isn't studio size, it's whether the tool can handle the complexity your economy actually has. That's a technical question, not a philosophical one, and it's the right question to ask of any vendor, including us.

How to choose

If you take only one thing from this post, it's this: the right approach isn't the most powerful one, it's the one that matches how much iteration you actually need to do.

• Shipping a small premium game with a static economy? A spreadsheet is fine to start with, but if you want a deeper understanding of your economy and iterate faster might be worth considering an integrated engine.
• Designing a systemic economy for the first time and want to learn? Machinations is the best teacher in the industry now.
• Running an established live-service title on a custom stack that's working? Don't rebuild it on a whim, but do keep an honest eye on what it's costing you in engineering time versus what newer tools can now do. A gradual migration to an integrated engine might be worth a lot in the long run.
• Starting a new project and want to move fast without giving up depth? Integrated engines are the direction the industry is heading, for teams of every size.

Whichever path you pick, the real win isn't the tool. It's the habit: simulate before you ship, and keep simulating after you ship. The studios that treat economy balancing as a one-time pre-launch activity are the studios that spend the first six months after launch in emergency re-balancing mode. The studios that treat it as a continuous discipline, whether they're a five-person indie or a thousand-person AAA, are the ones whose games are still growing two years in.

---

Leap is an integrated engine for game economy design, simulation, and LiveOps. If you want to see what the integrated approach looks like in practice, join the waitlist.

Join the Leap waitlist and see integrated economy simulation in action

Originally published at theleap.dev/blog.