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

131–140 of 273 posts

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

#131

Post by kahrl »

ndepoel wrote: post #51
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…

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…

[flagged]

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

#132

Post by awakeasleep »

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 alternate to this was the first WORMS game, where, if I remember it properly, there were nondeterministic replays and the next turn picked up from the replay not the initial action

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

#133

Post by mackman »

kahrl wrote: post #130
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…

[flagged]

Instant replays that require long-term deterministic behavior have to be bit perfect in a way that is dramatically hard harder to implement if trying to also do network synchronization. The hard parts of each of those is fundamentally different and trying to do them at the same time terrifies me. I have shipped console games doing both (independently) and was responsible for de-bugging determinism.

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

#134

Post by mackman »

Silphendio wrote: post #42
anthk wrote: post #26

Earlier quoted context omitted.

Quake needs a FPU; if that was true it would run on a 486 SX.

You're right, I must have gotten that mixed up. Sorry. I guess floats are still mostly deterministic if you use the exact same machine code on every PC.

One of the hardest determinism bugs I had to solve on the PlayStation three was that the PPU and the SPU actually used a different instruction set and had a different internal floating point register size. We had a multi threaded physics simulation, and during instant replay, we had to ensure that the job scheduler sent the exact same work to the correct cores or we got back subtly different floating point values, which of course, immediately caused major divergences.

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

#135

Post by mackman »

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.

The other interesting trick is you need a separate RNG for visual only affects such as particles than the one you use for the physics simulation. Depending on the game during replays, you could position the camera differently and then particle effects would render differently depend, depending on what’s on screen. Obviously that shouldn’t affect the way objects decide to break during the physics simulation.

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

#136

Post by maxbond »

setr wrote: post #109
diath wrote: post #76

Earlier quoted context omitted.

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(); }

the notion of using time directly in gamedev has always confused me; it feels like the correct answer should be to simply have a notion of turns, and a real-time game simply iterates over turns automatically. And then so many turns are executed per second It's a simulation; why should clock time be involved to begin with? The only things that should care about clock time are those that exist outside the sim, e.g audi…

Simulation can proceed in logical time but animation is necessarily tied to wall clock time in order to be perceived as smooth and consistent by a human viewer.

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

#137

Post by positive-spite »

recursivecaveat wrote: post #13

The strangest pause bug I know is in Mario Sunshine: pausing will misalign the collision logic (which runs 4 times per frame) and the main game loop. So certain specific physics interactions will behave differently depending on how many times the game has been paused modulo 4.

There is another great one in one of the Legend of Zelda games.

The game world is paused whenever Link pulls an item from a chest, but because his animation does not loop perfectly, because of a missing frame, he slowly slides across the ground and even through walls.

One of the minimum % speedrun abuses this by looping the animation for many hours in order to glitch through a wall, and not collect a progression item, which would count towards the collection percentages.

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

#138

Post by drzaiusx11 »

mjlee wrote: post #128
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.

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.)

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

#139

Post by alfg »

ndepoel wrote: post #51
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…

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.

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

#140

Post by 08627843789 »

dwroberts wrote: post #124
cubefox wrote: post #112

Earlier quoted context omitted.

Bluesky has a lot of left-wing extremists where things like murdering CEOs is cool because they are allegedly "technofascist".

Log off and go watch Robocop, jesus

[dead]
Post reply on HN