bevyengine / bevy

A refreshingly simple data-driven game engine built in Rust
https://bevyengine.org
Apache License 2.0
36.34k stars 3.58k forks source link

Native Tick Timers #1633

Open alice-i-cecile opened 3 years ago

alice-i-cecile commented 3 years ago

What problem does this solve or what need does it fill?

Tick based timers are timers that operate not on real time, but on the number of state updates that occur. Each state update constitutes a "tick".

For any timer that does not update outside a game session, a tick based timer is preferred. This makes games more consistent and replayable (which also means they are easier to debug).

From the bevy_tick_timers crate.

There are three arguments for moving this in-tree IMO:

  1. Ensure API consistency and stability.
  2. Encourage beginners to use tick-timers for most gameplay, rather than more complex and flaky real-time timers.
  3. Allow us to use tick-timers internally, such as for delayed state chart transitions (see #1597).

What solution would you like?

Borrow from @maplant's solid foundation and create a Bevy drop-in-replacement for ordinary real-time timers.

What alternative(s) have you considered?

Continue to rely on a third-party library. I've argued above why I think this is inferior.

Additional context

None.

maplant commented 3 years ago

I'm very glad that you found it useful! Take whatever you need from the repo. Because you're integrating it directly into Bevy you could consider using it as a wholesale replacement for the current schedule, a notion I wrote up about here: https://github.com/maplant/bevy-tick-timers/blob/master/about-tick-timers.org#a-timer-based-approach-for-scheduling I think that the effort and amount of changes would probably make it not worthwhile, however it does have the nice property that single use timers can take self: Box<Self> and thus can move items out of their struct without mem::replace, while timers that continuously rerun still take &mut self.

Let me know if you need any help from me!