croquet is very fast, and simple. However, if the relay server has no state whatsoever, this means that you can have conflicts between shared resources. Most multiplayer games i am aware of, have a server which is stateful, and enforces various rules, and dishes out exclusive resources, and arbitrates between the clients. Handling latency effects gracefully is an art form, and there are surprisingly few programmers who have built the networking stacks for various games. It is a super-narrow specialty of the programming industry, those people who know the networking aspects very well. Making sure that lower latency doesn't give you too much of an advantage is a very subtle area for which i have the highest admiration. I sure hope they have good debugging tools; it is no easy thing to debug multiple computers running in parallel at a distance, with lag times, and retransmissions causing random fluctuations in arrival time of correct packets.
Yes, if the server blindly passes on packets (merely orders them), then that means the client is authorative (determines the truth of what it sends), which is prone to cheating. It can say, "I did damage to player X", and there will be no way to resolve if that is true or not.
Ah interesting thanks @Duncan Cragg. Maybe I read too much into the name. I like the ideas in David Reed's original psuedo time thesis (https://dspace.mit.edu/handle/1721.1/16279) and related ideas of virtual time (David Jefferson). The new croquet seems to share some ideas at least because models live entirely in 'simulation time': https://croquet.io/sdk/docs/tutorial-2_5_sim_time_and_future.html. So models live in simulated time and advance only as they receive messages. I assume all messages must have a simulated time timestamp. So messages can be auto-ordered but I wonder how they handle lost messages. Wish they had more info on the internals.
BTW the interesting idea (to me) here isn't just a distributed library for games, but the idea that you have replicated objects with some consistency guarantees. All software needs this most of the time we're just implementing consistency and replication via custom RPCs and APIs (even though we don't call it that) and thinking of our data as half here, half there. Pushing replication and synchrony to the lower layer, solves some of these issues. As-is corquet is not a full solution, but the core idea of having timestamps in messages and multi-versions of objects on each host represents the distributed out-of-sync reality pretty well.
One of the croquet team member is Yoshiki Ohshima, who was at HARC.
11/06/2019, 7:48 AM
Croquet looks pretty neat. I used to do a decent amount of VR development, having built a prototype remote whiteboard system. Interacting with other developers in the community also doing social VR stuff, there was a shared desire for good, high-level multiplayer state management solution, so I could see Croquet fulfilling a big need there.
I wonder how Croquet will stack up against NormalVR's NormCore. Product-wise Croquet seems like it targets a broader set of usecases, with NormCore providing more VR-specific features out of the box. https://normcore.io/?utm_source=normalvr.com