Restart bugs often appear only after the game has already worked once. A second music track starts, a reward is applied twice, or the player cannot move after returning from a menu. The important question is what survived the transition and who was supposed to reset it.
Consider a fictional arena game where defeating one enemy adds the expected score during the first match but twice that amount after restarting. Follow the score event through object creation, subscription, transition, and cleanup before changing the scoring rule.
/01
Define what restart actually means
Write the exact sequence that reproduces the bug. Restarting a level inside a running player, returning through a menu, and stopping and starting Editor Play mode are different boundaries. Test them separately and record whether the bug requires victory, defeat, pause, or an unfinished animation.
Create a tiny transition record containing the previous scene, next scene, session identifier, and reason for the change. Add temporary diagnostic messages only where they answer a specific question. The arena example needs evidence about how many score events were emitted and how many listeners handled each event, not a dump of every update in the game.
/02
Assign every suspect object a lifetime
List the score service, player, spawner, audio owner, and transition controller. For each, decide whether it belongs to the application, a match, or a scene. Unity’s DontDestroyOnLoad preserves designated objects across scene changes, so inspect those intentional survivors alongside the objects recreated by the new scene.
Compare the number and identity of each owner before and after the transition. A persistent score service plus a newly spawned replacement is a different defect from one service with duplicate listeners. Avoid solving both with a broad object search and deletion routine. Establish which object should exist and which system has authority to create it.
/03
Follow subscriptions and unfinished work
Trace registration and cleanup as a pair. If a scene object subscribes to a longer-lived event source, inspect what removes that subscription when the object stops participating. Check whether pooled objects follow the same path as destroyed objects. A fix for one lifetime may leave the other unchanged.
Also inspect delayed work created before restart: animation completions, queued callbacks, requests, or timers. Give session-owned work a way to recognize that its session ended. In the arena example, an old enemy’s delayed defeat callback should not award points to the next match. Choose cancellation or rejection according to the existing architecture and verify the boundary explicitly.
/04
Separate Editor persistence from runtime persistence
Record the project’s Enter Play Mode settings. Unity documents that disabling domain reload preserves static fields and static event registrations between Play mode sessions. That can explain an Editor-only second-run symptom, but it does not automatically explain a restart inside an already running game.
Reproduce the relevant sequence in a built player before declaring the causes equivalent. If the two environments fail for different reasons, keep separate findings and acceptance checks. Do not change the team’s Editor settings merely to hide a missing reset; make the intended startup and session lifecycle clear in the code that owns it.
/05
Test repeated transitions and interrupted transitions
Repeat the same match-to-menu-to-match route and inspect the owner and listener records at each stable point. Trigger restart while a reward animation is still running, then retry from the normal end screen. The expected result is one legitimate score update for one legitimate event and no contribution from the previous match.
Check adjacent state such as pause, audio, selected controls, and the current save slot. Remove noisy diagnostics after preserving useful evidence and review the final diff for unrelated lifecycle changes. Report the transition paths and environments tested so a future regression has an exact route to reproduce.
Keep this in mind
Key takeaways
- Treat in-game restart, scene transition, and Editor Play mode re-entry as distinct boundaries.
- Track object ownership, event subscriptions, and delayed work across the failing transition.
- Verify repeated and interrupted restarts without changing the intended scoring or session rules.
Sources & further reading
Consult the source documentation for the version and platform you are working with.