6 ms·

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

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 surprised me how few games had that feature - though a few important ones, like StarCraft, did - and it only became rarer over the years.

dSebastien 6mo ago
I wish I kept my demo files!
applfanboysbgon 6mo ago
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.
- bob1029 6mo ago
  Determinism isn't essential to achieve record/playback experiences. You could just record the transform of the player at some fixed interval and then replay it with interpolation. This is arguably more "deterministic" in a strategic sense of shipping a viable product.
  - magicalhippo 6mo ago
    The player is just one entity, you'd need to do the same to any other non-trivial entity. And you couldn't use fixed intervals and naive interpolation, otherwise you'd have entities clipping the ground when bouncing etc.
- JoshTriplett 6mo ago
  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.
  - Krutonium 6mo ago
    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)
    - JoshTriplett 6mo ago
      I completely agree, but it's an easy mistake to make.
    - Keyframe 6mo ago
      not framerate of rendering but physics running at (its own) fixed frame rate.
      - nottorp 6mo ago
        Every game logic update, not only physics, should run on a timer that's fully independent from the frame rate. The only place where that doesn't matter is fixed hardware - i.e. old generation consoles, before they started to make "pro" upgrades.
        JoshTriplett 6mo ago
        > i.e. old generation consoles, before they started to make "pro" upgrades. And before it was realistically possible to port a game to run on multiple consoles without a complete rewrite.
      - bregma 6mo ago
        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.
        6mo ago
- Cthulhu_ 6mo ago
  Probably (armchair HN reader, not a game developer here) due to dealing with multiplayer latency and / or performance / multithreading / scalability.
- Jare 6mo ago
  Mostly because determinism is an all or nothing proposition. Either EVERYTHING in game logic is perfectly deterministic and isolated from everything else, or it pretty much as if nothing was. So if you want to commit to determinism, you have to be constantly vigilant and debugging these maddening types of bugs. Whether this investment is worth it or not is up to each dev. Sometimes you can find small areas of the game that can be deterministic and worth it. In a basketball game I worked on in the 90s, I designed the ball physics to be deterministic (running at 100hz). The moment the ball left the player hands it ran deterministically; we knew if it was going to hit the shot and if not, where the rebound would go to.
Lerc 6mo ago
I had a puzzle game were all of the solutions it would show were playbacks of my keypresses as I solved it myself. As the puzzles got more difficult it got harder and harder to record a solution without having pauses to think about what to do next.
- retsibsi 6mo ago
  I don't mean this in an "I know better" way, just genuine curiosity: why couldn't you record a solution with pauses and then strip them from the replay file?
  - Lerc 6mo ago
    I tried but the change in behaviour immediately before and after the pause could be seen in the playback. It's the time it takes to go "uhh, I'm stuck, I'd better pause" and then the bit before your brain kicks in following a pause.
GaelFG 6mo ago
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-28-8-network-programming-in-age-of-empires-and-beyond https://www.gamedeveloper.com/programming/1500-archers-on-a-... The main downside which probably caused the diseapearance is that any patch to the game will make the replay file unusable. Also at the time (not sure for quake) there was often fixed framerate, today the upsides of using delta time based frame calculation AND multithreading/multi platform target probably make it harded to stay deterministic (specialy for game where you want to optimize input latency)
- foota 6mo ago
  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?
  - MattRix 6mo ago
    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.
- amiga386 6mo ago
  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.
- Silphendio 6mo ago
nagaiaida 6mo ago
saving rocket league replays to watch yourself play from your opponent's perspective was super helpful in 1v1
silisili 6mo ago
Quake1 was my first love. From the old DOS version to the GLQuake to grappling hooks on Trinicom. I was amazed not only by said demo system but by QuakeC, and how heavily it was used, especially in college communities. I remember MIT and UWisc both being unreasonably productive modders in said language. As a kid, I couldn't wait to see what came next. Sadly, Q1 was rather one of a kind, and it was many years until anything else like it showed up.
jval43 6mo ago
Bungies Marathon series (1994) had the same recording system, as other commenters mentioned due to networking multiplayer. What's totally insane is that the modern engine rewrite Aleph One can also play back such old recordings, for M2 Durandal (1995) and Infinity (1996) at least.
eterm 6mo ago
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.
- gryfft 6mo ago
  > 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.
