Why "realistic" is the wrong goal, which simulation should carry the weight of your game, and what EVE Online and Half-Life 2 got right that a graveyard of canceled projects got wrong.
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.
Here's 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. The inventory weight limit in your favorite RPG 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 care about the distinction? Because simulation is where meaningful play comes from. 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. Outcomes feel earned. Strategies emerge. The world feels operational instead of staged.
The three layers every simulation stands on
Every simulation, from a match-3 economy to a full physics sandbox, rests on three layers. Fail at any one 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 actually 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 spiral into hyperinflation 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 to the player 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 classic 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. Legibility isn't a UI nicety. It's a third of the simulation.
The five types of game simulation
Different systems need different engines. Mixing them up is how games end up with the wrong problems.
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 its own 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.
The designer's first real decision is choosing which simulation carries the weight of the game, and which ones are just support. Skyrim is a narrative game with a physics sim bolted on - and 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 - and 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 trying to balance them against each other.
The Simulator Trap: fidelity is not the goal
The single most common mistake in simulation design, and the one that kills the most projects: 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 moment your simulation adds complexity the player can't feel or use, you're paying CPU cycles for nothing.
The principle worth pinning above your desk: 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 to spend on it, 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?
The graveyard of canceled games is full of titles that simulated weather fronts, full supply chains, and the daily routines of every NPC in the world - and then shipped a game where none of it touched the thing you actually did with your hands.
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.
The architecture is simple: player input feeds a simulation core (pure state and rules), and the core feeds everything else - the presentation layer (VFX, UI, audio), the save system, the networking. The core never knows a frame was rendered.
Do this and you unlock four capabilities that are nearly impossible to retrofit:
Deterministic replays. If the core is pure, you can reproduce any match by re-running the inputs. That's your debugging story and your 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 hacked one. Every competitive game that ships without determinism spends the rest of its life wishing it had it. Every one that bakes it in early gets to build features the others can't.
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 they intervene only when systemic fairness is at risk: an alliance corners a market, an exploit injects billions of ISK into circulation, a new 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, run it against this list:
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 difference matters: the first thing ships, the second thing gets patched for three years.
FAQ
What is a simulation in game design? A computational model that evolves over time according to rules. It doesn't need to be realistic - Mario's jump, crop growth timers, and inventory weight limits are all simulations. Any system with state that changes based on rules qualifies.
What are the main types of simulation in games? Five: physics (tactile interaction), agent-based (believable NPCs), economic (strategic planning), narrative (reactive storytelling), and networked (shared reality across players). Each has a distinct failure mode, and most games should pick one to carry the design and treat the rest as support.
How realistic should a game simulation be? Only as realistic as the player's decisions require. Increase fidelity when it gives players more interesting choices; anything past that point is CPU cost with no gameplay return. SimCity 4 shipped statistical abstractions instead of individual citizens for exactly this reason.
Why does determinism matter in game simulations? Deterministic simulations produce identical outcomes from identical inputs, which enables reliable replays, stable netcode, anti-cheat verification, and reproducible bug reports. It's nearly impossible to retrofit, so it has to be an early architectural decision.
The takeaway
Simulation is a dialogue between rules and curiosity. The rules are yours; the curiosity belongs to your players. The best simulations reward that curiosity with systemic answers instead of scripted ones.
So: pick the one simulation that carries your game's weight. Make it legible enough that players can reason about it. Decouple it from the screen so you can test it at speed. Log it so you can balance it. And resist the fidelity trap at every step. Do that, and your world doesn't just look alive - it is alive, quietly running its rules in the background, answering every player choice with logic that was there all along, waiting to be found.
Itembase lets you build your game economy as a node graph and stress-test it before you write a line of code - because you can't balance what you can't measure. Try it at itembase.dev/sim