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
Add a standardized way to track simulation time for interoperability #13306
Comments
Third-party rollback crates need decrement operations. This is why they using their own ticks and convert them back and forth. It's not convenient. Just providing decrement operations to resource would be weird since user should never decrement it. This is why I made `RepliconTick` into a simple struct and use a dedicated resource called `ServerTick` for tracking current simulation tick. See also bevyengine/bevy#13306
Third-party rollback crates need decrement operations. This is why they using their own ticks and convert them back and forth. It's not convenient. Just providing decrement operations to resource would be weird since user should never decrement it. This is why I made `RepliconTick` into a simple struct and use a dedicated resource called `ServerTick` for tracking current simulation tick. See also bevyengine/bevy#13306
Can you explain why |
There's a few issues, but the main ones would be:
Even if someone decided to internally use Adding this functionality to |
If there's interest in this I could pick this up once we have an idea of what it should look like (eg. part of |
What problem does this solve or what need does it fill?
There is currently no universal way to track the time of a running simulation. If it's just needed in user code it's simple enough to create a resource that tracks the number of ticks since the simulation started and use some constant for timesteps. However, when third-party plugins get involved there is no good interoperable solution. Some crates provide their own type, resulting in some vendor lock-in. Other crates can be configured for where to source their time, making them harder to set up.
These types are further complicated by conflicting needs of different crates. A networking crate most likely has a counter it only needs to go up, but a rollback crate depending on that networking crate would need it to also go backwards.
What solution would you like?
A centralized way to track the time in a simulation. It could be a fairly simple type like:
It could either be it's own thing or a variant for
Time
, asTime<Simulation>
. Incrementing it could either be left up to the user, or configured in a more out-of-the-box way like deciding between FixedUpdate and the main loop depending on the app's runner.The tick value could also be a newtype on
u64
(oru32
) so it's clear what these values mean if they are requested in function signatures or stored in other types (for example storing the tick on which an event happened).What alternative(s) have you considered?
Time<Fixed>
, but this wouldn't be ideal for apps that run at a fixed rate without FixedUpdate.Additional context
Here's a few crates that deal with some sort of simulation tick:
ggrs
bevy_replicon
lightyear
bevy_bundlication (disclaimer: I wrote this crate, the next version will likely also no longer have this type since it has been rewritten as a layer on top of bevy_replcion)
The text was updated successfully, but these errors were encountered: