Slowing down time applies it universally. Otherwise you're going to need that condition to every single object in the game.

I haven’t tried this yet, but for a custom engine I would introduce a second delta time that is set to 0 in the paused state. Multiplying with the paused-dt „bakes in“ the pause without having to sprinkle ifs everywhere. Multiplying with the conventional dt makes the thing happen even when paused (debug camera, UI animations).

E.g. when you open the ingame menu, the inventory (etc) you usually want to pause the gameplay, but still want to interact with the UI. Sometimes that means that at least also some of the gameplay logic needs to remain alive (inventory management, crafting, levelling up, etc...).

There are also a lot of games which need some sort of 'active pause', e.g. the gameplay needs to stop while the user can issue commands to units (traditional example: real-time combat with pause like in Baldurs-Gate-style RPGs).

Sometimes the underlying engine also doesn't properly separate gameplay logic from rendering, e.g. you can't skip one without also skipping the other (which is an engine design bug, but similar situations may also happen up in gameplay code).

Finally: pausing and the save-game-implementation is often an afterthought, but really should be implemented as the very first thing. It's quite easy to run into the trap that a frame also needs to advance time. If the game has the concept of a fixed-duration 'game logic tick' which is independent from the frame rate you're already halfway there though, but many games simply use a variable-length game tick which is identical with the frame duration.

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)

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.

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.

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.

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

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.

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

It’s one of my favourites

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

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

This explains that.

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.

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.

But when you find a broken ancient seal in the forest, the giant creepy eyeball moving around in it keeps moving even when you pause the game, which helps emphasise how other-worldly it is.

The game world is paused whenever Link pulls an item from a chest, but because his animation does not loop perfectly, because of a missing frame, he slowly slides across the ground and even through walls.

One of the minimum % speedrun abuses this by looping the animation for many hours in order to glitch through a wall, and not collect a progression item, which would count towards the collection percentages.

Live migration boils down to copy memory over the network, stream the page faults till you converge enough, and resume execution on the other host. It’s not a hard problem but a precise and tedious one.

Pausing a game might involve a lot of GPU contexts to freeze, network resources to pause, storage streams to pause, input handling, sound, etc. Add to that physics engine that may be tied deeply in the system and you end up with a hard problem.

What a VM does is not the role of the hypervisor, thus it can apply its hammer that works in pretty much all cases, and VMs are pretty much all the same. On the other hand, all games are bespoke with custom plugins and custom integrations, which make them the opposite of "generic pause implementation".

Many game systems need to remain active in paused state (the UI needs to remain working for example, and actions in the UI may also manipulate game state (inventory, crafting, levelling up...). There are also plenty of games with 'active-pause' where the user can issue commands to units while in paused state.

But like most things in game development there is no solution that fits every use case.

    float accum = 0;
    while (running) {
        poll_input();
        poll_network();

        accum += delta_time;

        while (accum >= tick_time) {
            accum -= tick_time;

            update_ui(tick_time);
            update_anims(tick_time);

            if (!paused) {
                update_entities(tick_time);
            }
        }

        render();
    }

Like, yes, the most likely people to respond to such a call for "stuff to put in an article on Kotaku" are probably developers that want some publicity. But this is hardly surprising.

Typically any of the common modern engines with a "time scale" variable like that are not at all optimising anything in that way. It's likely that the physics engine won't be stepped with a zero delta time, which will reduce the time spent on physics, but that's more of a byproduct of how physics engines work[0] than an optimisation.

You would have to go out of your way to capture the scene and display it "under the pause menu" in that way. Not saying nobody does that, just that it's not something the engine is giving you for free nor is it related to the time scale variable.

Further, doing that won't necessarily reduce resource usage. For example, if there isn't some sleep time inserted in the main loop when in a menu, or v-sync[1] to limit the framerate, the result of the simplified scene (just the menu and the quad with the captured scene) is an extremely high framerate, which may or may not cook the hardware more than the in-game load.

[0] Typical rigidbody physics engines are only (what I'll call) predictably stable with a constant delta time (same dt every tick). And a common way to manage this is with a time accumulator main loop, that only steps physics for whole units of dt.

[1] And v-sync isn't a silver bullet. consider refresh rates, different hardware, different drivers, driver overrides.

You gotta learn and understand its quirks, though. As long as your flight state is rock stable (e.g. on Auto Pilot) and/or you're not fiddling with the controls while paused, it's pretty much always worked fine for me.

I've also used its interactivity to my advantage and saved the plane from an otherwise unsaveable flight state, e.g. by gaining airspeed while paused.

So my memory might be playing me a trick, but wasn't that already the case in FS2002 and 2004? I seem to remember using the pause as a kid to look at my plane under every angle.

The rendering loop continues to run. The GUI is immediate mode and is still rendered. In some games visual effects continue to be rendered. If it’s a networked game the network code will continue to run.

Taken from this comment: https://news.ycombinator.com/item?id=47825155

Obviously not every game is doing that level of styling, but often a lot of stuff might still be happening when a game is "paused" for various reasons e.g. aesthetics, or handling input for pause menus, which usually offer you the ability to change all the games settings, e.g. video resolution, volume levels, etc. and also provide you with audio/visual feedback when you make choices, which requires keeping the audio engine running as well as rendering to the screen @ 60 fps.

And also that my “sound card works perfectly!”

I tell you what I'll do today on my dev time, I'll try implementing grayscale without aby research on pause and then compare notes (I'm assuming this wc code is available somewhere, which may be a bad assumption)

I'd honestly love to compile a book of "war stories" told by devs like netcoyote.

Maybe I will.

Net, if you're interested, hit me up.

And in the "this is why we can't have nice things", that also introduced problems, because we didn't want a player who was losing to keep pausing the game until the winning player quit out of frustration, so I think we kept a per-player pause counter, which would only be restored if other players also paused? (I don't quite remember all the details, just that we had to prevent yet another abuse vector).

In the article, there is a case where the game takes a screenshot and disable costly rendering, presumably to deal with this problem. But the thing is that most games are designed to to be actively played, not paused for extended periods of time and having an active pause for a couple of minutes isn't going to destroy the environment.

For backgrounding, is is common for games to run at a much slower framerate to save resources.