Allow use of systems for custom time handling #15455
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!
Uh oh!
There was an error while loading. Please reload this page.
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
.FixedMain
runs but are unable to do so.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
andrun_fixed_main_schedule
to call other systems that implement the actual behavior, e.g. based on "call thisEntity
" values stored in a publicly visible resource.By turning
time_system
andrun_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?
time_system
andrun_fixed_main_schedule
as 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
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
orFixedMain
) transparent to the systems that are called. This would makes whoever's advancingTime
and callingFixedMain
transparent.Footnotes
That being said, I do strongly recommend adding the behavior described in #12465 as a preset for
Time<Fixed>
. ↩The text was updated successfully, but these errors were encountered: