Changing FixedTimestep interval during runtime?

[demilich1]

Right now you specify the interval for FixedTimestep stages during App::build, i.e.

SystemStage::parallel()
                .with_run_criteria(FixedTimestep::step(0.1))

However, there is no way to change that rate afterwards. This is desirable for simulation type games (think Rimworld or Prison Architect); those usually offer different speed modes. You can run the whole game twice as fast when not much is happening or slow it down to half the speed when a lot is going on. Please note that this usually does not affect the framerate, just the speed at which the game logic is executed.

A nice way to implement this is to add all game-logic systems to a FixedTimestep and if the speed is increased, you just run those more frequently. I asked in Discord about this and it seems currently there is no way to do that in bevy. The suggested work-around is that I create my own RunCriteria which is basically a copy of the FixedTimestep but allows for changing of the step.

If there is an interest in that, I would be willing to open a PR and make that change upstream instead of only fixing my personal project. But I am not sure what the preferred approach would be.

You can already use mut timesteps: ResMut<FixedTimesteps> in a system, but that only allows for read access since FixedTimesteps::get() returns an immutable reference. It would be an option to add a FixedTimesteps::set_state(&self, name: &str, state: FixedTimestepState) function, but that alone would not solve the issue, as the state inside FixedTimesteps is never read back, so modifying it would do nothing.

So basically my question is two-fold:

1. Do you think users might find it beneficial to be able to change the fixed timestep during runtime?
2. If yes, what would be the cleanest approach for implementing such a behaviour?

[maniwani]

Adding a link to the above-mentioned Discord discussion.

I see no reason why the step rate shouldn't be runtime-mutable. The main thing is the API and documentation need to make it clear that changing this interval does not (and should not) change any "fixed_delta_seconds()" value developers would use inside their systems (to multiply velocities, step physics, etc.) as modifying that isn't numerically stable and can create unexpected behavior.

My suggestion would be to add a scale field and (maybe) a fixed_delta_seconds field to the Time resource. Then you could increase and decrease the step rate by simply changing this line from

self.accumulator += time.delta_seconds_f64();

to

self.accumulator += time.scale() * time.delta_seconds_f64();

That would make the app step faster or slower.

While we're at it, I would modify the FixedTimestepState to be more generic and better reflect this division of responsibilities. See below. Feeding the time and timestep as arguments to add_time is IMO more broadly useful than storing the step size internally. Here we're discussing scaling the frame delta time before adding it to the timestep accumulator. In the netcode PoC I'm working on (see rfc#19), I'm scaling the timestep argument instead. It'd be nice to simply reuse Bevy's implementation instead of having to provide my own.

The State::update function in fixedtimestep.rs would need to be modified to make use of these functions.

pub struct FixedTimestepState {
    time: f64,
    pub steps: usize,
}

impl FixedTimestepState {
    pub fn new(time: f64, steps: usize) -> Self {
        Self { 
            time, 
            steps
        }
    }

    // The number of accrued steps.
    pub fn steps(&self) -> usize {
        self.steps
    }

    // The amount of time (in seconds) accrued toward the next step.
    pub fn overstep(&self) -> f64 {
        self.time
    }

    // The amount of time (as % of timestep) accrued toward the next step.
    pub fn overstep_percentage(&self, timestep: f64) -> f64 {
        self.time / timestep
    }
    
    // Add to the stored time and then convert to as many timesteps as possible.
    pub fn add_time(&mut self, time: f64, timestep: f64) {
        self.time += time;
        while self.time >= timestep {
            self.time -= timestep;
            self.steps += 1;
        }
    }
}

impl Default for FixedTimestepState {
    fn default() -> Self {
        Self { 
            time: 0.0, 
            steps: 0
        }
    }
}

[demilich1]

That would be a rather simple, quick-to-implement solution. However, I see a couple of (potential) problems:

You could have independent FixedTimestep stages each with their own timer, i.e.

	.add_stage_after(
            CoreStage::Update,
            FixedUpdateStage,
            SystemStage::parallel()
                .with_run_criteria(FixedTimestep::step(0.1).with_label(FIXED_TIMESTEP_LABEL)),
        )
        .add_stage_after(
            CoreStage::Update,
            FixedUpdateStage2,
            SystemStage::parallel()
                .with_run_criteria(FixedTimestep::step(0.3).with_label(FIXED_TIMESTEP_LABEL_2)),
        )

If the scale factor exists globally in the Timeresource, you could never speed up only one of the stages.

Furthermore, if this scale factor were to be implemented in Time I would totally expect that it also affects the standard deltaTime. This is especially true for people coming from Unity, where the Time.timeScale property does exactly that. Now you are right that this might cause problems/unexpected behaviour with physics based games. But you can also find examples of games where this is not a problem and instead provides a cool and easy way to get a slow motion effect. I am not sure if the game engine should decide that for all developers.

In short I feel that one global scaling factor might not be good enough, we might want to do this per stage. But I might also be wrong and would like to hear other opinions on that topic.

[maniwani]

I'm not suggesting that this hypothetical time.fixed_delta_seconds be immutable at runtime, but I strongly believe that mutating it shouldn't be the default choice to achieve this kind of speed control (IMO "allowed but discouraged" is probably the best stance). There being games that chose to do so doesn't mean that the choice is a good one. The developers of those games may have simply not cared about the instability or didn't realize it could happen (it can be subtle). Unity using the same variable for the step rate and the physics step size is honestly pretty coincidental. Bevy can be smarter about it.

Likewise, Unity automatically scales its Time.deltaTime and provides a Time.unscaledDeltaTime, but it doesn't have to be like that. Bevy's Time could just continue to have the unscaled time.delta_seconds(), expose time.scale(), and leave it to the end-user to multiply with it if they want to. There might be reason to store the scale with the FixedTimestepState, though, instead of having just one.

I think the issue of not being able to use the same fixed timestep with multiple stages is a problem with how its run criteria is implemented, which is separately actionable.

Running more than one fixed timestep concurrently doesn't strike me as good practice. I don't see a niche for that (never seen that in any game engine tbh). Out-of-phase timesteps would have to be completely independent to make any sense of what happens when. In-phase timesteps would be better realized by just having some kind of "run every N steps" criteria. Async tasks are available for long running operations. And timers, tick timers, and multiplying by the time scale are probably better-suited for the remaining cases.

Just so you know, there will likely be a large redesign to the scheduler in the not-so-distant future. States and stages are almost definitely going to change a lot. Currently, states and "looping" run criteria in their current form don't play as nicely as they should, so I imagine the API around run criteria will change significantly as well.

[ManevilleF]

I like the time scale option a lot