3 ms·

So the simple case is using some sort of state variable: switch(game_state): case(paused): <the paused logic goes here> case(gameplay) <updatin

by otikik 6mo ago

So the simple case is using some sort of state variable: switch(game_state): case(paused): <the paused logic goes here> case(gameplay) <updating entities and regular gameplay goes here> 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.

diath 6mo ago
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(); }
- setr 6mo ago
  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
  - maxbond 6mo ago
    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.
    - setr 6mo ago
      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
- usea 6mo ago
  That's exactly how I do it. Makes the most sense to me.
- AlienRobot 6mo ago
  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.

by otikik 6mo ago

diath 6mo ago

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

setr 6mo ago
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
- maxbond 6mo ago
  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.
  - setr 6mo ago
    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
usea 6mo ago
That's exactly how I do it. Makes the most sense to me.
AlienRobot 6mo ago
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.