- saulr 6mo ago
  This absolutely still exists - I have a library for reading Source 2 (CS2, Deadlock etc) demo files and streams (HTTP ones like CSTV). https://github.com/saul/demofile-net https://github.com/saul/demofile-net
  - eterm 6mo ago
    Demo files work, but I'm talking about spectating live. The "Watch" tab was removed and the ability to just browse and spectate the top games currently being played. I'm sure the technology still exists in the engine, but it's no longer the key feature it once was. HLTV/GOTV was launched with some fanfare back in the day.
    - throwthrowuknow 6mo ago
      Absolutely crazy they haven’t revived this yet given the popularity of streaming.
    - Timshel 6mo ago
      Guessing too much potential for abuse if the same server was handling both match and spectating.
      - saulr 6mo ago
ErneX 6mo ago
Rocket League is a relatively recent game that allows match recording. It’s nice.
- avereveard 6mo ago
  also trackmania, and it's a common way they use to catch cheaters as pb on leaderboard have inputs
  - zimpenfish 6mo ago
    This[0] is a good intro to the topic (see also [1] for the written report) [0] https://www.youtube.com/watch?v=yDUdGvgmKIw https://www.youtube.com/watch?v=yDUdGvgmKIw [1] https://donadigo.com/tmx1 https://donadigo.com/tmx1
- larrry 6mo ago
  Replays are very common in fighting games as well, rollback netcode gets you most of the way to a replay system already (replaying game state from inputs is a core requirement for online play)
- zimpenfish 6mo ago
  Be nice if they fixed whatever bug they have on the Switch 2 that means every replay I previously downloaded[0] is unplayable and further that every time I now try and download a replay, the game crashes. But then it'd also be nice if they fixed the "game crashes randomly when joining games" bug too. (To give them credit, it doesn't now take 5 minutes after waking the Switch 2 before Rocket League reconnects me to the Epic servers like it did a couple of months ago...) [0] Also the stupidly low limit on how many you can download - it's my storage cost, not yours, wtf.
greazy 6mo ago
Interesting you mention StarCraft. The replay feature could diverge off due to the non deterministic nature of the game. https://news.ycombinator.com/item?id=21920508 https://news.ycombinator.com/item?id=21920508
- RedNifre 6mo ago
  The way I remember it was that replay playback would only break if you played a replay with a different game version than it was recorded with.
  - shaan7 6mo ago
    or, if you are replaying a single-player game that you saved+loaded (i.e. the replay only worked if the full game happened in one go without any loads).
  - esrauch 6mo ago
    There was definitely sync bugs with replays at various points. There was even desync bugs even in live multiplayer games; there was detection that it desynced which would end the game, which in turn meant exploits that would intentionally cause a desync (which would typically involve cancelled zerg buildings for some reason).
- rcxdude 6mo ago
  That's not the kind of nondeterminism that would cause replay divergence. The PRNG seed is stored in the replay (if it wasn't, almost every game would diverge very quickly. And since the multiplayer works the same basic way, the game would basically not function at all).
- raincole 6mo ago
  The comment you linked to doesn't know what they are talking. (Edit: given the context, they know what they're talking about, but you don't) A game having random mechanisms has absolutely nothing to do with whether it's deterministic. Slay the spire is 100% deterministic, gameplay-wise. All the online poker games too.
