Ludo Atlas · Genre Handbooks · Immersive Sim¶

Genre Handbooks · Volume 4. Positioning: the genre that makes the "network of interacting systems" its primary content. Players do not use the solutions on a menu; they improvise plans by combining the systems already present in the scene — the author builds the rules and the stage, and the specific solution is generated by the player. Companions: Game Design Handbook (core loops and number tables) · Level Design Handbook (sandbox space and guidance) · Programming Handbook (system architecture and AI) · Case Studies (case-breakdown methods). This page carries no external links; benchmark titles are widely known works only, and the figures here are typical magnitudes — calibrate them against measurements in your own project.

1. Positioning and Core Loop¶

In one line: immersive sim is the genre that makes "one mission, many solutions" the content itself. Its freedom is not granted by the plot but by the rules: the world is assembled from a handful of systems that can act on one another, the player's imagination combines them into a plan, and the game has exactly one duty — to respond coherently.

The core loop, written as a verb ring:

observe (space, objects and people can all be used) → conceive a plan → execute by combining tools (abilities, items, physics, dialogue) → the systems produce chain reactions → deal with the outcome, or switch plans and try again

The biggest difference from other genres is the middle step: there is no "correct answer" button, only a set of rules that make sense. Three preconditions must hold: the systems must speak one common language (§3.1), the space must stand up to being messed with (§3.2), and failure must become a transition rather than a reload (§3.3). If any one fails, the world degrades from "a playable sandbox" to "scenery plus staged performance", and the player's creativity dies on the spot.

Drawing boundaries against neighboring genres:

Neighboring genre	The boundary
Stealth	Stealth's systems serve only "not being seen", and the Stealth Handbook guarantees two main routes as a floor — bypass and deal with; immersive sim sets no default solution, and stealth is just one item in the toolbox.
Action shooter	In shooters, winning and losing happens in the hands; in immersive sims it often happens before contact — reconnaissance, preparation and route planning dominate, and combat is only one option.
Puzzle	Puzzle answers are fixed by the designer; immersive sim answers are improvised by the player from live systems, and the same puzzle may be solved differently every time.
Open world	The open world trades area for freedom; the immersive sim trades density for freedom — one building you can turn inside out beats a vast empty map.
Role-playing	RPG freedom hangs on stats, skill trees and dialogue options; immersive sim freedom hangs on objects and rules, with stats in a supporting role.

A self-check question: delete the solution the designer had in mind — does the same mission still have other ways through? If the answer is no, you are making linear levels; if the answer is a whole pile of them, read on.

2. Player Experience Goals and Benchmark Titles¶

Experience goals (in priority order):

Ownership of the plan: every completed mission can be retold as "that was the approach I came up with" — the credit goes to the player.
A believable world: the rules hold everywhere, and nothing a player tries breaks the fiction; "it actually thought of that" is the highest praise this genre can earn.
Stories worth telling: improvised rescues after a plan collapses, winning with dirty tricks — these are not scripted, yet they tell better than scripts.
Gradual mastery: learn single systems first, then their combinations; new players play "can I get through", experienced players play "can I do it beautifully".
Dignified replanning: being spotted or having a plan fail is a transition, not a reload; the world keeps running and the player continues another way.

Negative feelings (any one of these is a red light): a master key (one solution that beats every mission); cardboard scenery (everything that looks usable is just a texture); manual dependence (unplayable without reading the tutorial); rules on a whim (the same action works this time and not the next); staging that gives itself away (scripts pretending to be systems).

Benchmark titles (play them yourself before breaking them down — videos miss a large amount of system interaction):

Title	What to learn from it
Deus Ex series	The multi-solution space of a mission; modular combinations of abilities, gear and dialogue routes; the path the player chose being written into the story.
Dishonored series	Ability combinations that directly change route planning; levels as three-dimensional puzzle boxes; gameplay consequences written durably into world state.
Prey	High system density inside a single space station; "everything is a tool"; improvised combinations under resource pressure.
System Shock	Scene information entirely interactive (terminals, audio logs); hacking, physics and friend-or-foe relations interlocking; high-density levels inside a sealed facility.
Deathloop	The time loop makes the same systems digestible over and over; "knowledge points" turned into a mission puzzle — trading design for volume.
The Legend of Zelda: Breath of the Wild	Chemical and physical rules unfolded systematically; proof in an open world that emergence can scale.

3. Design Essentials¶

3.1 The Network of Interacting Systems: Draw the Interaction Matrix First¶

