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

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

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)

And also that my “sound card works perfectly!”

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

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

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.

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)

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

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

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.

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.

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.

It’s one of my favourites

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

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

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.

https://en.wikipedia.org/wiki/ScriptX

So time scale 0 meant paused relative to the parent time scale, and time scale -1 meant time flowed backwards, which was actually quite useful!

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

DonHopkins on Aug 18, 2024 | root | parent | next [–]

The QuickTime API supported reverse play around 1993 or so, when I enjoyed using it for "back and forth" animated sprites, and playing music videos backwards to reveal the satanic messages with demonic backmasking.

Reverse / Backwards Moonwalk - Michael Jackson - Better Than The Original!!!

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

Here's the documentation and code I wrote when working at Kaleida Labs (a joint venture of Apple and IBM) on a ScriptX animation library that used QuickTime and other renderers, and depended on QuickTime's support for playing videos backwards, and single stepping forward and backwards of course:

ScriptX Animation Library:

https://www.donhopkins.com/home/catalog/lang/scriptx/anim.ht...

ScriptX Animation Implementation Module:

https://donhopkins.com/home/archive/scriptx/animimp.sx

ScriptX's QuickTime renderer would even play audio backwards and at whatever speed, too. ScriptX had excellent multimedia clock synchronization, and we would have considered it a terrible bug if ScriptX was not able to seamlessly and transparently synchronize video and audio with any arbitrary clock, time offset, and time scale, no matter what the speed and direction.

I'm sad that 31 years later, web browser video and audio players (not to mention VLC) don't support hierarchical clocks like ScriptX did for multimedia synchronization. (Each child clock can have a time offset and time scale relative to its parent, and everything's automatically kept in sync, from the simulation to the renderer.)

Here is Kaleida's (then Apple's) 1993 patent on "Synchronized clocks and media players", which has long since expired in 2013:

https://patents.google.com/patent/US5452435A/en

>Abstract: A media player and the clock which controls it are integrated into a single object. This integration may be achieved by the construct of inheritance between objects in an object oriented programming environment. A software class for player objects is established which inherits from a software class for clock objects. In this way, a player "is a" clock. This integration provides improved synchronization among different media, and simplifies design of applications which employ player objects and clock objects. Each object is synchronized to a RootClock object which operates at the speed of the fastest media player in the system. The RootClock may be separated into "low" order and "high" order components and a compare register in order to reduce interrupt overhead.

>[...] QuickTime essentially allows a multimedia player to process timebased data. Since the data are time based, QuickTime provides for the description of "time" (called time basis) for the data as well as a definition of the context for evaluating that "time." In QuickTime, a movie's or media's time basis is called its "timebase."

>A timebase is essentially a vector that defines the direction and velocity of time for a movie or media. The context for a timebase is called its time coordinate system. Conceptually, a time coordinate system provides an axis for measuring time. The time coordinate system, like a geometrical axis, is divided into units of measurement by a measurement system, called a time scale. [...]

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

DonHopkins on Dec 29, 2018 | parent | context | favorite | on: Steve Jobs hired a career juggler to teach program...

Oh, of course I wish Apple and IBM had made it free! But it included Apple's "crown jewels", the QuickTime player source code, and they were't going to give that away in 1995. Apple were even trepidatious about IBM having access to that source code.

Besides having proprietary decoders, it could also do some things you can't even do well with the Flash player or html video component today: like smoothly playing videos and music backwards!

Ever since the music industry switched from vinyl to CD, listening to demonic backmasking in Devil Music like the Beatles and Led Zeppelin's promotion of Satanism became much less convenient. ScriptX solved that important problem elegantly with its synchronized clock system, but today's HTML video player still hasn't, alas.

https://en.wikipedia.org/wiki/Backmasking

https://www.youtube.com/watch?v=5BDh_j5qAJ4

Here's a description of ScriptX's clock system:

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

>Kaleida Lab's ScriptX (a multimedia programing language kinda like Dylan with classes) had built-in support for hierarchal clocks within the container (in the sense of "window" not "vm") hierarchy. The same way every window or node has a 2D or 3D transformation matrix, each clock has a time scale and offset relative to its parent, so anything that consumes time (like a QuickTime player, or a simulation) runs at the scaled and offset time that it inherits through its parent container. And you can move and scale each container around in time as necessary, to pause movies or simulations.) You could even set the scale to a negative number, and it played QuickTime movies backwards! (That was pretty cool in 1995 -- try playing a movie backwards in the web browser today!)

Is it possible to play HTML5 video in reverse?

https://stackoverflow.com/questions/5277293/is-it-possible-t...

Kinda, but it's not smooth enough to sing along while dancing backwards and worshiping Satan to:

https://codepen.io/adrianparr/pen/qmCek

    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();
    }

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.

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

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.

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

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.

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

The added fact is that many systems still need to continue running, such as audio, video, and input otherwise the program doesn't appear to respond to input and so isn't in a useable state any more.

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.

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.

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.

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