Game devs explain the tricks involved with letting you pause a game

Post by sebg » Sun, Apr 19, 2026, 3:33 PM UTC

drzaiusx11 wrote: post #138

mjlee wrote: post #128

Earlier quoted context omitted.

I used to be a professional sailor, and love finding nautical terminology in programming. At sea dead reckoning is navigating using the speed and direction of the ship, and adding tide and wind to calculate a fix based on the last known position. The term dates back to the 1600s. It is fun to point at a chart and confidently state “We’re here! I reckon...”

There's a book I read a while back named "Longitude" that maps the storied quest in science to improve upon dead reckoning by devising greater and greater accuracy in time pieces used on ships. Iirc it was a fun read if anyone else finds that sort of thing interesting (as I do.)

Post by mjlee » Sun, Apr 19, 2026, 3:34 PM UTC

drzaiusx11 wrote: post #138

mjlee wrote: post #128

Earlier quoted context omitted.

I used to be a professional sailor, and love finding nautical terminology in programming. At sea dead reckoning is navigating using the speed and direction of the ship, and adding tide and wind to calculate a fix based on the last known position. The term dates back to the 1600s. It is fun to point at a chart and confidently state “We’re here! I reckon...”

There's a book I read a while back named "Longitude" that maps the storied quest in science to improve upon dead reckoning by devising greater and greater accuracy in time pieces used on ships. Iirc it was a fun read if anyone else finds that sort of thing interesting (as I do.)

Post by Jare » Sun, Apr 19, 2026, 3:38 PM UTC

10000truths wrote: post #147

cubefox wrote: post #105

Earlier quoted context omitted.

An interesting thing about the a lockstep solution which only considers inputs is that any RNG required in the game must be generated from the input history somehow. This could lead to players being able to manipulate their luck with extremely precise inputs.

> a lockstep solution which only considers inputs Nothing stops you from adding a PRNG seed parameter to initialize your deterministic game engine.

Post by Rohansi » Sun, Apr 19, 2026, 3:43 PM UTC

syspec wrote: post #151

ndepoel wrote: post #51

Earlier quoted context omitted.

It wasn't really that much to do with determinism. Quake uses a client-server network model all the time, even when you're only playing a local single-player game. What the demo recording system does is capture all of the network packets that are being sent from the server to the client. When playing back a demo, all the game has to do is run a client and replay the packets that it originally received from the server…

"All you have the game has to do is run the client and replay the packets" --- Sure after you build a sophisticated the system that supports that, then you "just" do as you described. EASY!

Post by glaslong » Sun, Apr 19, 2026, 3:47 PM UTC

qwery wrote: post #102

Sharlin wrote: post #80

I would expect pausing to bring a game’s CPU/GPU usage down to near-zero, which won’t happen if the game keeps redundantly rendering the exact same frame. A game engine can optimize this by special casing time scale zero to simply render a single textured quad under the pause menu (which is probably what one of the commenters in TFA referred to).

You would expect it to do that, and I'd say that's a desirable behaviour, but it's not really that simple and you certainly don't get that for free. Typically any of the common modern engines with a "time scale" variable like that are not at all optimising anything in that way. It's likely that the physics engine won't be stepped with a zero delta time, which will reduce the time spent on physics, but that's more of…