"Network of interacting systems" translated into engineering language means: every system knows about the other systems. The method is to lay out every one of the player's tools against every class of object in the world as an interaction matrix, and ask three questions cell by cell: can it act on this? What state does the object end up in? And what does that new state mean for other cells? The tools themselves must combine: abilities stacked on environment, items on items, intelligence on routes — only when two things can be used together is there room to "build your own solution".

Objects carry attribute tags and systems match on tags, rather than hardcoding specific objects:

Tag (examples)	Common carriers	What systems it connects
Flammable	Oil drums, cloth, cardboard boxes	Fire, explosions, startled enemies, doors burned through
Conductive	Puddles, wires, metal floors	Shock abilities, short circuits, light failures, alarms
Carriable	Crates, corpses, fire extinguishers	Physics stacking, blocking doors, throwing, standing on
Hackable	Turrets, cameras, terminals	Information, alarms, turning them friendly, route planning

Three disciplines: one object with many uses takes priority over many objects with one use each (a single wrench that pries, repairs, throws, strikes and conducts beats five items with one use apiece); keep the total number of tools restrained, with core systems held to 3 to 5 (§3.5); prefer fewer cells over hollow ones — every cell written into the matrix must be verifiable by the player in the game.

On the player side, build a restrained, unified "interactable" visual and audio language (material, sheen, outline plus sound) so that what can be played with is evident at a glance; feedback comes in three tiers — light, obvious, destructive — with heavy feedback reserved for heavy consequences.

Acceptance criterion: take one mission to five people who have never read a guide; three or more clearly different solutions means the matrix is provisionally sound; if all five walk the same path, the matrix is sparse — go back and fill in cells.

3.2 The Level Is the Sandbox¶

The minimum configuration of a mission area: one objective, multiple entrances, multiple paths, with each entrance carrying a distinct cost profile (the front gate is heavily guarded; height demands an ability; ducts are filthy but safe; the sewer needs an item). The number of entrances is the number of solutions — leaving only one door turns the sandbox into a corridor.

Space is the stage for the systems, not a backdrop for transitions: every room should let at least two systems have something to say. Combat zones need movable cover and destructibles; offices need terminals and alarms; kitchens need fire and water. Corridors where "this stretch is shooting only" are forbidden.

Verticality and connectivity: rooftops, mezzanines and ventilation ducts are a second map of the same space; paths should be reversible wherever possible, and one-way designs few and conspicuous. Freedom to backtrack equals freedom of approach, and players will forgive one failure for the sake of "trying another way".

Density over area: content budgets are counted in "number of effective interactables per room", not per square kilometer. Halve the area and double each room's interactables, and the experience gets more immersive, not less; a big map dilutes system density into a walking sim.

Checklist: how many entrances are there? Which systems does each route use? Will five players take the same route (they should not)? If the target object is carried away or hidden by the player, does the mission still hold?

3.3 Player Expression and Emergent Stories¶

Designers write the rules; players write the stories. Making stories actually appear takes three things:

Persistent consequences: a smashed door keeps its hole, an alarm that has sounded has sounded, corpses do not vanish into thin air; the world remembers what the player did.
Soft consequences: alert level, NPC attitudes and shifts in mission stage replace the "mission failed" popup; a slip changes the situation, not the verdict.
Tellability: one action can be compressed into a single sentence (who, where, did what, with what result); a process that cannot be told is a process players will not remember.

A toybox and a safe zone: the first stretch of content lets players mess around without punishing experiments; teaching comes from the environment, a safe area to experiment in, and immediate feedback — not from a manual. Players learn to play the systems first, and are examined by the systems later.

Emergence is designed: provide the interfaces between systems (fire, electricity, water, noise, light, motion) and do not hardcode set pieces. The moment you stage a "looks like emergence" moment with scripts, exposure is only a matter of time — and players have long memories for exposure.

Player expression needs outlets: stealth, assault, talking your way through and showy tricks must all have real payoffs and costs, rather than one style alone being blessed by the numbers.

3.4 Combinatorial Explosion: The Test-Cost Ledger¶

With every system added, the verification space does not grow by one — it multiplies. 6 tools against 8 object classes make 48 cells; add a 7th tool and the new cells are not just 8 more — there are also its chains through world state with the old systems (fire burns through a wire, electricity opens a door, the enemy behind the door is startled). Factor in ordering and states as well, and the combination count runs into magnitudes nobody can test through.

The realistic approach is not exhaustive testing but layering:

