Auditing determinism #2480
Replies: 5 comments 9 replies
-
Notes on cross-platform floating point determinism from @james7132:
|
Beta Was this translation helpful? Give feedback.
-
One other sticking point here is education. The benefits of a deterministic game engine is not common knowledge, nor is the responsibility solely on the engine maintainers, so if this is to be a major selling point for Bevy, useful examples and and well-worded justification may be needed. Finally is ease of use to enable these features. IMO, there should at least be an optional |
Beta Was this translation helpful? Give feedback.
-
I am very interested in Bevy determinism. System execution order and to a lesser degree entity iteration order seems like the big issues. For sum checking is Sse4_2 Crc32C deterministic? I would think it would be. |
Beta Was this translation helpful? Give feedback.
-
This is probably off-topic, but to me it's interesting and relevant, and maybe relevant here. I post in the spirit of "would this work?" (while feeling unqualified to interject 😄) I have done a lot of "hobby" grade n-body gravity simulation experimentation, usually involving Bevy. For my use-case, I wondered if I could assume and start with rational XYZ coordinates, do all the newtonian math and handle irrationals symbolically. For example, I think I'm saying: One could extend the field of rational numbers with irrational roots, In the above case, one should only be dealing with roots of the form I've got a simple [simple!] nugget of the idea here https://github.com/stnbu/qpow [just an idea/bevy is cool] |
Beta Was this translation helpful? Give feedback.
-
Why Not Both? Game Logic vs View LogicI want to ensure we consider allowing a mix of determinism and non-determinism, with a clean separation between the two. Consider the separation of a render mesh and a physics mesh. In many games the physics might win the cost-benefit analysis for determinism, but the rendering might not. There are many architectures like MVVM/MVP that separate game or business logic from view or presentation logic, with well documented advantages, however here I'm presenting them as a boundary for determinism. You likely care more about determinism in the game logic, and care more about speed in the view logic. Match-3 ExampleIn the simple but concrete example of a match-3 game your architecture might have a low update rate grid-based state machine for the main game logic and model, and variable framerate non-grid aligned flashy effects in a view model on top of that. The game model is essentially a state machine with a 2-dimensional array. Determinism matters here, as this is the core logic of the game, and you want to be able to test and verify various states, and transitions. The view and view model is things like dropping animations, match effects, sound, music, and ui interaction. A large part of the view model is directly derived from the game model, it's essentially an animated visualisation derived from the state machine's transitions. It doesn't have as many advantages from determinism, and will likely just have performance issues from it. This is because generally it runs at a much higher or variable frame rate, directly reflects high frequency user input, or is computed from the deterministic model. Granted Possible Feature Flag SolutionTo support a mix of determinism a feature flag should not necessarily be all-or-nothing. One possible solution would be to expose deterministic and non-deterministic versions, for example Clean Separation SupportI don't think it makes sense to force a seperation of view and game logic on bevy users, but I'd love to have better support for those kinds of architectures. I'm interested to explore the idea of supporting a |
Beta Was this translation helpful? Give feedback.
-
Determinism is important for reliable tests, (lockstep) networking and scientific simulation (#1678) in Bevy.
There are several key sources of non-determinism that we need to carefully iron out (for at least some users and scenarios):
Commands
andEventReader
evaluation order. Currently these are both fixed by the topological order of the system execution, so solving 2 would solve this.Solving this needs to be a concerted, organized effort in both Bevy and its dependencies: individual developers are not empowered to reasonably make the changes needed on a per-game basis.
Tools to build out:
cargo test
chokes on both GPU support and multithreading)Engine fixes to make:
Engine features to build
Beta Was this translation helpful? Give feedback.
All reactions