If your game state is entirely immutable, you're actually most of the way there.

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!

Did you follow a pattern for recording and tracking those class states? I stick to the business realm of our industry and Iv'e used a pattern called event sourcing that sounds kind of similar. Every update to an entity is an event and you can rewind/fastfoward any entity to a moment in time. It consumes a lot of memory/db space and if you don't snap shot occasionally, it's time consuming to build the events into a model so I'm curious what you use. Might give me some ideas.

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.

We use event sourcing in a business application.

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.

Sure, if you don't mind I'll get back to you tomorrow if that's OK.

Hope you don't mind if I listen in - fascinated by this area too :-)

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.

Around the time GGPO's source was published, I wrote a very, very simple fighting game to test how to use it. Maybe of interest to those in here: https://gitlab.com/DixieDev/ggpo_example/-/blob/master/main....

This is a great example! Thanks for sharing.