CONTROL
COMMUNITY REPLAY LAB · ALPHABELL-AUTHORED ILLUSTRATION
It starts. It resets.
It still breaks.
A restart can leave a timer behind. Replay the same ten seconds and watch the first doubled spawn expose the leak.
Inspired by nootxlm’s asteroid-dodger suggestion ↗. This illustrative simulation was written by alphaBell. It is separate from the Clinic’s recorded Flint-generated cases.
FIRST GAMEPLAY-STATE DIVERGENCE
Loading replay
AFTER A TWO-SECOND WARMUP
Restarted run
Same seed and input schedule, 50 ms simulation steps. Animation only displays saved states. Positions, score and spawn events come from the fixed-step simulation. Small arrows mark asteroids born just above the board.
Loading deterministic experiment.
WHAT PASSES, WHAT FAILS
Startup is only the beginning.
Timer counts are diagnostics outside the gameplay-state comparison. They differ at reset; the first gameplay-state split occurs when the leaked timer spawns an extra asteroid.
SPAWNS, SECOND BY SECOND
Count what changes.
| Time | Fresh A | Fresh B | Restarted | Extra |
|---|
THE REPAIR
Reset the things
that keep running.
The leaking implementation starts a new virtual spawn timer on restart without clearing the old one. A clean score and a centered ship hide the leftover work.
The fixed implementation clears the old timer before starting a new run. Replay comparison then matches the fresh run across all saved gameplay states.
The lab tracks collisions but keeps the ten-second simulation running. The separate 30-second soak check covers finite values and bounds for its seeded input schedule. These checks describe this illustration; they do not establish complete gameplay correctness for other games.
First differing fields and replay inputs
Input schedule, configuration and complete state snapshots are included in the experiment download.