Hey Matlin, it's true that this approach is harder to implement, but that's a one-time cost, and it's one we take on for our users and they don't have to worry about.
We are targeting 100 concurrent users at 120 FPS. Not completely there, but it is certainly achievable, and we will scale back framerate when we need to.
So are you using fps management just for scaling purposes or also as a way of ensuring fairness? The reason I ask is because games like Forza have had to resort to setting all online players' frame rates to be the same regardless of their machine's capabilities due to the way the in-game physics work. PC players on high end hardware would consistently get better lap times than Xbox users because of it.
Maybe this is a bit out of scope of what the goal is for this project but just thought I would bring it up.
Huh! That's interesting. I don't think this applies to the type of collaborative apps (ie figma) we are targeting, but it's fascinating to know. Thanks!
Can you share how y'all made it fast? Obviously it can be made fast because multiplayer online games are living proof but I'm curious what it takes to get there or what's missing in my mental model.
What's your opinion on using this library as a base for (eg) a simplified "world-of-warcraft" clone?
I've done a lot of thinking (but not coding) around "simply replicating state" being the right answer to interconnected apps.
The degenerate case is to model everything as a git transaction log, but be able to run it "faster" than really using git. It's very intriguing to hear your discussion of "branching, sequentialization, etc..." because that seems like the right way to go. ( edit: and implicit _physics_ vs. state transfer in some cases... it's cheaper to send nuke@[x,y,z] instead of the literal calculations and changes to state that single action may imply ... physics in games maybe being gravity and ballistics, but 'business-physics' might be update/select/modify, etc. )
...eg: Unguaranteed, Guaranteed, Guaranteed Order, Most Recent State, Guaranteed Quickest (and each client has it's own "camera" / perspective against the "scene", where +180 might be "need it now b/c I'm looking at it", but -180 might be "meh, need close-to-the-latest-state before I turn around and look at it").
I'm rooting for you b/c "multiplayer + physics" seems like the right answer (eg: the ghost of couchdb), but no one seems to have (yet) cracked the semantic code as to how to describe "as fast as local, but synchronized with $THESE tradeoffs and $EXCEPTIONS".
