Skip to content

Allow use of systems for custom time handling #15455

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
maniwani opened this issue Sep 26, 2024 · 1 comment
Open

Allow use of systems for custom time handling #15455

maniwani opened this issue Sep 26, 2024 · 1 comment
Labels
A-Time Involves time keeping and reporting C-Feature A new feature, making something new possible D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it!

Comments

@maniwani
Copy link
Contributor

maniwani commented Sep 26, 2024

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.

Footnotes

  1. That being said, I do strongly recommend adding the behavior described in #12465 as a preset for Time<Fixed>.

@maniwani maniwani added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled A-Time Involves time keeping and reporting and removed S-Needs-Triage This issue needs to be labelled labels Sep 26, 2024
@alice-i-cecile
Copy link
Member

Related requests for more Time customizability:

#12465
#14215
#15409

@BenjaminBrienen BenjaminBrienen added S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it! D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes labels Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Time Involves time keeping and reporting C-Feature A new feature, making something new possible D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Ready-For-Implementation This issue is ready for an implementation PR. Go for it!
Projects
None yet
Development

No branches or pull requests

3 participants