> Specifically, I tried to recreate Braid's system (without knowing it existed), where you can rewind your game to any point in time. It required support from all the engine's subsystems - to rewind scripts, physics, etc.
Not necessarily.
You can write your own "snapshotable allocator" that allows you to rewind back in time anything, even the state of unmodified 3rd party libraries and interpreters (as long as you can configure them to use your allocator).
Feels like fiddling with snapshotting raw C++ memory is a can of worms (you listed some of the pitfalls yourself). Most of my snapshotting happened at the scripting runtime level, where everything is well-defined and well-understood: I manually snapshotted the VM's heap memory, the green threads' stack memory, the current instruction pointer of every green thread etc. I could safely validate those snapshots without segfaulting on a corrupted savefile, because it was a well-defined file format. The same code worked both as a time-travel snapshotter and as a general savefile format.
I think this is dangerous and can lead to remote execution attacks:
>The snapshot could even be exchanged over the network, assuming the receiving side has the same endianness, the same pointer size, is running the same binary, and can mmap the same memory location.
For physics, I needed to restore all those remembered motion vectors; for audio - current playback time, etc. Same as yours:
>The rest of the memory (the textures, the 3D models, the audio, the UI, etc...) should be allocated by your usual non-snapshotting allocator"
Not necessarily. You can write your own "snapshotable allocator" that allows you to rewind back in time anything, even the state of unmodified 3rd party libraries and interpreters (as long as you can configure them to use your allocator).
I wrote about it in https://www.jfgeyelin.com/2021/02/a-general-state-rollback-t...