Say "simulation" to most players and they picture one of two things: the rigid cockpit of Microsoft Flight Simulator, or a goat ragdolling through a gas station. Neither is what simulation actually means, and the misunderstanding costs real projects real years.
The working definition: a simulation is a computational model that evolves over time according to rules. That's it. The rules don't need to be realistic. Mario's jump arc is a simulation. Stardew Valley's crop growth is a simulation. Your RPG's inventory weight limit is a simulation. The moment you have state that changes over time based on rules, you're simulating something - whether you designed it deliberately or not.
Why the distinction matters: a scripted game tells you what happens. A simulated game lets you discover what happens. That single difference is why Dwarf Fortress has a devoted audience despite looking like a spreadsheet, and why Breath of the Wild gets away with chemistry interactions Nintendo's designers never explicitly planned.
The three layers every simulation stands on
Fail at any one of these and the whole thing sinks.
The model. Your variables (money, health, hunger, friction, morale) and the rules that govern them. This is the math.
The dynamics. What happens when those rules interact at runtime. This is where emergent play lives - and where the interesting bugs live too. You can write every individual rule correctly and still watch your economy hyperinflate because two rules interact in a way you never anticipated. Correct rules do not guarantee correct behavior.
The conceptual model. The player's understanding of the system. This is the layer most teams get wrong. A simulation that works internally but reads as opaque is functionally indistinguishable from random noise. If players can't form a mental model of how the system responds, they can't make interesting decisions inside it - they're just gambling.
The Sims' Plumbob is the proof. That green diamond isn't decoration; it's the conceptual model made visible. Remove it and half the game's appeal evaporates, even though nothing about the underlying simulation changed.
The five types of game simulation
Type- Primary goal - How it dies Example
- Physics - Tactile interaction -Performance cliffs - Half-Life 2
- Agent-based - Believable NPCs - Opacity(unreadable AI)- The Sims
- Economic - Strategic planning - Inflation and exploit loops - Cities: Skylines II
- Narrative- Reactive storytelling - Content cost explosion - Façade
- Networked - Shared reality- Latency and desync- Counter-Strike
Each type has a signature failure. Physics sims die on performance: one too many stacked barrels and the framerate collapses. Agent-based sims die on opacity: if players can't tell why an NPC did something, the "intelligence" reads as a bug. Economic sims die on exploit loops: one infinite money glitch and every price in the game becomes meaningless. Narrative sims die on cost: every branch you actually track doubles the writing budget, which is why most "reactive" games are far less reactive than the marketing claims.
Your first real decision is which simulation carries the weight of the game. Skyrim is a narrative game with a physics sim bolted on - the physics exists mainly so you can put buckets on shopkeepers' heads. That's fine. Half-Life 2 is a physics game with a narrative sim bolted on - the story exists mainly to walk you to the next Gravity Gun puzzle. Also fine. The trouble starts when a team accidentally ships two "main" simulations and spends five years balancing them against each other.
The Simulator Trap
The most common project-killer in simulation design: chasing fidelity for its own sake.
Valve didn't build an accurate fluid simulator for Half-Life 2. They built physics that made Gravity Gun puzzles intuitive. The water in that game would not survive a CFD engineer's review, and it doesn't matter, because the water exists to serve gameplay.
The principle: increase fidelity only when it increases the player's ability to make interesting choices.
SimCity 4 is the honest version of this story. The team tried simulating individual citizens, realized players couldn't perceive the difference, and shipped statistical abstractions instead. Cities: Skylines, years later, does simulate every citizen - because the hardware budget finally existed, and because agents visibly stuck in traffic became gameplay information. Same decision, different era, different correct answer. The question never changes: what does this fidelity buy the player?
Decouple the simulation from the screen
Separate the simulation core from presentation. This is so load-bearing that most engine programmers will fight you in a parking lot about it.
Player Input --> Simulation Core (state + rules) --> Presentation (VFX/UI/audio)
--> Save/Load
--> Networking
The core never knows a frame was rendered. Do this and you unlock four things that are nearly impossible to retrofit:
- Deterministic replays. If the core is pure, you can reproduce any match by re-running the inputs. Debugging story and anti-cheat story in one.
- Headless servers. Pure logic, no wasted rendering cycles.
- Long-horizon economy testing. Run 10,000 simulated years overnight and find out which resource breaks first - before your players do.
- Stress testing. Crank the tick rate to 1000x and watch whether the economy hyperinflates in year 200.
Determinism deserves its own sentence: if inputs are identical, outcomes must match. Otherwise your replays lie, your netcode desyncs, and your anti-cheat can't tell a legitimate play from a hack. Every competitive game that ships without determinism spends the rest of its life wishing it had it.
What EVE Online proves: you can't balance what you can't measure
EVE Online publishes Monthly Economic Reports with charts that look like central bank data - because for EVE's players, the in-game economy is an actual economy. CCP hires real economists. They track inflation, monopolies, and resource flows, and intervene only when systemic fairness is at risk: an alliance corners a market, an exploit injects billions of ISK, an expansion quietly breaks the supply curve of a key material.
The lesson is not "build a massive simulation." Most games can't afford one and don't need one. The lesson is that measurement is not optional. If your game has a simulation worth building, it has data worth logging. Teams that skip this step still learn about their economies - just six months late, from Reddit threads, after the damage is done.
The five-check shipping test
Before you call a simulation done:
- Legible. Can players explain why something happened?
- Controllable. Do players have real levers to alter the system?
- Performant. Does CPU cost scale sanely with complexity?
- Decoupled. Can the sim run headless at 1000x for stress tests?
- Seeded. Can you reproduce any world or bug from a single number?
Five out of five means you have a simulation. Anything less means you have a pile of interconnected code that sometimes produces interesting behavior. The first thing ships. The second thing gets patched for three years.
The takeaway
Simulation is a dialogue between rules and curiosity. The rules are yours; the curiosity belongs to your players. Pick the one simulation that carries your game's weight, make it legible, decouple it from the screen, log it so you can balance it, and resist the fidelity trap at every step.
Originally published on the Itembase blog. Itembase lets you build your game economy as a node graph and stress-test it before you write a line of code.
Top comments (0)