The most common mistake in simulation projects is spending the budget on visual realism. Realism helps, but it is not what makes training work. What makes training work is repeated practice at the decisions the trainee will actually have to make, with consequences that follow from those decisions.
Fidelity Is a Means, Not a Goal
There is a level of realism below which the trainee cannot engage, and above which additional detail adds cost without adding learning. That threshold depends entirely on what is being taught. Learning a procedure needs correct sequence, correct controls and correct system responses — not photoreal surfaces. Learning to recognize a physical fault may genuinely require high visual fidelity, because the visual cue is the skill.
The productive question is never “how realistic can we make it?” but “what must be realistic for this specific skill to transfer, and what can be simplified without harming it?”
Design Around Decisions
Start by listing the decisions the trainee must make and the cues they must notice. Everything in the simulation should exist to support practising those. A scenario in which the trainee follows instructions and watches an outcome is a video with extra steps; a scenario in which they choose, and the system responds differently depending on what they chose, is training.
This is also what makes simulation worth its cost relative to a manual or a classroom — the ability to practise a decision repeatedly, including the dangerous, rare and expensive versions.
Let Failure Happen
Simulations that prevent mistakes teach less than simulations that allow them and show the consequence. The value of a simulator is precisely that failure is safe. Trainees who have made the mistake once, seen what followed, and repeated the scenario retain it in a way that reading a warning does not produce.
Build Debrief In From the Start
The learning consolidates in the review, not in the run. Capture what the trainee did, when, and what the system was doing at the time, then present it in a form an instructor can walk through afterwards. Retrofitting instrumentation onto a finished simulation is far more expensive than designing it in.
Scope Realistically
- Content is the bulk of the cost. The engine is a one-off; scenarios are ongoing. A simulator with three scenarios gets used three times.
- Decide who authors new scenarios. If every scenario needs a developer, the library stops growing the moment the project ends. Authoring tools cost more upfront and are usually worth it.
- Match the hardware to the audience. A VR headset that has to be booked, charged and sanitized may be used less than a desktop version that runs on the laptop the trainee already has.
- Plan for change. Equipment, procedures and regulations change; a simulator that cannot be updated becomes wrong rather than merely dated.
Measure Whether It Worked
Decide before you build what evidence would show the training succeeded: time to competence, error rates in assessment, incident rates, reduced instructor hours. Instrument for it from the beginning. “Trainees liked it” is worth knowing and is not the same as “it worked” — and without the second, funding the next version is a much harder conversation.
Related service: Simulation and training software development
Behavioral Fidelity Is a Separate Axis From Visual Fidelity
Two simulators can look identical and teach differently, because the model underneath is a different kind of thing. One is a state machine: an author listed the states, the transitions between them and the conditions that fire each transition, so the system does what someone anticipated and nothing else. The other is a computed model, where pressures, flows, temperatures, permissions or timers are calculated and the display is a readout of that calculation, so the system can arrive at a combination nobody wrote down.
State machines break the moment the training goal shifts from execution to diagnosis. A trainee learning a checklist is well served by a scripted path, because the correct sequence is the content. A trainee learning to work out why a reading is wrong needs that reading to be produced by something, since the skill is reasoning backward from symptom to cause. The question that separates the two in a demo is short: ask what happens when the trainee acts in an order nobody planned for.
The middle option is usually the right one, and it is chosen per subsystem rather than per project. The one or two subsystems the trainee reasons about get a computed model, and everything else stays scripted, because a panel that only ever gets operated in one order costs a fraction of a simulated one and teaches the same thing. What decides which subsystems earn the computed treatment:
- Whether its failures interact. Independent faults can be listed; faults that combine into a state no one listed cannot.
- How many distinct states the trainee can legitimately leave it in, and whether a later step in the scenario has to read those states back.
- Whether timing is part of the skill. A pressure that builds over minutes, or an alarm cascade that fires in seconds, is a behavior rather than a screen.
- Who maintains it after the real equipment changes. A computed model tracks a specification; a scripted one is re-authored scenario by scenario.
Scenario Authoring Is a Data Problem Before It Is a Tool Problem
The reason a new scenario needs a developer is usually structural rather than a matter of difficulty: the scenario lives inside the build. Its starting conditions are set in a scene, its events are wired into prefabs or Blueprints, and its pass conditions are written in code, so changing any of them means a recompile, a new build and a redeployment to every headset or workstation. Authoring becomes possible at the point the scenario leaves the build, with initial state, injected events, timing, scoring rules and debrief markers held in data files the runtime loads at startup.
That move has a prerequisite most projects discover late. Every object a scenario can refer to needs a stable identifier that survives an artist renaming it or moving it in the hierarchy, every fault needs a name, and every measured outcome needs a definition that does not quietly change meaning between builds. Once scenario files version independently of the application, you also have to decide what a new build does with a file written for an older one: refuse it with a readable message, or migrate it on load.
Validation matters as much as the editor. A scenario referencing a valve that no longer exists should fail at load with the file and field named, not halfway through a session in front of a class. These are the parts that separate a simulator a subject matter expert can extend from one that only looks extensible:
- Stable identifiers for every referenced entity, assigned once, not derived from display names or scene paths.
- A published set of injectable events, each with parameters and a documented effect, instead of open script hooks.
- Scoring rules stored with the scenario, so changing what counts as correct does not require a build.
- Load time validation that names the file and the field it rejected.
- A defined behavior for the case where scenario data and application version do not match.
What a Session Record Has to Contain to Be Worth Reviewing
The requirement that breaks first is the clock. Trainee input and system state are usually produced by different parts of the application, and if each carries its own timestamp, nobody can say afterward whether the operator acted before or after the alarm. One monotonic clock, stamped at the point each event is generated, is what makes the two tracks alignable later; wall clock time is a poor substitute, since it can step backward when the machine synchronizes.
Replay is the stronger form of review and it constrains the whole build. Reconstructing a run from its log requires the simulation to be deterministic: a fixed timestep for the model, seeded random number generation, and no state that depends on frame rate or on how long a frame took. In Unity that means model updates belong in FixedUpdate rather than Update; in Unreal it means physics substepping and not feeding delta time into anything that changes state. Where determinism is not affordable, video capture with a searchable event track is the honest fallback: it serves an instructor and produces nothing that can be aggregated across a cohort.
Size follows from what you sample. A log of state changes, written as newline delimited JSON, keeps a full session in kilobytes and stays queryable across trainees, while per frame sampling of head pose, hand pose or a continuous gauge is orders of magnitude larger and is worth it only for the signals a specific question depends on, at a stated rate rather than every frame. Session records also raise questions that are far cheaper to settle before the first cohort than after:
- Who can read a record: the instructor, the trainee, the trainee's manager.
- Whether a given run is practice or assessment, and whether the trainee is told which before it starts.
- How long records are kept, and whether they are deleted with the person or retained as anonymized aggregates.
- Whether records may leave the site at all, which decides where the receiving system can be hosted.
- What is stored for a session that crashed or was abandoned partway through a scenario.
Frame Budget and Comfort Decide Whether a Headset Session Finishes
On standalone headsets the frame rate is a constraint, not a quality setting. A 72 Hz display leaves about 13.9 ms for an entire frame and 90 Hz leaves about 11.1 ms, and the simulation step, both eyes rendered and the compositor's own work all have to fit inside that. Missing the budget does not merely look worse: dropped frames and late head pose updates are a direct cause of discomfort, and a trainee who removes the headset partway has not completed the scenario.
Most discomfort is a locomotion problem rather than a graphics one. It comes from moving the camera in ways the trainee's balance system disagrees with, so scenarios that fit inside the tracked space and let the trainee walk the real distance avoid the issue entirely. Where the modeled space is larger than the room, teleport and snap turn are the conservative choices while smooth locomotion and smooth turning spend tolerance, and both belong in a per trainee setting rather than being fixed for everyone at build time.
The budget is also spent differently on mobile class GPUs than on a workstation, so a build that runs well tethered to a PC is not evidence that the standalone version will. These are the levers that usually decide whether a headset build holds its frame time:
- Forward rendering with MSAA on standalone hardware; deferred rendering is a tethered PC choice.
- Single pass instanced stereo, so the scene is submitted once rather than once per eye.
- Draw call and unique material counts, which bind before triangle count does on tile based GPUs.
- Baked lighting and light probes for anything that does not move, instead of realtime lights and shadows.
- Fixed foveated rendering, which lowers shading rate at the periphery where the optics are soft anyway.
- A fixed timestep model decoupled from the render loop, with interpolation for display, so a heavy frame changes what is drawn and not what the system did.
When a Full Simulation Is Not the Right Tool
If the bottleneck is knowledge recall rather than judgment, a searchable reference, a job aid or a checklist outperforms a simulator at a small fraction of the cost. If the real equipment is available, idle, and safe to make mistakes on, practice on the equipment beats practice on a model of it, because the model is always missing something the real thing does.
The cases worth arguing about sit between those two: the equipment exists but is in production, the decision matters but the failure is cheap to recover from, the skill is partly spatial and partly procedural. A part task build settles this faster than a debate. One scenario covering one subsystem, run with real trainees and an instructor watching, shows whether the decisions being practiced are the ones people actually get wrong.
The signals below usually mean the money buys more somewhere else:
- Nobody can yet say which decisions people get wrong. Simulation is expensive to aim, so an observation pass on the real work comes first.
- The procedure is still being argued over. Building against a specification mid revision trains the version that loses the argument, and the same build is cheaper once it settles.
- The task is performed once, under supervision, by people who will not repeat it. Repetition is what a simulator buys, and here there is nobody to spend it on.
- The real workplace already lets the mistake happen and shows the result immediately, so the safe failure a simulator would have to construct is already available at no cost.
Frequently Asked Questions
What counts as a training simulation, and what does not?
A training simulation is a model that changes state in response to what the trainee does and can reach states nobody wrote by hand. The neighbor it gets confused with is a digital twin, which mirrors one specific real installation, is usually fed by live or historical data from that asset, and exists to monitor or predict it. A training simulation carries no such obligation. It only has to be right about the behaviors the trainee must learn and can be simplified, or plainly wrong, everywhere else, which is why a twin is not a cheap route to a trainer and a trainer is not a cheap route to a twin.
Which engine does a training simulation get built in, and does the choice matter?
Unity, Unreal Engine and Godot all ship what a trainer needs: a scene system, physics, animation and OpenXR support for headsets. The differences that show up in practice are the authoring language and the licensing. Unreal pairs C++ with Blueprints, which lets staff who do not write C++ wire logic visually; Unity uses C# and has broad device and middleware coverage on standalone headsets; Godot is MIT licensed with no fee attached to shipping, uses GDScript or C#, and has a smaller enterprise XR ecosystem to draw on. Commercial engine terms change and differ between game and non game use, so they should be read at the time of the decision rather than assumed.
What has to exist before scenario development can start?
Three things, and the decision and cue list described above is only the first. The second is access to the people who know the system's unusual states, because the rare failures, the ambiguous readings and the workarounds crews actually use are rarely written down anywhere and are exactly what scenarios are made of. The third is reference material for the thing being modeled: panel layouts and photographs, alarm lists, control ranges, current procedure documents, and where possible a recording of the task being performed. The item most often missing is an agreed definition of correct performance. Without it there is nothing for the simulation to score, and the debrief falls back to whatever the instructor happened to notice.
How does a simulator report results into an existing LMS?
Through one of three standards, and the choice constrains what you can ask later. SCORM 1.2 or 2004 runs content in a browser frame and reports a small fixed set of values, essentially completion, a score and time, which is enough for a compliance record and nothing more. xAPI posts statements to a Learning Record Store over HTTP, so per decision detail such as which cue was missed at which step survives into reporting. cmi5 sits on top of xAPI and defines how an LMS launches content that does not run in a browser, which is the case that matters for a standalone headset build or a native desktop application.
How does a headset build actually reach the trainees' devices?
Standalone headsets are managed devices, so distribution normally goes through a device management console rather than a consumer store: the build is uploaded once, assigned to a device group, and installed on enrolled headsets. That assumes the headsets are enrolled and owned by the organization, and that someone holds the account the console belongs to. A tethered PC build is an ordinary application install and follows whatever software deployment path the site already uses. Decide early whether sessions must run with no network, since offline operation changes how results reach the LMS: records queue on the device and upload when it reconnects.
What happens when a trainee does something nobody specified?
Someone has to decide, and if nobody does, the engine decides by default. A wrong action that nobody specified becomes either a blocked control or a generic error, and both of those teach the trainee that the simulation, not the system, is what they are operating. The cheapest correction is a documented fallback rule per subsystem: an unspecified input either does nothing and is logged, or produces the response the real equipment would give, with the rule written down rather than left to whoever implements the panel. Reviewing the log of unspecified inputs after a pilot cohort is also the fastest way to find where the model needs to be broader.
Does the training need to be in VR?
The test is whether the skill lives in the body. If the trainee has to reach, look around, position themselves relative to equipment, or find something by where it is rather than what it is called, a headset is doing work a screen cannot. If the decisions are read off a display and made with a keyboard or a mouse, a desktop or browser build carries the same decisions without headset hardware. VR does produce one thing a desktop build cannot: where the trainee looked, in what order, and what their hands did before they committed, which is often the clearest evidence of whether a cue was noticed at all.