Yeah, Rust is temping, but I’ll pass for now. It’s too new, and I have no desire to deal with the funsies of compiling anything exotic on PS4, XB1 and Switch.
My main focus is finding the sweet spot between:
- Making it hard to break determinism
- Usability for designers
- Performance
Prioritized in that order. The rough plan is:
- Use blueprints with nativization. BP allows enforcing tight restrictions by using contexts and metadata, so I can limit the functions that can be called. This helps with #1 and #2.
- Simulation functions receive the previous frame entity state struct and must output the new state. No dealing with UObjects, no mutable state. This allows me to update entities in parallel (#2) without breaking determinism (#1). State is basically component data as in ECS, can be stored in arrays and will make it easier to do rollbacks, since I can just keep the states from previous frames around.
- Use message passing for interaction between entities. Simulation function posts messages, which are then read by the recipients at the appropriate time deterministically. Some work will need to be done here to keep delays from creeping in (messages being received 1 frame late).
- Every frame the current state of all entities is “rendered” using standard components/actors. This separation eases the burden during rollbacks, as it only ever happens once per frame even if the rollback caused multiple re-simulations, and enables running the simulation at a fixed time step while the “display” actors/components show interpolated data.
If I can get all of that working without any engine modifications, I might put it up on the marketplace.