Bug Tracking for Time Loop Games

A time loop game runs the same day, level or cycle over and over, and its entire design rests on a careful split: the world resets to a known starting state each loop, but certain things carry over, the player's knowledge, key items, story flags, and progress markers. That boundary between what resets and what persists is the most bug-prone surface in the genre. A flag that should have reset but leaked makes the world inconsistent, and a flag that should have persisted but got wiped erases the player's hard-won progress. This post is about tracking the bugs that live on that boundary.

The reset boundary is the whole design

Every time loop game maintains two categories of state: ephemeral state that the reset must wipe back to a pristine starting condition, and persistent state that must survive the reset intact. The reset logic is the single most important and most fragile piece of code in the game, because it has to correctly classify every piece of state into one bucket or the other. Miss a field and you get a leak; over-zealously clear a field and you wipe progress. As the game grows and new systems are added, every new piece of state is a new decision about which side of the boundary it belongs on, and any miss is a bug.

The insidious thing is that reset bugs are often invisible within a single loop and only manifest on a later one. A door that was opened in loop three should be closed again at the start of loop four, but if the reset misses it, the world is subtly wrong in a way the player may not connect to the door they opened. By the time they report that the world feels broken, the originating action is several loops back. To debug this you need to capture the full persistent state and the loop number, so you can compare what survived against what the reset contract says should have survived.

State that leaks across loops

A leak is when ephemeral state survives a reset it should not. An NPC that was killed stays dead into the next loop, a consumed item stays consumed, a triggered event does not re-arm. Leaks corrupt the puzzle logic of a loop game, because the entire genre depends on the player being able to rely on a consistent fresh start each cycle. Leaks usually come from state stored in the wrong place, a static field, a singleton, a cache that the reset routine does not know to clear. They are hard to spot because the leaked value is often plausible, just stale.

Finding leaks requires comparing the world state at the start of a loop against the canonical pristine state. Capture a serialized snapshot of the resettable world at loop start, and a diff against the known baseline reveals exactly which fields failed to reset. A report that the world is wrong is hopeless on its own, but a start-of-loop snapshot showing a flag that should be false sitting true points directly at the field the reset missed. Treat any state that survives into a fresh loop and should not as a leak to be traced back to wherever it is being stored outside the reset's reach.

Persistence that should survive but does not

The mirror failure is lost persistence: state that the player earned and that should carry across loops gets wiped by an over-broad reset. A key item the design says persists vanishes, a story flag that unlocks dialogue resets, the loop counter itself gets reset and the player is thrown back to the start of the experience. These are the most painful bugs in the genre because they erase real progress, and in a loop game progress is precious precisely because each cycle costs the player time. A wiped persistent flag can soft-lock the player out of content they already unlocked.

Lost persistence often comes from a reset that clears a whole subsystem rather than surgically resetting only its ephemeral parts, or from a save that does not correctly serialize the persistent set. Capture the persistent flags and items with every report, along with the loop number, so you can see whether a value that should be carried is missing. A snapshot showing a key item the player clearly acquired now absent, on loop seven, tells you the persistence path dropped it. Because these bugs can permanently block progress, they deserve the highest priority and the most careful capture of before-and-after persistent state.

Reproducing across loops

Reproduction in a time loop game means recreating a specific loop on top of a specific accumulated persistent state, which no screenshot conveys. A useful snapshot captures the loop number, the full set of persistent flags and items, a serialized view of the resettable world at the moment of the report, and the recent sequence of actions in the current loop. With that you can load the exact cycle the player was in, with their exact carried-over progress, and step through it. This turns a report about a soft-lock on loop twelve into a deterministic case you can load directly into a test harness.

Categorize reports by which side of the boundary failed, because the player only sees the symptom. Tag them as leak where ephemeral state survived, lost persistence where carried state vanished, loop-count desync, or soft-lock where the player is stuck. Once sorted, the clusters point at specific fields and systems: leaks cluster around a particular cached subsystem, lost persistence clusters around a specific item type, soft-locks cluster at a specific loop transition. That structure lets a small team make sense of what is otherwise the most confusing class of bug reports in any genre, because the player's sense of time is itself entangled with the bug.

Setting it up with Bugnet

Bugnet's in-game report button can attach a loop game's full boundary state as custom fields: the loop number, the complete set of persistent flags and items, a serialized view of the resettable world, and the recent actions in the current loop. Arm a guard so that a start-of-loop diff against the pristine baseline, or a missing persistent item, flushes a report automatically with that state. If the reset routine panics, the crash report carries a stack trace and device context. A complaint that the world is broken or I lost my item becomes a snapshot showing exactly which flag leaked or which persistent value was dropped.

Occurrence grouping then ranks boundary bugs by reach. Reports of the same flag leaking after a particular action fold into one issue with a count, and lost-persistence reports cluster into a high-severity issue you can filter by the item-type or loop-number custom field, all from one dashboard. The captured persistent state lets you confirm which side of the reset boundary failed without re-walking the player's loops yourself. Instead of triaging the most disorienting bug reports in gaming by intuition, you let the snapshots and the occurrence count point straight at the field the reset misclassified.

Testing the loop contract

Make the reset contract explicit and testable rather than implicit in scattered code. Maintain a declared list of every field that is ephemeral and every field that persists, and write a test that performs a reset and asserts every ephemeral field returned to its baseline while every persistent field was untouched. Run a soak test that loops hundreds of times with randomized actions, diffing the start of each loop against the pristine baseline and asserting that persistent values accumulate correctly. Most loop bugs are introduced when a new system is added without classifying its state, and a contract test catches that the moment it happens.

Treat lost persistence as a release-blocking class, and validate that real saves carrying many loops worth of progress still load all their persistent state through a new build. Keep every reproduced snapshot as a permanent regression test so a fixed leak cannot silently return when a future refactor moves state around. Done well, a time loop game gives players the reliable fresh start and the meaningful carried progress that make the genre magical, and the rare boundary bug that does appear arrives with a snapshot that names exactly which flag fell on the wrong side of the reset.

A loop game is a contract about what resets and what survives. Snapshot both sides of the boundary and the disorienting bugs become diffable.