Really fascinating approach to build real-time multiuser apps and games:
More info here: Croquet - Docs
2 Likes
This does look interesting but unfortunately a little bit like vaporware too. I can’t find any documentation on how they intend to address the most common Fallacies of distributed computing, ie. “The network is reliable” and “Latency is zero”.
As explained in the video all their reflector does is provide total ordering of messages so every client executes them in the same order. What happens if you are on a spotty WLAN connection and your networks drops out from time to time or goes to very high latency? I’d assume your app becomes unusable and locks up since it can’t do anything anymore?
I mean online games have had this issue for decades and most use custom protocols built on UDP for networks messages rather than TCP. Given that a browser can’t do that I’d argue that you cannot achieve the necessary performance you’d want here. I certainly don’t want the usual “lag” in my web UI?
This comes to mind 
1 Like
Not sure, but the team behind it seems to have the creds to pull it off.
It reminds me a bit of lockstep networking in fighting games. You have delay based netcode, instead of lagging, it delays your inputs until the input from other users is received for that given frame. You could say it is still lagging, as in, the UX looks unresponsive or delayed from when you press the button, but at least every user is in-sync with each other, so there’s no lag in the sense of being out-of-sync with others. That said, it needs to guess the delay, and if it guesses wrong as network fluctuates, you’ll need to freeze up the game, so there is still possibility for lag.
But, you have a more sophisticated method called rollback netcode, where your own input is always applied locally and immediately, keeping your game feel responsive and smooth at all times, but if input from other players come in late, the game rollbacks the state and replays their inputs and your inputs in the right order. Visually, it means what you currently see could suddenly change slightly as inputs are replayed in the case of a rollback, but at least nothing ever locks up and your inputs are always responsive. This is often even smart and tries to predict other players input or can ignore inputs from others that don’t alter the game state, etc. Finally, they always combine this with delay as well, so they check the connection with others, and assess a constant delay on which anything slower will have rollback applied, that limits how often things need to rollback, but make the user experience consistent.
I see that Croquet mentions they have some form of two-phase commits, so I might assume that maybe they have a form of rollback over it, so your UX would apply the changes as you make them, but as it replicates and synchronizes, things would possibly rollback and get re-applied in order with what others did on your end, thus preventing lock ups in the UX.
So like in your example, what would happen is you press the pedal on the car and your car moves instantly, but if say the other user pressed the break at the same time, what you’ll see is your car moving forward and suddenly being reset to its starting position, which happens because once the other player input came in, the game rolled-back to the state of when they pressed the break and re-applied the breaking pedal + the acceleration pedal as the input and updated the state accordingly. But note that you’d not see things being replayed, what you’ll see is things immediately fixing themselves to what they should be at the current time based on all user inputs being applied in the right order and at the right time.
This GIF is awesome 
I once planned to use it for a tweet to recommend people to avoid building distributed systems.
I guess they make the trade-off that a spotty WLAN connection will make your local app or game unusable, while the overall approach yields a very simple design. They plan to have those reflectors on network edges, so that the round trip latency is as small as possible. If I remember correctly the view is eventual consistent and optimistic updates can be made, while the model is always consistent.
However I’m not sure how this should work out, if one user is in Australia and the other one in Europe for example. That’s the same reasoning, why I’m skeptical about the user experience yielded by Phoenix LiveView.
I also thought it is vaporware, but I changed my mind, when I’ve read that Alan Kay already pioneered this approach in 2004:
He is also an advisor for the company behind Croquet.io.
I only discovered this whole thing randomly via Twitter:
The corresponding blog post is this one: Frontend-only Multi-Player. Unlimited Bandwidth. Or: What is Croquet.io, really?
1 Like
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.