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

81–90 of 273 posts

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

#81

Post by ndepoel »

anonymous_sorry wrote: post #77
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…

I don't see why it makes a difference for this purpose that you're replaying network packets or controller inputs or any other interface to the game engine. The important thing is that there is some well-defined interface. I guess designing for networked multiplayer does probably necessitate that, but if the engine isn't deterministic it still isn't going to work. There was a twitter thread years ago (which appears t…

It does make quite a big difference. The network packets received from the server in Quake will tell you exactly what state the game is in at any point in time. They contain information about the position and state of every entity and their motion, compressed via delta encoding. That means there's very little room for misinterpretation on the client side that would lead to de-sync issues. In fact clients have quite a lot of freedom in how they want to represent said game state, and can for example add animation interpolation to smoothen things out.

The example you mention of demo playback de-syncing when the circumstances slightly change, that is exactly what you get when you only record inputs from the player. Doom actually did this too for its networking model and demo playback system. That relies much more on the engine being deterministic and the runtime environment behaving consistently, because each client that replays those inputs has to run the exact same game simulation, in order for the resulting game states to match.

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

#82

Post by vvanders »

anonymous_sorry wrote: post #77
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…

I don't see why it makes a difference for this purpose that you're replaying network packets or controller inputs or any other interface to the game engine. The important thing is that there is some well-defined interface. I guess designing for networked multiplayer does probably necessitate that, but if the engine isn't deterministic it still isn't going to work. There was a twitter thread years ago (which appears t…

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.

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

#83

Post by bregma »

Keyframe wrote: post #38
Krutonium wrote: post #34

Earlier quoted context omitted.

Tying physics to framerate at all is a mistake. Like, should be filed as a bug mistake. There's no scenario in which that's desirable. And yet even Rockstar gets it wrong. (GTA V has several framerate dependent bugs)

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.

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

#84

Post by saagarjha »

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…

Super Smash Bros Brawl does this too for replays. I remember being a child and just learning about how computers worked and being very confused at how such a long video (which I knew to be "big") could possibly fit in such a small number of "blocks" on the Wii while screenshots were larger. I think the newer games do this too but they have issues because the game can be updated and then the replays no longer work.

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

#85

Post by torginus »

danhau wrote: post #7
DeathArrow wrote: post #3

Not sure if slowing down time is the right approach. The best approach would be using something like if(game_is_paused) return; in the game loops.

The slowing down thing sounds like a hack needed for engines that don’t give you control over the main loop. I haven’t tried this yet, but for a custom engine I would introduce a second delta time that is set to 0 in the paused state. Multiplying with the paused-dt „bakes in“ the pause without having to sprinkle ifs everywhere. Multiplying with the conventional dt makes the thing happen even when paused (debug camera…

I don't think it's a hack necessarily - as a well implemented time system would produce the same results at game rate = 0 as with pause.

Also there's a need for different time domains - like imagine, in a paused state the menu animations still need to play, or if the player enters a conversation, the game logic needs to pasue (depending on designer intent etc.)

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

#86

Post by torginus »

One of the things I was thinking about with regards to pause and or save games, is the need to control all aspects of real time logic, with possibly stopping/resuming, and saving it to disk is how our current ways of doing async is incredibly lacking.

Unity has introduced the idea of coroutines (which were essentially yield based generators), and people started using them, and immediately encountered problems with pausing/saves.

Internally these coroutines compile down to state machines with opaque internals which are not necessarily consistent across compilers/code changes, and its very difficult to accomodate needs like pausing when using them.

From what I've seen, the usual answer is that people go back to hand-written state machines, and go through the pain of essentially goto programming to fix these issues.

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

#87

Post by flohofwoe »

DeathArrow wrote: post #3

Not sure if slowing down time is the right approach. The best approach would be using something like if(game_is_paused) return; in the game loops.

It's usually not as simple as that. You'd still want to at least keep the UI alive, and you also need to continue rendering while the game is paused because the swapchain surfaces might lose their content (window resizing, changing the display mode, alt-tabbing to the desktop etc).

E.g. when you open the ingame menu, the inventory (etc) you usually want to pause the gameplay, but still want to interact with the UI. Sometimes that means that at least also some of the gameplay logic needs to remain alive (inventory management, crafting, levelling up, etc...).

There are also a lot of games which need some sort of 'active pause', e.g. the gameplay needs to stop while the user can issue commands to units (traditional example: real-time combat with pause like in Baldurs-Gate-style RPGs).

Sometimes the underlying engine also doesn't properly separate gameplay logic from rendering, e.g. you can't skip one without also skipping the other (which is an engine design bug, but similar situations may also happen up in gameplay code).

Finally: pausing and the save-game-implementation is often an afterthought, but really should be implemented as the very first thing. It's quite easy to run into the trap that a frame also needs to advance time. If the game has the concept of a fixed-duration 'game logic tick' which is independent from the frame rate you're already halfway there though, but many games simply use a variable-length game tick which is identical with the frame duration.

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

#88

Post by faangguyindia »

tuetuopay wrote: post #52
faangguyindia wrote: post #41

How difficult can it be when Cloud providers are able to do live migration of VM from one bare metal server to another?

Likely more difficult. Live migration boils down to copy memory over the network, stream the page faults till you converge enough, and resume execution on the other host. It’s not a hard problem but a precise and tedious one. Pausing a game might involve a lot of GPU contexts to freeze, network resources to pause, storage streams to pause, input handling, sound, etc. Add to that physics engine that may be tied deeply…

that's exactly what i wanted to know, trick works: be confidently wrong on web and get the right answer :D

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

#89

Post by flohofwoe »

faangguyindia wrote: post #41

How difficult can it be when Cloud providers are able to do live migration of VM from one bare metal server to another?

Pausing a game is not as simple as freezing its entire state (and saving is also not as easy as dumping the entire game state to disc, at the least you'd end up with gigabyte-sized savegames).

Many game systems need to remain active in paused state (the UI needs to remain working for example, and actions in the UI may also manipulate game state (inventory, crafting, levelling up...). There are also plenty of games with 'active-pause' where the user can issue commands to units while in paused state.

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

#90

Post by limaoscarjuliet »

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…

In some games - most famously Doom - entire multiplayer is based on exchanging just the inputs and the games on all connected computers are deterministic enough to provide same outcome on all of them.

I am one of the authors of Fire Fight game (1996-ish) and we pulled the same stunt. It was actually easy, we just had to build our own "random number generator" and fix all bugs with uninitialized memory :-)

Post reply on HN