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.
the notion of using time directly in gamedev has always confused me; it feels like the correct answer should be to simply have a notion of turns, and a real-time game simply iterates over turns automatically. And then so many turns are executed per second
It's a simulation; why should clock time be involved to begin with? The only things that should care about clock time are those that exist outside the sim, e.g audio
Simulation can proceed in logical time but animation is necessarily tied to wall clock time in order to be perceived as smooth and consistent by a human viewer.
In that case, animation belongs to the same category as audio — it exists outside the simulation state.
But I’m not 100% that’s even true; in the context of replay, I imagine it’d be more appropriately part of the sim for it to scrub properly.
In the context of networked games with client-side prediction, I think it’d probably be key frames tied to logical time and intermediate frames tied to wallclock
This gets bugged if it takes longer than one tick to run an iteration of game loop. Afaik the typical solution is to have a maximum number of iterations that you'll run and reset accum if it exceeds that.
switch(game_state):
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.