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

1.00safter the restart

CONTROL

Fresh run

1 virtual timer
CUMULATIVE SPAWNS 0SCORE 0HITS 0

AFTER A TWO-SECOND WARMUP

Restarted run

2 virtual timers
CUMULATIVE SPAWNS 0SCORE 0HITS 0
T + 1.00 s
0 s5 s10 s

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.

Cumulative totals
TimeFresh AFresh BRestartedExtra

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.