Add a standardized way to track simulation time for interoperability about bevy HOT 3 OPEN

There's a few issues, but the main ones would be:

• You might be writing logic for an app that runs in either the FixedUpdate of a client or the Update of a server. But Time<Virtual> is not suitable to run a deterministic simulation.
• None of the clocks is supposed to be turned back, but this is necessary when synchronizing the clocks as well as for things like rollback.
• The units used for time are very unpractical for networked simulations, Duration is huge and difficult to deal with compared to a simple tick counter.

Even if someone decided to internally use Time<()> for their simulation tick, they would need to make a SystemParam containing a few other resources to work around these issues, this would in turn become yet another type lacking interoperability.

Adding this functionality to Time<()> would be another potential solution, but I'd imagine this would lead to confusing behavior with Time<Virtual> having ticks with a variable delta. It would also add one field that doesn't match with this line in the docs: The clock does not support time moving backwards, but I guess a Time<Simulation> would have the same problem.

from bevy.

Can you explain why Time<()> doesn't meet the needs of networking crates here? This was intended to be a standard "in-game-time", which worked correctly both inside and outside of the fixed update loop.

from bevy.

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 Time, a separate Time<Simulation>, or a simple stand alone resource + plugin similar to FrameCount). I'd imagine @maniwani also has some opinions on this, since it relates to fixed timestep simulations and networking stuff.

from bevy.