Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

kotaku.com

Post reply on HN
Print view View original

141–150 of 273 posts

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

#141

Post by zaptheimpaler »

vintermann wrote: post #8

One of the things that impressed me in Quake (the first one) was the demo recording system. The system was deterministic enough that it could record your inputs/the game state and just play them back to get a gameplay video. Especially given that Quake had state of the art graphics at the time, and video playback on computers otherwise was a low-res, resource intensive affair at the time, it was way cool. It always s…

Age of Empires 4 also does this. It's very cool and saves a lot of space, but it does have some significant downsides at least the way its implemented there - you can't rewind replays, and they become unwatchable when the game updates significantly.

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

#142

Post by AlienRobot »

diath wrote: post #76
otikik wrote: post #61

So the simple case is using some sort of state variable: switch(game_state): case(paused): case(gameplay) You still have to be careful about how you implement "gameplay", though. For example if at any point you read the 'system clock' to do time-based stuff like animations or physics, then when you unpause you suddenly will have a couple minutes of advance in a place where you expect fractions of a second.

This is why delta time accumulator is preferred over using clocks, something like this would be best: float accum = 0; while (running) { poll_input(); poll_network(); accum += delta_time; while (accum >= tick_time) { accum -= tick_time; update_ui(tick_time); update_anims(tick_time); if (!paused) { update_entities(tick_time); } } render(); }

This gets bugged if it takes longer than one tick to run an iteration of game loop. Afaik the typical solution is to have a maximum number of iterations that you'll run and reset accum if it exceeds that.

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

#145

Post by shmeeed »

ninkendo wrote: post #116

I’d love to hear about the 2020 release of Microsoft Flight Simulator, which had an “active pause” feature that they hyped as a big innovation for that release. You could pause and switch camera angles and see what was going on, then quickly resume. Pretty much the whole game was still interact-able, but with your plane’s position paused. It was supposed to be a nice user-friendly way to pause while you checked gauge…

I was going to comment on MSFS2020's Active Pause as well. It's a curious implementation, but I always assumed the behaviour was intentional. After all, there's a "regular" pause mode as well.

You gotta learn and understand its quirks, though. As long as your flight state is rock stable (e.g. on Auto Pilot) and/or you're not fiddling with the controls while paused, it's pretty much always worked fine for me.

I've also used its interactivity to my advantage and saved the plane from an otherwise unsaveable flight state, e.g. by gaining airspeed while paused.

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

#146

Post by Keyframe »

bregma wrote: post #83
Keyframe wrote: post #38

Earlier quoted context omitted.

not framerate of rendering but physics running at (its own) fixed frame rate.

I think you mean timestep. The video frames get updated on one timestep (the so-called "frame rate" because it is the rate at which video frames get redrawn, the inverse of its timestep), physics gets updated on a separate timestep, and gameplay or input or network polling can be updated on its own timestep.

pretty much, over the dozen or so game and rendering engines I made over the decades name mutated from tick to timestep to frame (rate) to refresh rate (hz) to tick again.. it doesn't matter as long as every system is decoupled and rendering is unbounded (if hardware/display combo supports it). This needs thinking from day one. Cool stuff you can do then is determinism, you can do independent timers which go forward, halt, backward in time, different speed multipliers over those (so some things run slower, faster, everything goes slower / faster), etc.

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

#147

Post by 10000truths »

cubefox wrote: post #105
vvanders wrote: post #82

Earlier quoted context omitted.

Look into dead reckoning vs lock step for networking. Lockstep requires determinism at the simulation layer, dead reckoning can be much more tolerant of differences and latency. Quake and most action games tend to be dead reckoning (with more modern ones including time rewind and some other neat tricks). Very common that replay/demo uses the network stack of it's present in a game.

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.

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

#148

Post by Aurornis »

effdee wrote: post #144

If your game uses more than 1% CPU and 1% GPU when paused you're doing something wrong. A damn blurred screenshot should not make the GPU consume hundreds of Watts.

Paused game does not equal paused process. It means the gameplay clock has paused.

The rendering loop continues to run. The GUI is immediate mode and is still rendered. In some games visual effects continue to be rendered. If it’s a networked game the network code will continue to run.

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

#149

Post by furyofantares »

alfg wrote: post #139
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…

It's just capturing inputs and replaying them.

That's not true though, is what they're saying. Quake demo files are server-to-client packets, results of the simulation, not client-to-server packets, the inputs.

If you wanted to add random critical hits and random bullet spread based on the pixels in a live feed of a lava lamp cam, clients could still record .dem files and they would still work.

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

#150

Post by henriksoerensen »

TacticalCoder wrote: post #122
vintermann wrote: post #8

One of the things that impressed me in Quake (the first one) was the demo recording system. The system was deterministic enough that it could record your inputs/the game state and just play them back to get a gameplay video. Especially given that Quake had state of the art graphics at the time, and video playback on computers otherwise was a low-res, resource intensive affair at the time, it was way cool. It always s…

> The system was deterministic enough ... I wrote about it here many times over the years but in 1991 I wrote a little DOS game (and I had a publisher and a deal but it never came out and yet it's how my career started but that's another story) and at some point I had an "impossible to find" bug because it was so hard to reproduce. So I modified my game engine to be entirely deterministic: I'd record "random seed + p…

> I had a fully deterministic game engine in 1991 and, funnily enough, a few days ago with the help of Claude Code CLI / Sonnet 4.6 I compiled that old game of mine again (I may put it on a public repo one day): I still had the source files and assets after all those years, but not the tooling anymore (no more MASM / no more linker) so I had to "fight" a bit (for example I had not one but two macros who now clashed with macros/functions used by the assembler: "incbin" and another one I forgot) to be able to compile it again (now using UASM, to compile for DOS but from Linux).

Fun thing - I'm working on modernizing a legacy Fortran / Win32 application to something a bit more modern, and ran into similar issues with toolchain not being available anymore; and further some libraries where source is needed to compile, but only have binaries of the libraries.

Claude Code was amazing creating stubs by looking at function calls used and how, and then getting just enough in place to call existing binaries correctly; and further updating the code to be in alignment with Fortran specs that can compile on existing compilers - but it was a 'fight'.

Post reply on HN