Jump through the hoops with Croquet – The New Stack

You can design and build your breakthrough product in one go, or better yet deliver your project in stages. If that sounds like the message of an agile consultant, it is. Another reliable way is to cut your proposal into different independent layers.

I mention this to circumvent the various statements made by Croquet, all of which have slightly different audiences. It allows you to “create entirely client-side multi-user web applications”. But Croquet is also “the operating system of the metaverse”. Additionally, “Croquet OS is a powerful and easy open way to create microverses”. It’s microworms; not microservices or metaverses.

Once you accept that progressive building makes sense, you don’t need to worry about anything related to the term “metaverse”. Today, concerns around an impending metaverse/cyberspace/oasis would center on social and regulatory issues. Meta’s Nick Clegg looks at them here in anxious detail. At some point, Croquet will have to deal with these issues, but for this article, I’m only looking at the more developer-friendly engineering challenges that Croquet addresses.

In the world of multiplayer gaming, the server has to be the point of truth, largely for reasons of trust. When one or more players go head-to-head in Fortnite, each must be confident that given fair latency and fps, only their weapon skill dictates events. However, for many user-initiated actions, even within the same game, there are no real trust issues. Looting a predetermined chest is an example of this.

Croquet makes it clear that in its system there are no servers – but there are reflectors. Indeed, a global fleet of them. The fastest way to appreciate what they do is to simply run croquet.io/w3 on the browsers of two separate devices side by side. For the second device, copy the generated URL in the browser of the first device or use the QR code that hides at the bottom left. You’ll see the same manipulable landscape (much like the old god sim Populous) across both browsers. If you distort one, the other also changes, even if you only scroll one. You might think “well, both devices are looking at the same server model”. But no, they run their own model code but watch a shared message stream. So the job of the reflectors is to make sure that when I change the facts in the field (literally in this case, by changing the surface in the simulation), clients running the same model are updated at the same time with the same posts.

A Croquet client runs synchronized models that communicate via publish/subscribe. Much like the Internet itself, reflectors are just a messaging infrastructure, leaving computing to happen at the edge.

Hello World Example

I’ll dive straight into a Codepen example here to show how it works.

You should see the “Hello World!” program (it doesn’t actually print that line) with the three live files in consecutive windows (HTML, CSS and Javascript) framed in Codepen. And you will see a number counting down in the bottom window. We won’t need great coding skills to figure out what’s going on.

Croquet sees an app as split into one view and a model. We know what the model does – he runs the show. Its job is to publish the activities and provide methods to do so. But while that’s happening, what you see in the browser is the view. The view subscribes to all the events it needs. It also publishes its user interaction events. So when you hit that ever-increasing number, it resets.

In our example, when you click inside the countShow div (see HTML window), a local click event is captured inside My opinion (see the Javascript window). This was defined in the constructor. The referenced method counterReset does what you imagine — post a message on the appropriate channel:

So your local My model (and all other models connected to the session) will react via subscribing to the “counter” event channel. On receipt of the “reset” message, the model resets the counter and publishes the “modified” message:

And as sure as night follows day, My opinion retrieves the “modified” message it is subscribed to and modifies the view by reading the model:

Everything is quite simple. We note that the only direct interaction between the view and the model without the chaperone pass message was when the view read the count value directly from the model, as you can see above.

I mentioned a session, and that’s what the last section of JavaScript code handles; it joins a session with your API key and view and model class names. The only other important thing in JavaScript is the registration of My model with croquet.

What happens when you modify the view or the model

What happens if you change parts of the view?

Let’s play around with the code and add an extra welcome banner ourselves:

Other than the expected visible greeting, nothing else happened.

But what happens if you change the model?

Now that’s another story. I just added a comment, but you’ll probably notice that the random letters in the color box and the QR code change as soon as the reload happens:

From what we’ve seen, there’s no way to sync multiple models if the models were actually different (ok, I just added a comment). Remember that the model is saved, so if the model changes afterwards, something has to break.

The session is identified by two automatically assigned colors and a five-letter nonsense word connected to a QR code and URL. Users who are in the same session – who see the same badge – are guaranteed to be in sync.

Any modification of the model code will create a new session, with a different badge. Only when other users load this modified code will they be able to join the new session. As you’d expect, the model should never access the view directly; remember how we changed the view without messing up the system. Thus, the view is local and possibly unique to the user — a shared model cannot know about user-independent views. Also, the view can’t write to the model — the model is shared by everyone, so it can’t be edited. Communicate only through the publish/subscribe message and pass the chaperone, in order to avoid any inappropriate behavior.

You can get your own API key from Croquet to see what you can do. While this method of synchronizing multi-user activity requires further examination at the boundaries of trust, for now it represents an interesting new perspective on the serverless toolset.

Main image via Shutterstock.

James S. Joseph