7373737373 6mo ago
Supreme Commander 2 savefiles appear to be a list of timestamped user interface inputs and unit commands
- slightlygrilled 6mo ago
  Yeah they used determinism, few bit can be read about here: https://gafferongames.com/post/floating_point_determinism/ https://gafferongames.com/post/floating_point_determinism/ https://www.forrestthewoods.com/blog/synchronous_rts_engines_and_a_tale_of_desyncs/ https://www.forrestthewoods.com/blog/synchronous_rts_engines...
maccard 6mo ago
I worked on this for a pretty big game. We recorded the network traffic and played it back and simulated the game - so same problem with patches. It also has the awkward side effect of exposing a metric crap ton of “join in progress” style bugs because our game didn’t support JiP.
ndepoel 6mo ago
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 a very elegant system that naturally flows out of the rather forward-looking decision to build the entire engine around a robust networking model.
- anonymous_sorry 6mo ago
  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 to be long gone) about how the SNES Pilot Wings pre-game demo was just a recording of controller inputs. For cartridges manufactured later in the game's life, a plane in the demo crashes rather than landing gracefully, due to a revised version of a chip in the cartridge. The inputs for the demo were never re-recorded, so the behaviour was off.
  - ndepoel 6mo ago
    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.
diath 6mo ago
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 replays quickly become outdated.
- krautsauer 6mo ago
  Or you bundle a copy of the engine and game content with every recording…
- TacticalCoder 6mo ago
  > ... 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.
  - Jyaif 6mo ago
    > 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 Starcraft 2 does that. It's still quite an achievement.
sikozu 6mo ago
[dead]
stephbook 6mo ago
The best replay feature was in "Heroes of Newerth." (DotA 1.5 in 2009) Warcraft 3 replays couldn't jump in time, just forward very fast. HoN could do that. It was amazing. For a few months they even made ALL replays searchable on a website. Every game of HoN played globally.
saagarjha 6mo ago
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.
limaoscarjuliet 6mo ago
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 :-)
- ductionist 6mo ago
  I love Fire Fight! I got the demo on a PC Gamer disc when I was a kid and played it forever. And couple of years ago when I built a retro PC, it was one of the first games I loaded up :)
abejfehr 6mo ago
You might find this talk interesting: https://youtu.be/W20t1zCZv8M https://youtu.be/W20t1zCZv8M It’s one of my favourites
jmorenoamor 6mo ago
Factorio follows that method also, given its complexity it's quite an achievement
klodolph 6mo ago
> 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 https://www.gamers.org/dEngine/quake/Qdem/dem-1.0.2.html
TacticalCoder 6mo ago
> 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 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 <- fn(state)". This explains that.
joelanman 6mo ago
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.
nickjj 6mo ago
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.
awakeasleep 6mo ago
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
zaptheimpaler 6mo ago
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.
- reitzensteinm 6mo ago
  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.
pull_my_finger 6mo ago
I always wondered how NES games, which were notoriously low memory, could have game simulation on the start screens. Think Super Mario Bros, but there are many others. If no input is received at the start menu, the game starts playing a demo run. You always see videos and posts about how developers were dissecting sprites and swapping color pallets to work around the small memory, so how in the heck did they manage having the gameplay demos?
- amiga386 6mo ago
  The demo playback on 8-bit games was rarely more than a few seconds long, and it's just a capture of input data. Here's Super Mario Bros's demo replay data: https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L1083-L1109 https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L108... 21 bytes of joypad input and 21 bytes of input timings
pornel 6mo ago
It wasn't deterministic. It didn't record the inputs. It recorded the basic state of the objects you could see. Deterministic game sync is a completely different approach more often used in RTS games. Quake had non-deterministic authoritative central server + clients getting an incomplete view of the world.
purple-leafy 6mo ago
Hey I am actually working on a browser game that is fully-deterministic (except for player inputs) and so I can basically replay games entirely. Think like a chess engine game. I’ve been obsessing over this determinism and replayability for months, to the point where any game played is fully replay-able to the exact same events as the original game. So you can play, then watch a recording and spectate your played games from different actors perspective (enemy perspective etc). My rendering and game logic are fully decoupled. I wrote the “engine” for the game from scratch. I think I only use one third party library currently. Cool to see this discussion

