thebluefish / bevy_contrib_schedules Goto Github PK

The final part of this article (Gaffer on Games) deals with interpolation to get rid of undesirable stutter. It explains the reasoning for this better than I could.

You could provide some sort of API to query how much time remains in the accumulator for a schedule - or rather, it would probably be more suitable just to provide the fraction (let alpha = accumulator / timestep).

Then, an end-user is responsible for tracking current and previous state and interpolating between them, e.g.:

struct Position(Vec3);
struct PreviousPosition(Vec3);

// after the physics simulation, within the main schedule
fn before_render(
    schedule_runner: Res<ScheduleRunner>, // Fixed Schedule, provided as a resource
    query: Query<(&mut Transform, &Position, &PreviousPosition)>,
) {
    let alpha: f32 = schedule_runner.alpha(); // example API, calculates `accumulator / timestep` (only for schedules with fixed timesteps)
    for (mut transform, new_position, previous_position) in query.iter_mut() {
        // position and previous_position were updated by our physics simulation
        // transform determines where the sprite will actually render
        // below is equivalent to: transform.translation = previous_position.0 * (1.0 - alpha) + new_position.0 * alpha;
        transform.translation = previous_position.0.lerp(new_position.0, alpha);
    }
}

In addition to Fixed and Always ScheduleRunners, provide an EventDriven variant, which could make use of Bevy's Events system to determine when it should run.

Main use-cases: turn-based games of various types, such as rogue-likes. In a turn-based game, the "game tick" is not time-based but event-based, i.e. it is in response to some action taken by a player. The idea here is that you could write gameplay code that simply advances the game state from turn N to turn N+1, no different to advancing from frame N to frame N+1 for rendering, or simulation tick N to simulation tick N+1 for physics, but this would be decoupled from the rendering / input itself so it would be fully interactive.

Looking through your code, I believe there may be some overlap between this approach and the manual runner approach you're looking into. Although I believe both would be useful to have, I believe an event-driven approach may cover a great many of the use-cases that a manual runner approach would be useful in. As events are a first-class Bevy system, this event-driven approach could be fairly easy not only to implement, but especially for end-users to make use of in their games.

Take a scenario where you would like to pause the game (e.g. when opening a settings menu). The simulation should also pause (i.e. not execute).

Existing alternatives:

• Drop the schedule on pause. Re-create the schedule on resume.
• Set up a GameState resource. Every simulation tick, for every system in the schedule, check some GameState resource to see if the code within should run or not.

Both of these options have a lot of moving parts, so a cleaner API that allows you to pause the execution of a schedule directly would be nice.

Great work on this library. I think it solves a few common problems and does it in an elegant way. I've got a series of feature requests (which I'm also happy to work on if you're open to it), which I'm sending through now. First up, clamping the frame time.

There should be provision for clamping the frame time when creating a fixed ScheduleRunner.

From this article (Gaffer on Games): In the very last code sample, there were these lines, which had no explanation:

        if ( frameTime > 0.25 )
            frameTime = 0.25;

If you run a big enough simulation, however, you'll run into this issue:

1. The computation time is longer than the frame time.
2. The next frame is delayed, increasing the frame time.
3. With more frame time, there are more simulation ticks.
4. With more simulation ticks, the computation takes longer.
5. The next frame is delayed, further increasing the frame time.
6. And so on, until the app slows to a crawl.

Clamping the frame time ensures that "real time" doesn't "run too far ahead" of the frame time for the simulation to catch up. If the simulation does begin to fall behind, clamping limits the size of the gap (the number of ticks becomes constant). Even if this does slow down the simulation, the simulation itself will still be deterministic, and a slower simulation is probably preferred to total non-responsiveness.