Promised solutions accepted one by one: every objective keeps a guaranteed minimum of 2 to 3 clear routes (stealth, assault, detour) that must pass reliably — this is the promise made to the player.
High-risk cells first: use telemetry to pick the cells players use most and whose consequences cost the most, and test them in depth; spot-check the obscure cells.
Messing-around tests: have QA break progress with "the dumbest methods": throwing the mission item onto a corpse pile, stacking crates to jam a door, killing everyone in the tutorial, pushing the target NPC off a building.
Automated smoke tests: one standard-action script set per level; after any system change, run the whole level set to prevent regressions.

Cost profiles must spread apart: each solution's expenditure (time, resources, risk, consequences) must be graded; if the gaps are too small, a "universal solution" swallows the other systems and the matrix is devalued on the spot.

One discipline: every new system enlarges the regression checklist for all old levels. A new system whose "what does it multiply with" you cannot answer does not get built yet.

3.5 The Small-Team Simplification: Fewer Systems, Deeper Interaction¶

A system budget of 3 to 4 (for example: movement and stealth, physics carry-and-throw, one ability axis, information and hacking); cut the rest or fold them into existing systems — each extra system doubles the matrix and the test workload.
One object, many uses: spend the budget on multiple uses for the same item rather than on a new item table; item count is cost, use count is content.
Tag reuse: a small set of tags (flammable, conductive, carriable, destructible, hackable) runs through all content; new content comes from new combinations, not old-code changes.
Levels small and dense: 3 to 5 high-density scenes are enough to carry a small title; one building, one station floor, one street beats twenty maps.
AI simple but consistent: enemies with three states (patrol, suspicious, combat) plus readable perception are enough to carry the systems drama; few in number and clearly profiled, the total cost comes in below an action game's.
Integrated feedback: a unified interactable language and sound system is the cheapest amplifier of expression (for visual and audio practice see the Art & Audio Handbook).

One discipline: before any new feature enters the project, state clearly which matrix cells it plugs into; if you cannot, cut it.

4. Technical Essentials¶

The engineering difficulty concentrates in three places: how systems talk to one another, how world state stays consistent, and how systems get verified. None of the following is engine-specific; the complexity of an interacting system comes from "everyone has to talk to everyone", not from any single feature.

System interfaces (tags, events, rules)

Interaction runs on the trio of "tag + event + rule": objects carry attribute tags (flammable, conductive, carriable); systems only emit events (ignite, electrify, noise) and query attributes; a rule table matches in the middle. New content equals new tag combinations, with no changes to old code; write interactions as hardcoded calls between objects instead, and every cell added to the matrix means ten edits.
Rules and parameters are fully data-driven (for number-table methods see the Game Design Handbook) and hot-editable at runtime; balance comes from iteration, and numbers hardcoded in code mean giving up on tuning.
Global world state is managed centrally: doors, alarms, corpses and mission-stage changes are all queryable and serializable, so AI, UI, saves and telemetry reuse the same data; two copies of state each computing their own answers will inevitably fight.

Simulation and AI

Perception and behavior follow the Programming Handbook's general practice: parameterized sight and hearing, explicit state machines, last-known-position and search behavior; the difference is a higher demand for consistency — enemy reactions to systems (hearing an explosion, seeing fire, stepping in water) must plug into the same matrix.
Simulation downgrades: distant AI and physics run at reduced frequency, near ones at full fidelity; the floor for any downgrade is consistent rules — distant calculations may be coarse, but must never give the trick away.
Physics is gameplay parts: carrying, throwing, stacking and holding down buttons all need forgiving detection and anti-stuck design, plus escape hatches (push, jump, kick) — never let players get stuck inside their own plan.
Set performance budgets up front: dynamic objects, destructibles and on-screen AI are all black holes; fix the budget before laying down content, or the only late-game move left is cutting content.

Testability and saves

Debug visualization is infrastructure: AI states, perception cones, noise events, physics resolution and interaction logs all toggleable; add an "interaction matrix board" that shows the most recent trigger record for every cell.
Telemetry records the solutions and systems players actually use, to decide which part of the matrix to lay next; a cell nobody touches is a cell that was never made — either add guidance or delete it.
Automated smoke tests cover each level's standard actions; run the whole level set after any system change to prevent regressions (matching the layered testing in §3.4).
Settle the save strategy early: dynamic world state is abundant, and quicksave/quickload versus checkpoint systems each carry their own testing costs; whichever you choose, loading must be in the seconds range and the world must be self-consistent after a load (AI, objects and mission stage all restored). Deterministic simulation (fixed timestep, controlled randomness) makes replay and debugging much cheaper.