dSebastien 6mo ago

I wish I kept my demo files!

applfanboysbgon 6mo ago

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.

bob1029 6mo ago
Determinism isn't essential to achieve record/playback experiences. You could just record the transform of the player at some fixed interval and then replay it with interpolation. This is arguably more "deterministic" in a strategic sense of shipping a viable product.
- magicalhippo 6mo ago
  The player is just one entity, you'd need to do the same to any other non-trivial entity. And you couldn't use fixed intervals and naive interpolation, otherwise you'd have entities clipping the ground when bouncing etc.
JoshTriplett 6mo ago
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.
- Krutonium 6mo ago
  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)
  - JoshTriplett 6mo ago
    I completely agree, but it's an easy mistake to make.
  - Keyframe 6mo ago
    not framerate of rendering but physics running at (its own) fixed frame rate.
    - nottorp 6mo ago
      Every game logic update, not only physics, should run on a timer that's fully independent from the frame rate. The only place where that doesn't matter is fixed hardware - i.e. old generation consoles, before they started to make "pro" upgrades.
      - JoshTriplett 6mo ago
        > i.e. old generation consoles, before they started to make "pro" upgrades. And before it was realistically possible to port a game to run on multiple consoles without a complete rewrite.
    - bregma 6mo ago
      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.
      - 6mo ago
Cthulhu_ 6mo ago
Probably (armchair HN reader, not a game developer here) due to dealing with multiplayer latency and / or performance / multithreading / scalability.
Jare 6mo ago
Mostly because determinism is an all or nothing proposition. Either EVERYTHING in game logic is perfectly deterministic and isolated from everything else, or it pretty much as if nothing was. So if you want to commit to determinism, you have to be constantly vigilant and debugging these maddening types of bugs. Whether this investment is worth it or not is up to each dev. Sometimes you can find small areas of the game that can be deterministic and worth it. In a basketball game I worked on in the 90s, I designed the ball physics to be deterministic (running at 100hz). The moment the ball left the player hands it ran deterministically; we knew if it was going to hit the shot and if not, where the rebound would go to.

Lerc 6mo ago

I had a puzzle game were all of the solutions it would show were playbacks of my keypresses as I solved it myself. As the puzzles got more difficult it got harder and harder to record a solution without having pauses to think about what to do next.

retsibsi 6mo ago
I don't mean this in an "I know better" way, just genuine curiosity: why couldn't you record a solution with pauses and then strip them from the replay file?
- Lerc 6mo ago
  I tried but the change in behaviour immediately before and after the pause could be seen in the playback. It's the time it takes to go "uhh, I'm stuck, I'd better pause" and then the bit before your brain kicks in following a pause.

GaelFG 6mo ago

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-28-8-network-programming-in-age-of-empires-and-beyond https://www.gamedeveloper.com/programming/1500-archers-on-a-... The main downside which probably caused the diseapearance is that any patch to the game will make the replay file unusable. Also at the time (not sure for quake) there was often fixed framerate, today the upsides of using delta time based frame calculation AND multithreading/multi platform target probably make it harded to stay deterministic (specialy for game where you want to optimize input latency)

foota 6mo ago
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?
- MattRix 6mo ago
  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.
amiga386 6mo ago
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.
Silphendio 6mo ago

nagaiaida 6mo ago

saving rocket league replays to watch yourself play from your opponent's perspective was super helpful in 1v1

silisili 6mo ago

Quake1 was my first love. From the old DOS version to the GLQuake to grappling hooks on Trinicom. I was amazed not only by said demo system but by QuakeC, and how heavily it was used, especially in college communities. I remember MIT and UWisc both being unreasonably productive modders in said language. As a kid, I couldn't wait to see what came next. Sadly, Q1 was rather one of a kind, and it was many years until anything else like it showed up.

