News for hackers. Stuff that matters.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by ndepoel on Sunday April 19, 2026 @04:58AM (#47822869)
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.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by anonymous_sorry on Sunday April 19, 2026 @05:44AM (#47823055)
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.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by ndepoel on Sunday April 19, 2026 @05:57AM (#47823117)
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.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by setr on Sunday April 19, 2026 @07:40AM (#47823580)
if its deterministic lockstep, then all you need to do is record inputs and replay the inputs, since the engine itself is guaranteed to behave the same. If it's client/server and non-deterministic, then you need to record the entire state of the system at every step (which you'll naturally receive from the server) to replay. The main difference would be in how large a replay file would get; and more dynamism naturally implies more information to record. Large unit quantities in e.g. an RTS behaves more sanely with deterministic replay.

the other negative with deterministic input-based replay is what you've said -- if the engine deviates in any manner, the replay becomes invalidated. You'd have to probably ship with every version of the engine, and the replay just runs on the relevant release. Just replaying and re-recording the inputs on the new version wouldn't do anything, because the outcome behavior would inevitably out of sync with the original.

I'm also not sure how one would support scrubbing, except by also having inverse operations defined for every action or by fully-capturing state at various snapshots and replaying forward at like 10x speed.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by vvanders on Sunday April 19, 2026 @06:01AM (#47823126)
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.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by cubefox on Sunday April 19, 2026 @07:53AM (#47823653)
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.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by mackman on Sunday April 19, 2026 @09:49AM (#47824303)
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 Pa... by 10000truths on Sunday April 19, 2026 @10:46AM (#47824705)
> a lockstep solution which only considers inputs

Nothing stops you from adding a PRNG seed parameter to initialize your deterministic game engine.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by Jare on Sunday April 19, 2026 @11:38AM (#47825091)
Typical deterministic game engines will do this, send it to every machine as part of the initial game state, and also check the seed across machines on every simulation frame (or periodically) to detect desyncs.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by cubefox on Sunday April 19, 2026 @11:33AM (#47825054)
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.)
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by chowells on Sunday April 19, 2026 @01:13PM (#47825836)
That's not more of a problem than synchronizing the player names at game start. It's table stakes for an online game.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by cubefox on Monday April 20, 2026 @12:16PM (#47836404)
If you synchronize the seed at game start for speedruns, the seed is the same for everyone, and players can again manipulate their luck, so nothing was gained.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by chowells on Tuesday April 21, 2026 @12:39PM (#47851184)
If you run a game entirely between colluding parties, cheating speed runners can just hack it to do whatever they want anyway. See the Dream Minecraft thing from several years back. Speed running claims may be cheated in a thousand ways. It's up to the people who care about it to establish and enforce rules.

But if you're running a multiplayer game with random elements and aren't colluding, you don't have to let a malicious party set the RNG seed to whatever they like just because you agree on it at game start. There's any number of simple cryptographic protocols that allow each peer to contribute equally to the RNG state based on having a separate commitment phase. And it's a lot easier to run a quick cryptographic setup than it is to have constant input-driven adjustment.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by DonHopkins on Sunday April 19, 2026 @02:00PM (#47826221)
https://news.ycombinator.com/item?id=30359560

DonHopkins on Feb 16, 2022 | parent | context | favorite | on: Don't use text pixelation to redact sensitive info...

When I implemented the pixelation censorship effect in The Sims 1, I actually injected some random noise every frame, so it made the pixels shimmer, even when time was paused. That helped make it less obvious that it wasn't actually censoring penises, boobs, vaginas, and assholes, because the Sims were actually more like smooth Barbie dolls or GI-Joes with no actual naughty bits to censor, and the players knowing that would have embarrassed the poor Sims.

The pixelized naughty bits censorship effect was more intended to cover up the humiliating fact that The Sims were not anatomically correct, for the benefit of The Sims own feelings and modesty, by implying that they were "fully functional" and had something to hide, not to prevent actual players from being shocked and offended and having heart attacks by being exposed to racy obscene visuals, because their actual junk that was censored was quite G-rated. (Or rather caste-rated.)

But when we later developed The Sims Online based on the original The Sims 1 code, its use of pseudo random numbers initially caused the parallel simulations that were running in lockstep on the client and headless server to diverge (causing terribly subtle hard-to-track-down bugs), because the headless server wasn't rendering the randomized pixelization effect but the client was, so we had to fix the client to use a separate user interface pseudo random number generator that didn't have any effect on the simulation's deterministic pseudo random number generator.

[4/6] The Sims 1 Beta clip ♦ "Dana takes a shower, Michael seeks relief" ♦ March 1999:

https://www.youtube.com/watch?v=ma5SYacJ7pQ

(You can see the shimmering while Michael holds still while taking a dump. This is an early pre-release so he doesn't actually take his pants off, so he's really just sitting down on the toilet and pooping his pants. Thank God that's censored! I think we may have actually shipped with that "bug", since there was no separate texture or mesh for the pants to swap out, and they could only be fully nude or fully clothed, so that bug was too hard to fix, closed as "works as designed", and they just had to crap in their pants.)

Will Wright on Sex at The Sims & Expansion Packs:

https://www.youtube.com/watch?v=DVtduPX5e-8

The other nasty bug involving pixelization that we did manage to fix before shipping, but that I unfortunately didn't save any video of, involved the maid NPC, who was originally programmed by a really brilliant summer intern, but had a few quirks:

A Sim would need to go potty, and walk into the bathroom, pixelate their body, and sit down on the toilet, then proceed to have a nice leisurely bowel movement in their trousers. In the process, the toilet would suddenly become dirty and clogged, which attracted the maid into the bathroom (this was before "privacy" was implemented).

She would then stroll over to toilet, whip out a plunger from "hammerspace" [1], and thrust it into the toilet between the pooping Sim's legs, and proceed to move it up and down vigorously by its wooden handle. The "Unnecessary Censorship" [2] strongly implied that the maid was performing a manual act of digital sex work. That little bug required quite a lot of SimAntics [3] programming to fix!

[1] Hammerspace: https://tvtropes.org/pmwiki/pmwiki.php/Main/Hammerspace

[2] Unnecessary Censorship: https://www.youtube.com/watch?v=6axflEqZbWU

[3] SimAntics: https://news.ycombinator.com/item?id=22987435 and https://simstek.fandom.com/wiki/SimAntics

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by dormento on Monday April 20, 2026 @10:41AM (#47835096)
I love stories like these.

Btw video number [2] is private.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by cubefox on Monday April 20, 2026 @12:21PM (#47836490)
Quite fitting then that it is called "unnecessary censorship".
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by mjlee on Sunday April 19, 2026 @09:04AM (#47824011)
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 Pa... by Jare on Sunday April 19, 2026 @11:33AM (#47825062)
I think the introduction of the term in networking simulations and games came with SIMNET https://en.wikipedia.org/wiki/SIMNET and continued more widely in the DIS https://en.wikipedia.org/wiki/Distributed_Interactive_Simula...

I first learned of it in some writing about a 1997 multiplayer game called, heh, Dead Reckoning.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by drzaiusx11 on Sunday April 19, 2026 @10:00AM (#47824368)
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 Pa... by mjlee on Sunday April 19, 2026 @11:34AM (#47825067)
It's a great read! A story of how the scientific elite stalled progress because the right answer wasn't the one they hoped it would be, and didn't come from the sort of person they thought it should.

If you get the chance, you can see some of Harrison's chronometers at the Royal Observatory in London, though I don't know if they're always on display.

I'll add a recommendation for Sextant by David Barrie.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by drzaiusx11 on Sunday April 19, 2026 @05:53PM (#47827966)
Thanks for the recommendation, I'll add it to the shortlist!
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by sebg on Sunday April 19, 2026 @11:33AM (#47825060)
What other books do you like?
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by drzaiusx11 on Monday April 20, 2026 @08:23PM (#47843034)
Pick a subject I guess, that's a really hard question
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by sebg on Thursday April 23, 2026 @04:40PM (#47881605)
Last two books that you read?
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by drzaiusx11 on Sunday April 26, 2026 @10:20AM (#47910573)
"Build Your Own Metal Working Shop From Scrap" by David Gingery which covers everything from building a foundry to making all your tools from first principles using nothing but river sand and junk metal for smelting.

"On Trails" by Robert Moore that discusses how walking paths from the first peoples persist, grow and change over hundreds of years, along with advances in walking trail design in recent years to become a part time recreational activity vs the pure utility of terrain traversal as they first were. Covers how a trail is a "living thing", as it were, because any who tread on it help reinforce it. Covers non human trails like ants and their reenforcement via pheromones and the like.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by forrestthewoods on Sunday April 19, 2026 @03:46PM (#47827069)
> I don't see why it makes a difference for this purpose that you're replaying network packets or controller input

Building a simulation that has perfect determinism is incredibly time consuming. Incredibly. Especially one that is identical across platforms, chipsets, and architectures.

Deterministic simulation replay also breaks anytime you change the simulation. Which is kind of obvious. But quite meaningful.

In any case, I’ve shipped games that use both solutions. And let me tell you, deterministic simulation from input is an order of magnitude more effort to build, test, and maintain!

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by vor_ on Monday April 20, 2026 @03:57AM (#47831484)
Using a client-server model for single-player allows it to lean on that system for replaying state changes.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by DANmode on Monday April 20, 2026 @10:25AM (#47834848)
HN post linking to that Twitter thread!

https://news.ycombinator.com/item?id=19883714

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by _jackdk_ on Sunday April 19, 2026 @07:22AM (#47823489)
Carmack wrote a really interesting .plan about this. It seems to be written between Q2 and Q3A, and cites the Windows message queue as a big inspiration:

https://github.com/ESWAT/john-carmack-plan-archive/blob/mast...

[dead]
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by mackman on Sunday April 19, 2026 @09:44AM (#47824268)
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 Pa... by alfg on Sunday April 19, 2026 @10:19AM (#47824496)
It's just capturing inputs and replaying them.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by furyofantares on Sunday April 19, 2026 @10:58AM (#47824793)
That's not true though, is what they're saying. Quake demo files are server-to-client packets, results of the simulation, not client-to-server packets, the inputs.

If you wanted to add random critical hits and random bullet spread based on the pixels in a live feed of a lava lamp cam, clients could still record .dem files and they would still work.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by syspec on Sunday April 19, 2026 @11:00AM (#47824805)
"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 Pa... by Rohansi on Sunday April 19, 2026 @11:43AM (#47825128)
It sounds like it would be complicated but it's really not! The server should already be sending a snapshot of the world when you connect and then stream deltas after that. If you capture all of the packets the server sends you can mock the connection to the server and it should just work because the client renders everything based on that data. You'll only need to do a bit of work to disable client input etc.
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by Narishma on Sunday April 19, 2026 @11:03AM (#47824824)
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 Pa... by Jare on Sunday April 19, 2026 @11:44AM (#47825135)
Doom and Wolf3d and many other multiplayer games of the 90s (including some I worked on) were deterministic/lockstep and machines only needed to exchange inputs (in a deterministic manner ofc).

Quake was completely different. The client/server term was aimed at describing that the game state is computed on the server, updated based on client inputs send to the server, and then the game state is sent from server to the clients for display. Various optimizations apply.

Deterministic/lockstep games more often used host/guest terminology to indicate that a machine was acting as coordinator/owner of the game, but none of them were serving state to others. This terminology is not strict and anyone could use those terms however they wanted, but it is a good ballpark.

Re:Game Devs Explain the Tricks Involved with Letting You Pa... by lelanthran on Sunday April 19, 2026 @11:27AM (#47824998)
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 Pa... by trashface on Sunday April 19, 2026 @12:04PM (#47825293)
The engine needs to save the RNG seed too and various other details, the goal is definitely to make it as deterministic as possible (and yes saving the packets is part of that).
Re:Game Devs Explain the Tricks Involved with Letting You Pa... by vidalee on Monday April 20, 2026 @09:38AM (#47834161)
League of Legends is using the same system