5. Content Volume and Workload Reference¶

The following are typical magnitudes for projects of this kind, for scoping estimates; not a commitment.

Project form	Content volume	Timeline	Notes
Systems prototype	1 room, 3 systems	4–6 weeks	Whitebox; validates only the interaction matrix and multiple solutions
Small complete title	3–5 high-density scenes	1–2 years	Indie-team scale, a single ability axis
Typical mid-sized title	6–10 scenes	2–4 years	Multiple ability sets, a story layer and multi-solution verification
Major-studio scale	10+ scenes	4+ years	Systems, levels and testing burning money in parallel

The verification matrix decides the cost: test volume grows multiplicatively with "tool count, object count, existing level count"; every added system regresses every old level. This is the most expensive and most underestimated bill in immersive sim.
Level and system polish time runs higher than for linear projects, commonly two to three times or more; a title's success or failure often becomes clear only after systems freeze.
Reuse is the key to paying back: the same systems with new environments and objectives produce new levels, giving a higher content-reuse rate than linear games; the precondition is a stable matrix and tooling in place.
Scheduling anchors: systems prototype in 4–6 weeks; vertical slice (a stretch of content at ship quality) usually 4–6 months; extrapolate from there by multiplying content volume by a polish factor. Scope out of control is this genre's number one risk — go narrow and deep first, then talk about wide.

6. How to Start the First Prototype¶

The first prototype makes a single room: 3 systems (for example movement and stealth, physics carry-and-throw, one ability or information tool), one objective (get into the room, take what is in the safe, get out) and three entry routes. Complete it in 4–6 weeks, touching no story, no saves, no menus.

Week 1: the system backbone. Lay about 5 object tags and 15+ effective interaction cells into one blocky room; all parameters hot-editable; debug visualization (perception, noise, physics resolution) in place. Ugly is expected.

Week 2: laying out the matrix. Complete the feedback: every cell's effect must be visible and audible; the three routes are supported by different systems (the front gate needs combat or stealth, height needs an ability, the duct needs an item). One enemy may be added.

Week 3: self-testing and messing around. Spend a day playing your own build with "the dumbest methods"; then find 3–5 people who have never played it — no hints, no explanations — and record which systems they used, where they got stuck, and how many times they said "I wanted to do this, but the game would not let me".

Weeks 4–6: revision and review. Process the complaints in one consolidated pass; classify every cell as "promised" or "emergence bonus"; produce a one-page current state of the matrix and the system budget (§3.5).

Success criteria (all observable):

At least 4 of 5 testers use clearly different solutions and can each explain their reasoning.
No more than 1 complaint per person of the "I wanted to do something and the game played dumb" kind.
With art and story turned off, the system interactions are still legible from blocks, tags and sound alone.
Adding a new item or tag takes half a day to plug into the matrix and get working (proof the toolchain is in place).

If the matrix fails acceptance, do not start laying out levels. The foundation of an immersive sim is its interaction systems, and rework on this front is the most expensive bill of all.

7. Common Pitfalls¶

Many systems, no depth: ten items with one correct use each — a matrix so sparse there is no freedom; one object with many uses always takes priority (§3.1).
Scripts impersonating systems: staging and triggers pretending to be multiple solutions — players see through it on the first try, and once trust collapses there is no immersion to speak of.
Levels spread thin like a pancake: area used as content dilutes interactable density and bankrupts the "everything can be interacted with" promise; small, dense and turnable upside down is the right shape (§3.2).
One default solution dominating: combat or a single ability beats everything and the rest of the systems become decoration; every system needs the scenario where it is the best deal, and cost profiles must spread apart (§3.4).
Matrix not maintained: water conducts electricity, but the new weapon that splashes water gets no reaction; before anything new enters the project, update the matrix first, then write the feature.
Inconsistent rules: the same action works in this level and not in that one; system credibility comes from consistency, and "why doesn't it work this time" is a common source of bad reviews.
Testing only the intended route: the game collapses the moment players mess around; messing-around tests, high-risk cell spot checks and smoke regression are mandatory, not bonus points (§3.4).
Saves and reloads failing: a complex world that will not save, and loads that give the trick away (AI resets, objects vanish, mission state scrambles); settle the save strategy early and test it early (§4).
No way in: freedom so total that players do not know what to do; you need clear short-term goals, a safe zone for experiments, and an opening that teaches the systems to the player.
A small team coveting major-studio scale: wanting it all, ending up with half-finished everything; cutting systems to protect depth is always the safest cut in immersive sim (§3.5).