ONESHOTGEMS

For game developers

Check the paths between game states

Many awkward game bugs happen between stable screens: a start click is accepted twice, a pause menu leaves movement active, or a victory overlay appears while the timer keeps running. A state-transition test names the states, the action that moves between them, and the behavior that should stop or begin at that boundary. This is different from checking each screen in isolation because a screen may look right while hidden input or score logic continues underneath it.

Draw a small state map

Start with only the states that exist today: ready, playing, paused, won, lost. List valid transitions such as ready to playing on Start, playing to paused on Pause, paused to playing on Resume, and playing to lost after a collision. Decide whether won or lost can transition to playing directly or must pass through ready. A tiny map exposes impossible routes before you add more screens or features.

Test duplicate and out-of-state input

Try the same transition twice quickly: double-click Start, press Pause twice, or hit Restart while the win panel is opening. Each state should handle repeated input deliberately instead of creating duplicate timers or overlays. Also press a gameplay key while paused or after losing. Decide whether the action is ignored, queued, or used by a menu, then verify the selected rule.

Questions about testing game state transitions

Which game states should I test first?

Cover the states that block play or end a run: ready, active play, pause, win or loss, and restart. Add intermediate screens when they change available actions.

Should gameplay input work while a pause menu is open?

Choose a rule and test it. Many games ignore movement while paused, but menu navigation may remain active; the important part is a consistent, visible distinction.

Sources and further reading

Report a correction · How these guides are made

Follow your curiosity