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

21–30 of 273 posts

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

#21

Post by foota »

GaelFG wrote: post #15
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…

I'm pretty sure it's because it's in fact 'just' a cool side effect to a common network architecture optimisation from the time where you could'nt send the 'state' of the entire game even with only delta modifiers and so you make the game detertministic to only synchronize inputs :) an exemple article I remember : https://www.gamedeveloper.com/programming/1500-archers-on-a-... The main downside which probably caused…

Fun fact, overwatch must have done a similar things because they would let you play back games up until some release when you could no longer replay them unless you'd saved the render.

I think if I remember right there were also funny moments where things didn't look right after patches?

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

#22

Post by amiga386 »

GaelFG wrote: post #15
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…

I'm pretty sure it's because it's in fact 'just' a cool side effect to a common network architecture optimisation from the time where you could'nt send the 'state' of the entire game even with only delta modifiers and so you make the game detertministic to only synchronize inputs :) an exemple article I remember : https://www.gamedeveloper.com/programming/1500-archers-on-a-... The main downside which probably caused…

I think it's more the patching thing that made "collect and replay inputs" less common.

Networked games have a "tickrate", just for the networking/state aspect. For example, Counter-Strike 2 has a 64Hz tickrate by default. They also typically have a fixed time interval for physics engines. Both of these should be completely independent of framerate, because that's jittery and unpredictable.

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

#23

Post by eterm »

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…

Related to that is the ability to watch games using the game-client too.

This used to be a promoted feature in CS, with "HLTV/GOTV", but sadly disappeared when they moved to CS2.

Spectating in-client is such as powerful way to learn what people are doing that you can't always see even from a recording from their perspective.

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

#24

Post by JoshTriplett »

applfanboysbgon wrote: post #12
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…

Checking in as a random indie developer who still prioritises determinism in my engine. I don't understand why so many games/engines sacrifice it when it has so much utility.

I think if it were as simple as "remember the RNG seed", game developers would do it every time. But determinism also means, for instance, running the physics engine at a deterministic timestep regardless of the frame rate, to avoid differences in accumulated error or collision detection. And that's something that needs designing in from day one.

Thank you for still prioritizing it.

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

#25

Post by Silphendio »

GaelFG wrote: post #15
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…

I'm pretty sure it's because it's in fact 'just' a cool side effect to a common network architecture optimisation from the time where you could'nt send the 'state' of the entire game even with only delta modifiers and so you make the game detertministic to only synchronize inputs :) an exemple article I remember : https://www.gamedeveloper.com/programming/1500-archers-on-a-... The main downside which probably caused…

You don't need to tun the whole game at a fixed framerate, only the physics. That's actually common practice.

The bigger problem is that floating point math isn't deterministic. So replays need to save key frames to avoid drift.

Quake used fixed point math.

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

#26

Post by anthk »

Silphendio wrote: post #25
GaelFG wrote: post #15

Earlier quoted context omitted.

I'm pretty sure it's because it's in fact 'just' a cool side effect to a common network architecture optimisation from the time where you could'nt send the 'state' of the entire game even with only delta modifiers and so you make the game detertministic to only synchronize inputs :) an exemple article I remember : https://www.gamedeveloper.com/programming/1500-archers-on-a-... The main downside which probably caused…

You don't need to tun the whole game at a fixed framerate, only the physics. That's actually common practice. The bigger problem is that floating point math isn't deterministic. So replays need to save key frames to avoid drift. Quake used fixed point math.

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

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

#27

Post by gryfft »

eterm wrote: post #23
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…

Related to that is the ability to watch games using the game-client too. This used to be a promoted feature in CS, with "HLTV/GOTV", but sadly disappeared when they moved to CS2. Spectating in-client is such as powerful way to learn what people are doing that you can't always see even from a recording from their perspective.

> Related to that is the ability to watch games using the game-client too.

Halo 3's in-engine replay system was the high water mark of gaming for me.

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

#28

Post by gobdovan »

When I present TLA+ [0], I am referencing game pauses (pause buffer / item duplication Legend of Zelda exploit, Dark Souls menuing to cancel animations) and deliberate crashes as mechanics to exploit games, as those are still valid actions that can be modeled, and not doing that allows such exploits to happen.

A system is only correct relative to the transition system you wrote down. If the real system admits extra transitions that you care about (pause, crash, re-entry, partial commits), and you didn't model them, then you proved correctness of the wrong system.

[0] https://lamport.azurewebsites.net/video/videos.html

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

#29

Post by ErneX »

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…

Rocket League is a relatively recent game that allows match recording. It’s nice.
Post reply on HN