Determinism
Same inputs, same simulation.
Same inputs, same simulation on Windows and Linux, checked every night. So a recorded session replays with the same result, on Windows or on Linux.
What runs every night
- 01
Game scenes
Six scenes, among them an arena with 200 physics bodies, a crowd of characters and four sample games driven by recorded and scripted input. Each runs 600 steps on Windows and on Linux.
- 02
Layer by layer
The simulation state is hashed at the first step and every 60 steps after it, split into world, physics, controllers, characters, crowds and scripts.
- 03
Physics stress scenes
Five physics-only scenes, from piles of bodies to large arenas, hashed on both platforms the same way.
- 04
A difference is named
If the two ever disagree, the check names the scene, the step and the layer that differ, and the team is alerted that night.
What it means for training
Debriefs that hold up
Save a session's input and replay it later, from any camera: the trainee sees what really happened, not an approximation.
Same run, same outcome
Run a recorded session again, on Windows or on Linux, and the simulation ends the same way, so whatever you measure from it holds.
Check every update
After an engine update, replay your recorded sessions to check that each scenario still plays out the same way before trainees use it.
The fine print
- Both builds are checked on one PC today: Windows native and Linux beside it. Agreement across different machines and processors is the next check, not a claim yet.
- It checks the simulation, not the picture. Rendered frames are checked separately and are not claimed to match across graphics cards.
- It does not compare runs with different thread counts. The physics stress scenes run on one thread.
Your next scenario, running this week.
Start with a pilot, or get the engine and try it yourself.