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.

Games are multithreaded and have loads of objects running everywhere. If you're using anything that's not a custom game engine, there really isn't a single main() function that you can plop an if statement like that into.

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

▲

flohofwoe 2 days ago | parent | prev | next [-]

It's usually not as simple as that. You'd still want to at least keep the UI alive, and you also need to continue rendering while the game is paused because the swapchain surfaces might lose their content (window resizing, changing the display mode, alt-tabbing to the desktop etc).

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.

	▲	qwery 2 days ago \| parent [-]
		Yep, this comment does a good job of illustrating the (surprising) complexity of this. I'll add that the notion of the "time scale" variable as mentioned in the article is something that's only solidified/codified since Unity and the like came about. And at the same time, the way Unity et al. works[0] doesn't really encourage thinking about what I'd call "main loop logic" in the bottom-up way that's required to build a really robust system for managing states. You can do it, of course, (you can write as much code as you want) but by default, everything in the scene is "active" and somewhat independent from everything else, and you don't have direct control over the various major systems. [0] I guess I should say "worked" -- I mostly used 3.x and a little bit of early version 4 -- I'm sure it's improved but I wouldn't expect anything drastically different.

▲

danhau 2 days ago | parent | prev | next [-]

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, UI animations).

	▲	torginus 2 days ago \| parent \| next [-]
		I don't think it's a hack necessarily - as a well implemented time system would produce the same results at game rate = 0 as with pause. Also there's a need for different time domains - like imagine, in a paused state the menu animations still need to play, or if the player enters a conversation, the game logic needs to pasue (depending on designer intent etc.)
	▲	kdheiwns 2 days ago \| parent \| prev [-]
		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.

▲

daemin a day ago | parent | prev | next [-]

A surprising number of systems break down if you pause time by passing a 0 time delta, hence why slowing down time is usually the thing that gets done. The alternative (which you imply with your suggestion) is to pass the many paused states down to every system which further complicates their implementation and is a major source of bugs.

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.

▲

astrobe_ 2 days ago | parent | prev [-]

It depends on how your timers are implemented. If they are implemented as a "rendez-vous" absolute date (as in UTC for instance - not in local time unless you want to add "eastern eggs" related to daylight saving time...), this will cause bugs. If you implement your own in-game monotonic clock that you can stop, it should be ok.

▲

sweetjuly 2 days ago | parent [-]

>If they are implemented as a "rendez-vous" absolute date

Do people actually do that? What's the plan for when the user sleeps their machine? All the events just inexplicably happen all at once when they wake it?

	▲	stoltzmann 2 days ago \| parent \| next [-]
		I've implemented timers that had timeouts using unix timestamps, but only for multiplayer - when a player's attempt to connect to the server times out, etc. Inside the game loop, we would keep the global tick counter that incremented on every tick, and timeouts would be based on that rather than on UTC. The tick counter was updated only when the game logic was actually running. Our approach to pausing was to not run the functions that handled frame updates or physics updates, and to only run the rendering functions. Generally we would never care about actual world time other than for some timeouts like for network (as the time passes for everyone), or for easter eggs like changing the tree models for Christmas or so. I don't think anyone serious would implement event timers based on real time.
	▲	astrobe_ 2 days ago \| parent \| prev [-]
		That's sort of the point TFA. You make implementation choices that feel OK and then the time comes to implement the "trivial" pause function... In other domains, adding the delta time of your main loop to your timers can cause (logical) clock drifts in the long term because of resolution errors.