Caterpillar

The approach I introduced yesterday should be a good baseline, but to make rewinding truly good, there are more things to consider.

First off, we don't have to handle all events in a special way. Some events can be undone, just like instructions, if we've logged the data required to do that. An example of that would be writing to memory (which, for Caterpillar, counts as I/O). Another could be sound effects, which you probably could just ignore, or if you want to get fancy, play backwards when undoing them.

Graphics are interesting. In a typical game, you have many small operations that draw things, but you don't actually show any of that until the end of the frame, when you present the whole thing at once. Rewinding more than a few frames might not be practical, due to memory use. And it would be better to show the results of every single draw call anyway. Sounds complicated, but also worth doing.