What problem does this solve or what need does it fill?
Bevy is pretty great at handling time (time.delta_seconds() just working in both variable/fixed timestep is some nice UX that other engines don't really have) , but it'd be even better if users could simply take complete control of time for advanced usecases.
Time handling (especially fixed update) is still a bit clunky in a few noticeable ways.
- External events like input don't carry any timing information, so there's some aliasing happening.
- There is no automatic or built-in tool (such as interpolation) to smoothly render state that updates in
FixedMain.
- Some users (e.g. networking plugins) would like to control when
FixedMain runs but are unable to do so.
- Some users would like to disable
FixedMain entirely but are unable to do so.
What solution would you like?
Instead of going down the path of adding more parameters and preset1 behaviors to address these issues, Bevy could address the root problem of "time isn't configurable enough" by reworking time_system and run_fixed_main_schedule to call other systems that implement the actual behavior, e.g. based on "call this Entity" values stored in a publicly visible resource.
pub fn time_system(world: &mut World) {
let res = world.resource::<BikeshedMe>();
let system_id = res.system_id();
world.run_system(system_id);
}
By turning time_system and run_fixed_main_schedule into dispatchers, a user could control how time is handled by creating their own "one-shot" systems and setting them as the systems that get called instead of the default ones.
What alternative(s) have you considered?
- The time plugin could keep packing more and more configurable parameters into "official" components/resources.
- I wouldn't like this solution because it puts the onus on Bevy to keep adding and documenting them.
- The time plugin could let users provide
time_system and run_fixed_main_schedule as configuration.
- I wouldn't like this because it's important to be able to control the behavior at runtime. Other plugins or the editor might want to take control, not just the end user.
I think my proposed solution is more idiomatic and "ECS-y" (systems define behavior) and would let Bevy draw a clear line between "simple" and "advanced" configuration. Any behavior that isn't baked into one of the Time structs would become "advanced use" that users can achieve by overriding the default targets.
Additional context
IMO this is sort of a logical continuation of #8964. That one made whoever's calling (Main or FixedMain) transparent to the systems that are called. This would makes whoever's advancing Time and calling FixedMain transparent.
What problem does this solve or what need does it fill?
Bevy is pretty great at handling time (
time.delta_seconds()just working in both variable/fixed timestep is some nice UX that other engines don't really have) , but it'd be even better if users could simply take complete control of time for advanced usecases.Time handling (especially fixed update) is still a bit clunky in a few noticeable ways.
FixedMain.FixedMainruns but are unable to do so.FixedMainentirely but are unable to do so.What solution would you like?
Instead of going down the path of adding more parameters and preset1 behaviors to address these issues, Bevy could address the root problem of "time isn't configurable enough" by reworking
time_systemandrun_fixed_main_scheduleto call other systems that implement the actual behavior, e.g. based on "call thisEntity" values stored in a publicly visible resource.By turning
time_systemandrun_fixed_main_scheduleinto dispatchers, a user could control how time is handled by creating their own "one-shot" systems and setting them as the systems that get called instead of the default ones.What alternative(s) have you considered?
time_systemandrun_fixed_main_scheduleas configuration.I think my proposed solution is more idiomatic and "ECS-y" (systems define behavior) and would let Bevy draw a clear line between "simple" and "advanced" configuration. Any behavior that isn't baked into one of the
Timestructs would become "advanced use" that users can achieve by overriding the default targets.Additional context
IMO this is sort of a logical continuation of #8964. That one made whoever's calling (
MainorFixedMain) transparent to the systems that are called. This would makes whoever's advancingTimeand callingFixedMaintransparent.Footnotes
That being said, I do strongly recommend adding the behavior described in #12465 as a preset for
Time<Fixed>. ↩