Relevant: GGPO, the age-old gold standard of rollback netcode, was recently open-sourced!
https://github.com/pond3r/ggpo
I haven't used it myself yet - mostly because I'd want Haskell bindings first hah
https://github.com/pond3r/ggpo
I haven't used it myself yet - mostly because I'd want Haskell bindings first hah
I built a rollback multiplayer system in C#, and most of work goes towards having classes that are mutable, but remember their previous state so they can be rewound to any frame in the past second or so.
This involves enforcing invariants, persistent collection types, generating code to efficiently walk your entire game state, etc.
In Haskell, you just have a list of game states at the end of every frame, pick what you want and go.
Of course, you're not going to get C# performance this way, but you should still be able to build something pretty advanced if you give it a dedicated CPU core.
There are over a thousand people at this moment playing my indie web games built with rollback networking - if anybody has any questions, happy to answer them!
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.
Event sourcing, at it's core, is making sure your source of truth is a log of events and your app state is derived from that.
Beyond those constraints, there are many variations of how it can be done, each with very different tradeoffs.