jval43 6mo ago

Bungies Marathon series (1994) had the same recording system, as other commenters mentioned due to networking multiplayer. What's totally insane is that the modern engine rewrite Aleph One can also play back such old recordings, for M2 Durandal (1995) and Infinity (1996) at least.

eterm 6mo ago

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.

gryfft 6mo ago
> 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.
saulr 6mo ago
This absolutely still exists - I have a library for reading Source 2 (CS2, Deadlock etc) demo files and streams (HTTP ones like CSTV). https://github.com/saul/demofile-net https://github.com/saul/demofile-net
- eterm 6mo ago
  Demo files work, but I'm talking about spectating live. The "Watch" tab was removed and the ability to just browse and spectate the top games currently being played. I'm sure the technology still exists in the engine, but it's no longer the key feature it once was. HLTV/GOTV was launched with some fanfare back in the day.
  - throwthrowuknow 6mo ago
    Absolutely crazy they haven’t revived this yet given the popularity of streaming.
  - Timshel 6mo ago
    Guessing too much potential for abuse if the same server was handling both match and spectating.
    - saulr 6mo ago

ErneX 6mo ago

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

avereveard 6mo ago
also trackmania, and it's a common way they use to catch cheaters as pb on leaderboard have inputs
- zimpenfish 6mo ago
  This[0] is a good intro to the topic (see also [1] for the written report) [0] https://www.youtube.com/watch?v=yDUdGvgmKIw https://www.youtube.com/watch?v=yDUdGvgmKIw [1] https://donadigo.com/tmx1 https://donadigo.com/tmx1
larrry 6mo ago
Replays are very common in fighting games as well, rollback netcode gets you most of the way to a replay system already (replaying game state from inputs is a core requirement for online play)
zimpenfish 6mo ago
Be nice if they fixed whatever bug they have on the Switch 2 that means every replay I previously downloaded[0] is unplayable and further that every time I now try and download a replay, the game crashes. But then it'd also be nice if they fixed the "game crashes randomly when joining games" bug too. (To give them credit, it doesn't now take 5 minutes after waking the Switch 2 before Rocket League reconnects me to the Epic servers like it did a couple of months ago...) [0] Also the stupidly low limit on how many you can download - it's my storage cost, not yours, wtf.

greazy 6mo ago

Interesting you mention StarCraft. The replay feature could diverge off due to the non deterministic nature of the game. https://news.ycombinator.com/item?id=21920508 https://news.ycombinator.com/item?id=21920508

RedNifre 6mo ago
The way I remember it was that replay playback would only break if you played a replay with a different game version than it was recorded with.
- shaan7 6mo ago
  or, if you are replaying a single-player game that you saved+loaded (i.e. the replay only worked if the full game happened in one go without any loads).
- esrauch 6mo ago
  There was definitely sync bugs with replays at various points. There was even desync bugs even in live multiplayer games; there was detection that it desynced which would end the game, which in turn meant exploits that would intentionally cause a desync (which would typically involve cancelled zerg buildings for some reason).
rcxdude 6mo ago
That's not the kind of nondeterminism that would cause replay divergence. The PRNG seed is stored in the replay (if it wasn't, almost every game would diverge very quickly. And since the multiplayer works the same basic way, the game would basically not function at all).
raincole 6mo ago
The comment you linked to doesn't know what they are talking. (Edit: given the context, they know what they're talking about, but you don't) A game having random mechanisms has absolutely nothing to do with whether it's deterministic. Slay the spire is 100% deterministic, gameplay-wise. All the online poker games too.

7373737373 6mo ago

Supreme Commander 2 savefiles appear to be a list of timestamped user interface inputs and unit commands

