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 2 days ago | parent | next [-]

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 2 days ago | parent [-]

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 2 days ago \| parent [-]
		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 2 days ago | parent | prev | next [-]

That's exactly how I do it. Makes the most sense to me.

▲ AlienRobot 2 days ago | parent | prev [-]

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.