Pause must truly freeze game state, not just hide the screen

What it is

Pause has two implementation depths: a true pause freezes all game state—timers, physics, AI behaviour, network sync all stop, with the screen showing only a menu overlay; a visual hide merely obscures the screen while the game logic underneath keeps running. Visual hide is nearly always wrong in single-player (the player believes they are safe while their character is being attacked) and is an unavoidable compromise in multiplayer (the server cannot stop the world for one player).

Why it happens

Pause's value promise is "I can safely leave this attention stream"—deal with something real, check a menu, breathe. Only a true pause honours that promise: if the game continues underneath and the player returns to a dead character or collapsed situation, the broken promise costs trust in the pause function and the game itself. True pause requires freezing the whole game loop, and state-snapshot completeness matters: every active system (animation, particles, audio, timers, network heartbeat) must handle pausing—any system left running produces the unsettling "I paused but something is still moving" sensation. Multiplayer's compromise is showing a pause menu client-side while the server runs on—honest design then explicitly states "multiplayer cannot pause" and offers safe exits (safe zone, untargetable state) instead of letting a pseudo-pause manufacture false security.

Where it stops holding

Multiplayer has no true-pause option (the server world cannot stop for one player)—that is unchangeable; what can change is the pseudo-pause's honesty—mark in the menu that the game continues, show risk information (the character may be attacked), and provide safe options rather than false pause comfort. Games with system-clock dependencies (timed levels, live events) need an explicit decision: does the timer pause too (true pause stops it) or keep running (real-world events do not wait)?—the choice should follow the event's nature (gameplay timers pause; real-time events do not) and stay transparent. RPGs with many background systems need per-system pause audits; overlooked background systems (resource regen, status-effect timers) are a classic bug source.

Applying it

• Audit pause completeness: list every active system and confirm each is frozen on pause or explicitly marked as continuing by design.
• In multiplayer, label the pause menu "game still running" with risk information, and provide safe options instead of a false sense of pause.
• Verification: pause for several minutes, then resume and compare game state against the pre-pause snapshot (position, health, timers, NPC behaviour). Any mismatch is an unfrozen system.

Related

• Same group: W5.06.2 Save-point predictability shapes risk-taking · W5.06.3 Auto-save and manual save need distinct UI identity · W5.06.4 Deep menu hierarchies make common settings expensive
• Nearby: I1.03 Pausing and interruption recovery · I2.02 Timers and time-limited mechanics · W5.06 Menus, pausing, and saving
• Search terms: pause menu · game state · multiplayer pause · game loop