I personally wouldn't rely on determinism in Godot or being it a thing in the future, even lead developer expressed concerns about this.
There are some libraries which allow you to integrate your own fixed-point math to avoid floating point related errors (the use cases are not limited to physics):
libfixmath (C)
FixedMath.Net (C#)
So in this case you'd have to either provide needed typedef for real_t
in the source code directly (if that's even possible) to utilize fixed point math, or implement your own physics implementation I guess, which is not an option for most people.
Even if determinism (or rather lack of chaos) can be achieved locally, you'd still might encounter issues down the road regarding your solution being cross-platform, with never-ending compiler configurations out there to deal with floating point precision.
So as suggested by others, you'd likely want to come up with ways to efficiently store critical and update states in your game. It's not really practical to record the states every single frame so you'd want to record only a subset of states and then to apply interpolation when playing those back.
Another approach which I'm considering to try out myself is semi-relying on determinism by actually recording those input actions/events and recording occasional synchronization states at the same time. That way, the most optimal replication can be achieved by simulating game input (see parse_input_event()
, action_press()
methods) and replicating another bunch of synchronization states which can "catch up" to exact checkpoint state to eliminate any desynchronization at the moment.
Also see an in-depth discussion regarding node replication.
Reverse, where you can trigger a backwards sequence to get back to any point you want.
That's where mixing inputs with recording states is not a solution because if you do rely on determinism to play those states back, it's either not really possible or such rewinding won't be smooth anymore.