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

151–160 of 273 posts

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

#151

Post by syspec »

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…

"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!

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

#152

Post by Narishma »

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…

I'm not sure that's the reason since Doom and Wolfenstein 3d before it also had such demo systems but they didn't use a client/server model.

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

#155

Post by netcoyote »

One of the fun features that I developed for Warcraft (the RTS) was to fade the screen to grayscale when the game is paused.

Since the game uses a 256 color palette, it was only necessary to update a few bytes of data (3x256) instead of redrawing the whole screen, so the effect was quick.

I also used this trick when the game stalled due to missing network packets from other players. Initially the game would still be responsive when no messages were received so that you could still interact and send commands. After a few seconds the game would go into paused state with grayscale screen to signify the player that things were stuck. Then several seconds after that a dialog box would show allowing a player to quit the game.

This was much less disruptive than displaying a dialog box immediately on network stall.

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

#157

Post by reitzensteinm »

zaptheimpaler wrote: post #141
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.

You can still rewind by storing checkpoints, resuming at the most recent before the seek time and fast forwarding from there.

The updates thing is a shame. You can store multiple configuration files for balance patches, but executable code is much harder.

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

#158

Post by KellyCriterion »

netcoyote wrote: post #155

One of the fun features that I developed for Warcraft (the RTS) was to fade the screen to grayscale when the game is paused. Since the game uses a 256 color palette, it was only necessary to update a few bytes of data (3x256) instead of redrawing the whole screen, so the effect was quick. I also used this trick when the game stalled due to missing network packets from other players. Initially the game would still be…

Palette rotation was also heavily used by Ultima & Origin games up to U8 - Pagan

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

#159

Post by lelanthran »

Narishma wrote: post #152
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'm not sure that's the reason since Doom and Wolfenstein 3d before it also had such demo systems but they didn't use a client/server model.

It doesn't need a client server model, but it does need a message pump design.

Then you record the messages as they are recieved, and if networked, tx and rx the messages in the main pump loop.

If not networked, everything still works as normal: game engine itself never knows the difference.

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

#160

Post by cubefox »

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.

That could lead to other subtle problems elsewhere though, because it requires synchronizing the seed. If you can't do that, it could lead to problems. E.g. when comparing offline speedruns where everyone would have a different seed. Then some players could have more luck than others even with the same inputs, which would be unfair. (Though I can't think of anything else at the moment.)
Post reply on HN