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.