Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

kotaku.com

Post reply on HN
Print view View original

71–80 of 273 posts

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

#71

Post by RedNifre »

greazy wrote: post #32
vintermann wrote: post #8

One of the things that impressed me in Quake (the first one) was the demo recording system. The system was deterministic enough that it could record your inputs/the game state and just play them back to get a gameplay video. Especially given that Quake had state of the art graphics at the time, and video playback on computers otherwise was a low-res, resource intensive affair at the time, it was way cool. It always s…

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

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.

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

#72

Post by diath »

vintermann wrote: post #8

One of the things that impressed me in Quake (the first one) was the demo recording system. The system was deterministic enough that it could record your inputs/the game state and just play them back to get a gameplay video. Especially given that Quake had state of the art graphics at the time, and video playback on computers otherwise was a low-res, resource intensive affair at the time, it was way cool. It always s…

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

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

#73

Post by sikozu »

vintermann wrote: post #8

One of the things that impressed me in Quake (the first one) was the demo recording system. The system was deterministic enough that it could record your inputs/the game state and just play them back to get a gameplay video. Especially given that Quake had state of the art graphics at the time, and video playback on computers otherwise was a low-res, resource intensive affair at the time, it was way cool. It always s…

[dead]

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

#74

Post by krautsauer »

diath wrote: post #72
vintermann wrote: post #8

One of the things that impressed me in Quake (the first one) was the demo recording system. The system was deterministic enough that it could record your inputs/the game state and just play them back to get a gameplay video. Especially given that Quake had state of the art graphics at the time, and video playback on computers otherwise was a low-res, resource intensive affair at the time, it was way cool. It always s…

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

Or you bundle a copy of the engine and game content with every recording…

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

#75

Post by saulr »

Timshel wrote: post #68
eterm wrote: post #37

Earlier quoted context omitted.

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.

Guessing too much potential for abuse if the same server was handling both match and spectating.

Spectators don't watch the game on the same server that's hosting the game. The host server sends the traffic to a 'relay' on a delay, which spectators then connect to. Similarly for the HTTP streamed games, the game server is writing the data for spectators on a delay.

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

#76

Post by diath »

otikik wrote: post #61

So the simple case is using some sort of state variable: switch(game_state): case(paused): case(gameplay) You still have to be careful about how you implement "gameplay", though. For example if at any point you read the 'system clock' to do time-based stuff like animations or physics, then when you unpause you suddenly will have a couple minutes of advance in a place where you expect fractions of a second.

This is why delta time accumulator is preferred over using clocks, something like this would be best:

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

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

#77

Post by anonymous_sorry »

ndepoel wrote: post #51
vintermann wrote: post #8

One of the things that impressed me in Quake (the first one) was the demo recording system. The system was deterministic enough that it could record your inputs/the game state and just play them back to get a gameplay video. Especially given that Quake had state of the art graphics at the time, and video playback on computers otherwise was a low-res, resource intensive affair at the time, it was way cool. It always s…

It wasn't really that much to do with determinism. Quake uses a client-server network model all the time, even when you're only playing a local single-player game. What the demo recording system does is capture all of the network packets that are being sent from the server to the client. When playing back a demo, all the game has to do is run a client and replay the packets that it originally received from the server…

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 pause a game

#78

Post by kdheiwns »

danhau wrote: post #7
DeathArrow wrote: post #3

Not sure if slowing down time is the right approach. The best approach would be using something like if(game_is_paused) return; in the game loops.

The slowing down thing sounds like a hack needed for engines that don’t give you control over the main loop. 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…

Unity does this. You get scaledDeltaTime (when you set game speed to 0, it'll return 0) and unscaledDeltaTime (returns time between frames ignoring game speed). Pauseable logic uses the former. Pause menus use the latter.

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

#79

Post by stephbook »

vintermann wrote: post #8

One of the things that impressed me in Quake (the first one) was the demo recording system. The system was deterministic enough that it could record your inputs/the game state and just play them back to get a gameplay video. Especially given that Quake had state of the art graphics at the time, and video playback on computers otherwise was a low-res, resource intensive affair at the time, it was way cool. It always s…

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

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

#80

Post by Sharlin »

I would expect pausing to bring a game’s CPU/GPU usage down to near-zero, which won’t happen if the game keeps redundantly rendering the exact same frame. A game engine can optimize this by special casing time scale zero to simply render a single textured quad under the pause menu (which is probably what one of the commenters in TFA referred to).
Post reply on HN