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

121–130 of 273 posts

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

#121

Post by klodolph »

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 that it could record your inputs/the game state and just play them back to get a gameplay video.

NOT how demos work in Quake. It’s more like Quake uses a client/server architecture, and the demo is a capture of the messages.

https://www.gamers.org/dEngine/quake/Qdem/dem-1.0.2.html

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

#122

Post by TacticalCoder »

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 + player input + frame at which user(s) [two players but non-networked] input was happening". With that I could make tiny save files and replay (and I did find my "impossible to find" bug thanks to that).

First time I remember someone talking about it was a Gamasutra article by an Age of Empire dev (article which another poster already mentioned here in this thread): they had a 100% deterministic engine. FWIW I wrote an email to the author of that article back then and we discussed deterministic game engines.

Warcraft 3 definitely had a deterministic game engine: save files, even for 8 players (networked) games were tiny. But then you had another issue: when units, over different patches, would be "nerfed" to balance the game (or any other engine change really), your replay files wouldn't play correctly anymore. The game wouldn't bother shipping with older engines: no backward compatibility for replay files.

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

Another fun sidenote... A very good friends of mine wrote "World Rally Fever" (published by Team 17) and I was a beta tester of the game. Endless discussion with my friend because I was pissed off for his engine was so "non-deterministic" than hitting the Turbo button on my 486 (I think it was a 486) while I was playing the game would change the behavior of the (computer) opponents.

https://youtu.be/NhRQWNqbvTk

To me a deterministic game engine, unless you're a massively networked multi-player game, just makes sense.

Blizzard could do it for Warcraft 3 in 2002 for up to 8 players and hundreds of units. Several games had it already in the nineties.

It simplifies everything and I'd guesstimate something like 99% of all the game out there that don't do it could actually do it.

But it touches to something much more profound: state and how programmers think about state and reproducibility. Hint: most don't think about that at all.

Some do though: I was watching a Clojure conf vid the other day and they often keep hammering that "view is a function of state". And it is. That's how things are. It was true in 1991 when I wrote my DOS game, it was true for Age of Empire, Warcraft 3 and many other games. And it is still true today.

But we're in 2026 and there are still many devs insisting that "functional programming sucks" and that we should bow to the mutability gods for that is the only way and they'll fight you to death if you dare to say that "view This explains that.

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

#123

Post by cubefox »

esrauch wrote: post #119
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".

"Evil megacorp" media is hardly new.

Murdering CEOs is extremism, saying something is an "evil megacorp" is totally different.

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

#124

Post by dwroberts »

cubefox wrote: post #112
gordian-mind wrote: post #62

I was suspicious of those random game developers getting quoted, and this is the pinned post of the one giving this cute silly story about slowing down game speed time: "Announcing TORMENT HEXUS, a match-3 roguelike about putting technofascist CEOs on the wrong side of skyscraper windows! [...] And remember: they SHOULD be afraid of us. #indiedev #indiegame" Weird times.

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

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

#125

Post by nickjj »

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…

Demos were really useful for helping validate competitive play too. While certain anti-cheat programs were available such as PunkBuster (Quake 3), having gaming ladders request everyone records a demo and upload it from their POV was a very low friction way to deter cheating. The idea being, no one looked at them unless there was suspicion so it wasn't even a time sink for administrators.

No fancy kernel level anti-cheats. Just ensure matches were played on legitimate servers and demos were recorded.

Also, back then live streaming while playing was usually too much of a computational and network burden (56k modems), but casting was just coming around as being a thing and certain Quake 3 mods had spectator modes that let someone streaming spectate you from the first person live which also helped deter cheating. There was even split screen spectating modes so you can follow the action (useful for 4v4 games, etc.).

Carmack and team really made something special back then. The ideas they had and what they did with their tech on relatively low end hardware was remarkable.

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

#126

Post by joelanman »

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…

You could play back multiplayer Halo 3 matches in 3D, with a free camera. Was really interesting to see how matches played out, how you got killed and so on, and for taking cool screenshots.

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

#127

Post by TacticalCoder »

diath wrote: post #72
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…

If memory serves well, that worked by replaying network packets, which is what some other games do as well, the problem with that approach is that for live service games unlike old games that were often "set in stone", the protocol always changes, so it's a huge maintenance burden. You either need to add conversion tools, keep maintaining backwards compatibility with older protocol versions, or you accept that replay…

> ... or you accept that replays quickly become outdated

That's how Warcraft 3's fully deterministic save files would work. Old replay files would only work tied to one specific patch patch of the game.

But here's the thing: it's still a godsend while in development and it was still a godsend to players too. "Battlenet user spiritwolf beat me even though I had the upper hand, how did he do it? Let's check the replay immediately".

Also if you really think about it: if you plan for it from day one, there's not much preventing your game engine from having a pluggable system where you could have the various different patches of the game engine ship with every subsequent release of the game.

So when 1.03c is out but you want to play a replay meant for version 1.02b, the game automatically just use that version of the game engine.

The only case where this basically ain't working is if there's a patch for a security exploit: that'd probably need to be patched for good.

But for all other cases, backward compatibility for replay files / deterministic game engines is totally doable. It may not be how things are done, but it's totally doable.

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

#128

Post by mjlee »

vvanders wrote: post #82
anonymous_sorry wrote: post #77

Earlier quoted context omitted.

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.

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

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

#129

Post by MattRix »

foota wrote: post #21
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…

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?

Overwatch also has “kill cams”, which basically create an entire alternate game state to show you how the enemy killed you, and they have the “Play of the Game” system that replays the coolest moment of the game at the end. It’s impressive tech.

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

#130

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]
Post reply on HN