Event sourcing is exactly what this is. The game state is built from a combination of initial setup parameters (random seed, level etc), and a list of player inputs.
I snapshot after every recent frame. The snapshots are stored in the game entities themselves via generated code. Each user accessible entity has a bunch of shadow slots it can copy from or write to. Then a higher level system sends each entity commands such as "store your state in slot 5" or "copy slot 3 over your current state".
Old snapshots aren't useful and are discarded. The server itself runs a few seconds behind the client states, does no rewinding, and any player that falls behind that will receive a fresh copy of the server's state.
Haha! That's exciting to see something like that shared across industries. I use it for medical health records to ensure we track every single change and know when something changed. Pairs really nicely with dynamodb in aws.
Could you talk a little about that or point to something that details the overall strategy? I'm considering a similar setup for event sourcing in AWS and DynamoDb with change streams crossed my mind.
I've actually used Datomic to do backend development before, and it's really interesting to contrast two frameworks that are built around very similar ideas, but with vast differences in requirements and implementation.
I snapshot after every recent frame. The snapshots are stored in the game entities themselves via generated code. Each user accessible entity has a bunch of shadow slots it can copy from or write to. Then a higher level system sends each entity commands such as "store your state in slot 5" or "copy slot 3 over your current state".
Old snapshots aren't useful and are discarded. The server itself runs a few seconds behind the client states, does no rewinding, and any player that falls behind that will receive a fresh copy of the server's state.