I'm curious how your engine decides to trigger rollbacks without explicit knowledge of which parts of the game state each input can actually affect. Naively rolling back on every missed input can and will be abused - in early versions of Street Fighter V players found out that while being comboed you could churn out inputs as fast as possible to cause rollbacks for your opponent, even though none of those inputs could actually do anything (this was made worse by other issues with that game's inability to keep opponent game clocks synced and constant one-sided rollbacks).

Pretty cool work, kudos!

This was exactly the premise behind the multiplayer SDK I made[1] but I moved to a middle ground (after feedback from devs) so to support existing languages and game engines single player game devs are familiar with but still easier than many other options out there.

We have now scaled it to many millions of players and it has proved worthy!

1. https://joinplayroom.com

How do you handle hidden information, or "need to know"/"potentially visible set" style revelations to player clients?

This is all very impressive and combines ideas I tinkered with in C on and off for years, into a cohesive product. Very impressive.

WASM-4 has a simiar multiplayer model. There's some things you still have to be careful with, like delaying screen transitions so you don't have a "you win" screen flash for a few frames when the other player didn't lose but their input hasn't gotten t o you yet.

A few quick q's, since I'm working on a game with a hand-rolled rollback impl (we have state copying, so we can do some nice tricks):

- Is there anywhere we can follow you about the clock-sync trick? I'd definitely love to be notified - On the adaptive delay, are there gameplay or rollback engine implications to variable delays? Seems somewhat "unfair" for a player to be penalised for poor network conditions, but maybe it's better than them teleporting around everywhere.

Good luck with the project! I'll hopefully have a fiddle around with it soon :)

Speaking of async coroutines, my belief is that they don't get used enough in other game engines because their lifetimes are not tied to anything - you have this danger where they can outlive their entities and crash your game.

Async coroutines in the way you are describing have terrible/unpredictable cache/memory access behaviour which leads to bad performance. Every time you switch coroutines you need load memory from (most likely) an unrelated region causing slowdowns.

I exclusively make games that include online multiplayer, so this really caught my eye. Really looking forward to digging in.

How do you abstract away the multi tenancy for your developer/user? As in different rooms or instances. Or similar. I'm asking because I'm building a visual development tool for web apps, and all such abstractions, as in computer powers to non developers, are interesting for me to see how they are done.

How does this compare to something like BYOND? I realize it’s dated now but conceptually there are some similarities.

If I created a game in this, what gurantee do I have that someone will be able to play this game in 100 years?

This is cool, but its hard to make a game engine full featured enough to be worth developing for. Have you thought about making this an addon for another engine like Godot or Bevy? Godot in particular is a nice engine to develop on, but the multiplayer support could be improved.