slightlygrilled 6mo ago
Yeah they used determinism, few bit can be read about here: https://gafferongames.com/post/floating_point_determinism/ https://gafferongames.com/post/floating_point_determinism/ https://www.forrestthewoods.com/blog/synchronous_rts_engines_and_a_tale_of_desyncs/ https://www.forrestthewoods.com/blog/synchronous_rts_engines...

maccard 6mo ago

I worked on this for a pretty big game. We recorded the network traffic and played it back and simulated the game - so same problem with patches. It also has the awkward side effect of exposing a metric crap ton of “join in progress” style bugs because our game didn’t support JiP.

ndepoel 6mo ago

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 a very elegant system that naturally flows out of the rather forward-looking decision to build the entire engine around a robust networking model.

anonymous_sorry 6mo ago
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 to be long gone) about how the SNES Pilot Wings pre-game demo was just a recording of controller inputs. For cartridges manufactured later in the game's life, a plane in the demo crashes rather than landing gracefully, due to a revised version of a chip in the cartridge. The inputs for the demo were never re-recorded, so the behaviour was off.
- ndepoel 6mo ago
  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.

diath 6mo ago

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 replays quickly become outdated.

krautsauer 6mo ago
Or you bundle a copy of the engine and game content with every recording…
TacticalCoder 6mo ago
> ... 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.
- Jyaif 6mo ago
  > 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 Starcraft 2 does that. It's still quite an achievement.

sikozu 6mo ago

[dead]

stephbook 6mo ago

The best replay feature was in "Heroes of Newerth." (DotA 1.5 in 2009) Warcraft 3 replays couldn't jump in time, just forward very fast. HoN could do that. It was amazing. For a few months they even made ALL replays searchable on a website. Every game of HoN played globally.

saagarjha 6mo ago

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.

limaoscarjuliet 6mo ago

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

ductionist 6mo ago
I love Fire Fight! I got the demo on a PC Gamer disc when I was a kid and played it forever. And couple of years ago when I built a retro PC, it was one of the first games I loaded up :)

abejfehr 6mo ago

You might find this talk interesting: https://youtu.be/W20t1zCZv8M https://youtu.be/W20t1zCZv8M It’s one of my favourites

jmorenoamor 6mo ago

Factorio follows that method also, given its complexity it's quite an achievement

klodolph 6mo ago

> 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 https://www.gamers.org/dEngine/quake/Qdem/dem-1.0.2.html

TacticalCoder 6mo ago

> 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 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 <- fn(state)". This explains that.

joelanman 6mo ago

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.

nickjj 6mo ago

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.

awakeasleep 6mo ago

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

zaptheimpaler 6mo ago

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.

reitzensteinm 6mo ago
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.

pull_my_finger 6mo ago

I always wondered how NES games, which were notoriously low memory, could have game simulation on the start screens. Think Super Mario Bros, but there are many others. If no input is received at the start menu, the game starts playing a demo run. You always see videos and posts about how developers were dissecting sprites and swapping color pallets to work around the small memory, so how in the heck did they manage having the gameplay demos?

amiga386 6mo ago
The demo playback on 8-bit games was rarely more than a few seconds long, and it's just a capture of input data. Here's Super Mario Bros's demo replay data: https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L1083-L1109 https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L108... 21 bytes of joypad input and 21 bytes of input timings

pornel 6mo ago

It wasn't deterministic. It didn't record the inputs. It recorded the basic state of the objects you could see. Deterministic game sync is a completely different approach more often used in RTS games. Quake had non-deterministic authoritative central server + clients getting an incomplete view of the world.

purple-leafy 6mo ago

Hey I am actually working on a browser game that is fully-deterministic (except for player inputs) and so I can basically replay games entirely. Think like a chess engine game. I’ve been obsessing over this determinism and replayability for months, to the point where any game played is fully replay-able to the exact same events as the original game. So you can play, then watch a recording and spectate your played games from different actors perspective (enemy perspective etc). My rendering and game logic are fully decoupled. I wrote the “engine” for the game from scratch. I think I only use one third party library currently. Cool to see this discussion