Explain the ending before offering a retry
Show the event that ended the run in terms of the game’s rules: a missed target, exhausted resource or failed objective. If the player can learn from that cause, place the useful information near the retry choice. Avoid a vague “Game Over” alone when the cause is known. Keep the score or other relevant result visible long enough to compare the attempt, but do not force an elaborate recap before another try.
Separate retry from leaving
Give restart and exit different labels, positions or visual treatments so a hurried tap cannot discard a run by mistake. If restarting erases valuable progress, ask for confirmation or provide a reversible step. For an endless score attempt with no persistent progress, a direct retry may be appropriate. Choose the amount of friction according to what will be lost, not according to a generic screen template.
Return to the first decision quickly
A retry should restore a valid initial state: clear temporary effects, reset timers and place the player where the opening rule can be read again. Check that repeated restarts do not duplicate listeners, keep old score values or leave a stuck input active. If the game includes a loading step, show that the request registered. Test failure, retry, early exit and retry again; the second run often reveals state that a fresh launch concealed.
Questions about game restart design
Should restart be one tap?
It can be when the only loss is a short attempt. Add a confirmation or undo when a restart would erase progress the player may reasonably want to keep.
What should reset when a run restarts?
Reset every run-specific value needed for a clean attempt, including active timers, temporary effects and input state. Preserve only progress the design intends to persist.