Spine
Simulation and replay
Sixty ticks a second decide everything, the same way every time; pulses tell the adapter what happened, and it draws the game you see.
- Sheet
- 2 of 18
- Latest release
- v0.42
- As of
- 2026-10-22
Everything in an EngineD game happens to a steady beat. Sixty times a second the simulation takes one tick: it reads what the players pressed, moves every body, settles every shot and decides who lives. Then it reports what happened, and the adapter turns those reports into the pictures and sounds you experience.
- 60
- ticks every second, each exactly as long as the last
- 1
- source of chance, started from a seed
- 5
- ticks at most caught up in one frame, by default
As of 2026-10-22.
Two halves that never mix
The engine is split down the middle. The simulation is the part that decides: where everyone is, what a bullet hit, how much health is left. It never looks at the screen and knows nothing about the game engine it runs inside. The adapter is the part that shows: it draws, plays sound, reads the keyboard and mouse, and runs the physics that only has to look right.
The simulation
- Decides everything that matters to the game
- Moves in fixed ticks, sixty a second
- Same inputs give the same result
- Tested on its own, in a plain test program with no game engine in it
- Never assumes there is only one player
The adapter
- Decides nothing the simulation decides
- Runs as fast as the screen allows
- Draws, sounds, reads input, runs ragdolls and debris
- Smooths the picture between ticks
- Anything it wants done goes in as input for the next tick
That last rule is the important one. Even a button on an in-world screen does not act on its own: pressing it queues a request, and the simulation carries it out inside its next tick, like any other input.
One tick, in order
A tick is a single, complete step of the world. Inside it, the parts of the world take their turns in an order that never changes, and each step sits where it sees the world in the state it needs.
| Step | Why it goes there |
|---|---|
| Lifts first | A body riding a lift is carried before it moves itself, so it never sinks into the floor it stands on. |
| Paused areas early | A game can freeze the enemies and bodies in one part of a level. Everything that might act there needs to know before it does. |
| Props before shooting | A crate due to come back stands up again before anything fires into the space it fills. |
| Players, then the rest | Anything fired this tick was fired by someone who has already had their turn, so it is never a tick late or a tick early. |
| Footprints last of the gore | A foot can step in blood that landed in this very tick. |
Same inputs, same game
The simulation is deterministic: start it the same way and feed it the same presses, and it makes exactly the same decisions, tick for tick. Two things make that possible. Time only ever moves in whole ticks, never in the uneven slices a screen produces. And every bit of chance, from a shotgun's spread to which way a body falls, comes from one generator of random-looking numbers that starts from a known number, the seed.
After any tick the engine can boil the whole world down to a single fingerprint number. Two runs that agree have the same fingerprint; the first tick where they differ is where something went wrong. That gives three things for free:
- Replays that are not recordings of the screen but a full re-run of the game from its inputs.
- Tests that play a situation through and check it ends the same way every time.
- Bug hunts that point at the exact tick where two runs part ways.
Ragdolls, the one exception
When a body dies it goes limp. Its limbs become a ragdoll: linked pieces that fall, fold and slump under physics. That physics belongs to the adapter, which hands it to Unity's physics engine. It is fast and looks right, but it is not exactly repeatable: the same fall can end a little differently on another run or another computer. For a picture that does not matter. It matters as soon as the simulation starts listening to it.
And by default it does listen. The simulation takes three things back from the ragdoll physics, so that what you shoot is what you see:
- Where a lying body's limbs are. A shot at a drawn arm hits that arm, and the elbow you aimed at is the joint that gives way.
- Where a torn-off limb flies. It lands and drips where you saw it land, not a metre away.
- Where a body at rest really lies. If the drawn body slid off somewhere, the simulation's body follows it there.
Limbs that count (the default)
- Shots meet the limbs where they are drawn
- Severed pieces land where you see them land
- A world with ragdolls in it does not replay exactly
Drawn-only limbs
- The ragdoll is decoration; the simulation ignores it
- Shots meet a body in its simulated resting pose
- Replays are exact again, every time
The trade is my call: damage that matches the picture is worth more than exact replays of a room full of corpses. The exception has firm limits. Each body is set to one mode when it dies and keeps it, so one world can hold both kinds. A drawn-only body refuses the physics outright. And the automatic tests that compare fingerprints never run Unity's physics at all, so they stay exact. Watch the names: the drawn-only mode is the repeatable one, and the one with the rougher damage. Things the simulation works out itself, such as a corpse floating in water, replay exactly in either mode.
A door left open for multiplayer
Lockstep and rollback, two of the usual ways to build a multiplayer shooter, both depend on a simulation that gives the same result from the same inputs. EngineD has that already, so a future game could take any of the usual broad approaches without first rebuilding the engine's core.
| Method | In broad strokes | What the repeatable simulation gives it |
|---|---|---|
| Lockstep | Every machine runs the whole game and only the players' presses travel between them | Same presses, same game on every machine; fingerprints catch a machine that drifts |
| Rollback | A machine guesses a distant player's presses, runs ahead, then rewinds and re-runs a few ticks when the real ones arrive | Re-running ticks gives the same answer, so the correction is exact |
| Replays and spectating | Send a seed and a list of presses instead of a video | Already how replays work |
| Checking a player's claims | A server re-runs the presses a player sent and compares the outcome | The re-run must agree, and it does |
Some of the shape is in place already. The simulation never assumes there is only one player: each player brings its own presses every tick, and the adapter draws one player's view and everyone else as bodies. Some things would have to give. Ragdolls would need their drawn-only mode, or their positions shared between machines. A setting that changes the simulation, such as a limit on how much gore stays in the world, would have to match everywhere. And nothing can slow a shared world down for one player, so the weapon wheel, which can slow the game while it is open, would be set to run at full speed; the engine already allows that setting for this reason.
Pulses: how the simulation tells the adapter
When something happens in a tick, the simulation raises a pulse: a short, fixed-shape report such as "a shot was fired from here", "this enemy took 12 damage", or "a lift arrived". There are dozens of kinds, one for each sort of event the adapter must show. Pulses are one-way. The adapter listens and reacts; the simulation never reads them back, so nothing it decides can ever depend on what was drawn or heard.
| Pulse | Raised when | The adapter might |
|---|---|---|
| Shot fired | A shot actually goes off | Flash the muzzle, play the bang, kick the gun |
| Impact | A shot lands on something | Throw sparks or dust, leave a mark |
| Damage | A body loses health, after armour | Play a pained sound, flash the screen |
| Gibbed | A killing blow takes a body apart | Burst the body into pieces |
| Landed | Any body touches down hard enough | Play a thud |
| Lift arrived | A lift reaches a stop | Ring a chime |
Because a pulse may be read after the thing it names has gone, it carries what the adapter needs with it: a blood pulse, for example, already says what colour the blood is and how big the body was.
The host and its views
On the adapter's side, one piece, the host, owns the simulation. Every time the screen is about to draw a frame, the host works out how many ticks are owed since the last one, runs them, hands over their pulses, and lets everything draw. Screens do not tick at sixty: frames arrive when they arrive, sometimes several between ticks, sometimes one after a long stall.
If the computer falls badly behind, the host runs at most five ticks in one frame and lets the rest go. The game briefly slows down instead of trying to catch up and falling further behind each frame; the adapter's own physics is held to the same budget, so the two slow down together.
| Control | What it does | What it leaves alone |
|---|---|---|
| Pause | Stops feeding ticks. Menus pause the game this way, and sound can be silenced with it. | The simulation never learns it was paused |
| Slow motion | Feeds ticks more slowly. Everything on screen, animation and effects included, slows with it. | Each tick is unchanged, so replays still match |
| Personal time | A status can give one character a clock of its own: weapons that cycle faster or slower, a burn that bites at a different pace. | Everyone else's time, and the world clock |
Everything you see of the simulation is a view: the adapter's face for one simulated thing, be it a player, an enemy, a door or a blood stain. Things the level places bring their own view; things the simulation creates during play, such as a dropped item or a corpse, get one from a spawner that watches for them. When a view has to be hit by shots, its hit shape is sized from the simulation's own numbers, never typed in separately, so a bullet lands where the simulation says the body is.
Views also hide the beat. The simulation moves in steps, so the view blends between the last two ticks. When a body climbs a stair, the simulation lifts it in a single tick, and the camera eases that lift over a few frames instead of jumping.
Related sheets
- Life of a shotOne bullet through every system, tick by tick.
- Bodies and collisionThe questions the simulation asks the world.
- Rendering and effectsWhat the adapter draws from the pulses.
- QualityHow the repeatable simulation is put to work in tests.