But with all these mentions of democratizing and opposing centralization, the licensing model seems unclear to me. The Croquet Microverse is Apache-licensed but "built on top of Croquet OS" which seems to be proprietary with paid and centralized server. Does anyone understand whether at least the client side component of the Croquet OS, which interfaces with the Microverse, is open source so that alternative server implementation could be developed without legally dubious reverse engineering of the protocol?
> Smith has been in touch since the publication of this article to clarify Croquet's positioning on open source: "All of our frameworks are open source. The kernel of the system – the virtual machine and the reflector – is currently not open source though.
> "This is mainly because of our concern about handing our business over to Amazon. We plan to open source the entire system once we are fully deployed. In fact, the fully decentralized system we will be making available next year will need to be open source."
> He added that while the org has pricing for its web-based products (here), it has "not established pricing for Croquet for Unity yet – this will be set once we have the commercial release in the next few months, but will be very competitive."
Croquet's always been peer-to-peer, with no need for servers. It sounds like they've made a small server to "reflect" traffic between clients that can't directly communicate (like using a STUN server to coordinate SIP/WebRTC).
> Does anyone understand whether at least the client side component of the Croquet OS, which interfaces with the Microverse, is open source so that alternative server implementation could be developed without legally dubious reverse engineering of the protocol?
I don't think any reverse engineering is needed, since the protocols (e.g. TeaTime) were published decades ago. AFAIK the existing Smalltalk clients are FOSS (OpenCroquet/OpenCobalt); there have also been JS ports in the past (I think as part of Qwaq/Teleplace/Terf), but I can't remember if they're FOSS; those may be the same as this "Croquet OS", or this could be a rewrite.
(Yes, this project has had many names over the decades!)
As far as scaling goes, fancy scaling solutions are currently in the 'future-problems' basket. Currently Substrata just uses a naive client-server solution with O(n^2) messaging where n is the number of connected clients - e.g. each message from a client is sent to all other clients.
I'm relying on the performance of C++ to manage despite this. I've tested with a few hundred concurrent clients.
You can get any two of those easily. All three, and you're into a big data wrangling problem.
Since I'm working on a high performance client for Second Life/Open Simulator, I have to face all three, and am interested in systems that address all of those.
2) and 3) are the usual case for games - there's a big content download, and then you go. Such systems inevitably have a "Loading..." screen, or screens.
Decentraland is 1) and 3); it's a big world, but not much detail. (Each parcel in Decentraland has only 20,000 triangles.) Second Life is 1) and 2) - big, detailed world, big performance problems.
There are some voxel based systems which manage all three, sort of. They have their own problems.
Improbable's system seems to work, but it cost US$400 million to develop and takes huge server resources to run, so the only real customers have been for special events and military training. The five indy games that tried to use it all went broke. (Worlds Adrift was pretty good, too.)
In Croquet that simply falls out of synchronizing computation itself, rather than just state. Since all machines receive the exact same inputs, their physics engines arrive at the exact same results without any need to cooperate.
I'm trying to get a sense of what this can do. The demos look like something from the Web3D era. (Web3D was VRML in XML syntax.) You can make little rooms and put a modest amount of stuff in them. Kind of like Decentraland, etc. There are lots of systems like that. Redblox was promoting theirs yesterday on Reddit. A few car brands have web sites like that. They work fine, but you're done in ten minutes.
It's when you scale up the world complexity and size that these simple approaches come un-glued.
The Croquet web site is "sign up now for waitlist", not "Here's our world".
Is this supposed to be representative of the technology?
> A few car brands have web sites like that.
For free experiences online, either you are trying to do things as cheaply as possible, or you are the biggest richest player in town. There is no viable middle experience, as much as people pretend there is. A car brand choosing to use this is trying to do middle.
Hm. This is being touted as a major breakthrough, yet it looks like everybody else's low-end 3D world. A good example of that genre is Mozilla Hubs.[1] You get to visit a little pre-built 3D world with other people in it. Graphics are cartoon-level. Performance is OK. Works fine. Few users.
Croquet tries to accomplish the same thing in a more distributed way. That's OK, but if all the clients are running in lockstep, the slowest client determines the speed. There are some games like that, and they usually come with a program to kick off laggy users.
Metaverse technologies that scale to a big world are interesting. But this doesn't seem to be it.
Why the comment "This is that rare announcement that's far more significant than it sounds." In El Reg, which is usually rather skeptical. Am I missing something?
Indirectly, as in I worked on both, and they are directly inspired by ideas from Smalltalk. Both Lively Kernel and Croquet were done by members of Alan Kay’s group.
Exactly this, if the networking is all handled automatically, the server is only relaying data so won't be able to validate things.
The update in TFA is interesting as well, they're worried about Amazon for some reason, hence not releasing some of the moving parts. There are open source licenses that prohibit cloud usage.
Do you mean that there are licenses that prevent SaaS/PaaS/IaaS usage? Because "cloud" is a bit of a nebulous (sorry!) term. If Amazon is running it on physical tin, in their own DCs (even the same tin and DCs as their cloud services) is that "cloud usage"?
Why open source any of it? The copyright owners don't believe they have a business model that can survive in the open source world. Fine. It's their creation, their choice of license. It gets filed in my mind on the closed-source shelf.
Just to follow up with this. I've had the idea knocking around of creating an online version of the RoboRally boardgame and this looks like it would fit well for that. However, if I can't model the rules on the server then anyone would be able to easily cheat.
Not sure in the case of Croquet, but you can implement this very well with https://reflect.net (my company). Server authority is a core piece of what it provides, and as a bonus you don't need a special runtime – it runs in plain javascript in a web page.
I play Robo Rally all the time with my kids and would love you to implement this. Happy to help any way I can :).
Two-way gateways to and from other instances, and existing web pages and web apps ... Croquet environments can contain multiple live web views, and Croquet code can also fetch data from external sources and render it live within the virtual environment.
Hopefully "decentralized" (+ centralized reflector) Croquet in Javascript can co-exist with JS libraries that work with existing servers.
Perfect world. Thanks for those classic gems in new setting and caring about them.
Ah, and I am grateful for that comment giving official blessing to the part of my mind that loves Squeak and Applescript to also be that happy about the expressive coding feature integration that JS has become. Incredible how well all the parts fit in the end (the language perfection unfortunately not being extended to that limited canvas to HTML integration. Seems we still can only draw in boxes and structure with text and objects.)
I can speak to Third Room, although haven’t dug enough into the current incarnation of Croquet to do a side by side comparison. I’ve called out the bits which I’d guess are more unique about TR.
TR is/was:
* Open decentralised platform for spatial 3D collaboration, end-to-end encrypted by default thanks to being built on top of Matrix
* Web native built on WebGL/WebXR; no proprietary Unity or similar. glTF native for content.
* Apps written in WASM (compiled down from C, JS, and in theory Rust or Zig), using WebSG (our proposed web standard API for manipulating glTF content)
* Triple-buffered engine that can get 120fps on typical hw, including full immersive VR and XR on Quest Pro
* Direct manipulation in-world editing and inspector (“web style”), exposing the same model used by WASM apps.
* Networking is full mesh (so limited to 20-30 players per room), but these days could scale much higher by using the Element Call SFU (or by tiling the world)
Unfortunately, despite the Creator Update kicking ass in June (https://matrix.org/blog/2023/06/07/introducing-third-room-tp...) we failed to lock down long-term funding for Third Room and the team disbanded in July. The code and servers prevail though, and hopefully some day it may live again.
The original Croquet was a major inspiration for TR, and it’s cool to see the name live on. Hope they have more success than we did with TR.
Damn, this is a huge shame. What were this sticking points for investors if you don't mind me asking? What is the value proposition? I mean, I am really interested in potentially using this in the AEC industry as an open source product. But where would the revenue come from?
a) metaverse hype collapse causing blowback oversteer against any kind of virtual world platform
b) the team wasn't interested in running it standalone as a for-profit startup outside of the Matrix Foundation, and Matrix doesn't have enough $ to fund core Matrix, let alone Third Room
c) big organisations who claimed they were interested in funding it within Matrix entirely failed to follow through (which probably maps to metaverse hype collapse). My favourite example is Rolls Royce, who ran a fullblown innovation challenge in May, saying they were specifically focusing on interoperable 3D collaboration: https://iuk.ktn-uk.org/opportunities/rolls-royce-sme-innovat.... We invested significant effort in applying, and never even heard back from them at all. As far as I know, they silently ditched the innovation challenge without telling anyone who'd applied to it. You can see our showreel for it at https://youtu.be/cFKJ-IuGaKA.
In terms of business models: selling SaaS hosting and proprietary apps & DLC on top of the open platform is the way to go, imo. https://thirdroom.io/preview#what-can-you-use-it-for has ideas for problem domains.
If anyone reading this happens to have $500K-$1M/y available to fund core dev, there's a small but finite chance of finding a way to get the project back on the road. But the core Third Room team has disbanded, and as per https://matrix.org/blog/2023/12/25/the-matrix-holiday-update... the focus of the remaining Matrix core team is currently monomaniacally on core Matrix foundations rather than future-facing stuff like Third Room.
Needless to say, I feel incredibly frustrated that we funded TR so far, and then had to stop before it got to escape velocity: simultaneously helping the open metaverse while setting it back too.
Thank you for outlining the challenges. I think the whole metaverse angle has been a mistake. There are many legitimate use-cases like work collaboration, or multiplayer games. The marketing of the metaverse just leaves a really bad taste in my mouth.
If one were to create a MVP for a collaboration platform. Would it be possible to do that with the current state of Third Room in your opinion?
I have seen Webspaces before some months ago. It's a fantastic project. The forced voxelization to keep complexity predictable is genius. I really wish the Third Room and Webspaces would join forces.
Something like forced quantization into point clouds, 3D tiles, and gaussian splats would be a game changer.
I saw it. I read the homepage and the Github page. It tells me very little and doesn't explain much of how it works. Certainly not enough to try to explore the differences.
OK, look, yesterday, I spent an hour carefully writing a simple explanation for some zeeb on Fesse Bouc on why you couldn't expand a ZX Spectrum with more RAM.
He replied with a one-line dismissal saying it was boring.
I blocked the nasty little troll.
Do you really want me to try to explain this, or is this another idle snarky comment?
Trying to summarize what's important about this tech is going to take a substantial chunk of my day. It's all in the article anyway. Have you RTFA and read the Wikipedia page on the original Croquet? Have you, in other words, done the absolutely minimal effort?
> Do you really want me to try to explain this, or is this another idle snarky comment?
Yes, and thanks for doing so at https://news.ycombinator.com/item?id=38803004. I was hoping for a comparison with Third Room particularly, given TR was directly inspired by the original Croquet (albeit using WASM for shared computation rather than SmallTalk semantics). But it looks as you may have dismissed TR out of hand; I tried to explain its novelties at https://news.ycombinator.com/item?id=38773575.
> Have you RTFA and read the Wikipedia page on the original Croquet?
Yes, yes, and I used the original Croquet extensively in the mid-2000's.
> Have you, in other words, done the absolutely minimal effort?
Yes, I think so. I was more wondering how you felt modern-Croquet compared with other Croquet-inspired decentralised collaboration/comptuation environments like Third Room; I think I have the answer loud and clear now.
Thanks for the very patient and civil response, and I am sorry for my tone. I am far too used to being challenged and confronted about simple statements of
historical record in software and technology, but talking to other old farts in the industry, apparently this is now commonplace. :-(
I apologise.
I was very impressed by the tech demo of Open Croquet that I received, but there is only so much space in a Reg article and I didn't feel that I was technically qualified to go deep into how the tech works.
I can respect good tech or a good demo even though I have no use for it myself. I don't do online gaming at all and have not done so since its very early days. It is outside my ballpark: I personally am not interested in using 3D, or gaming, or VR, or programming any of these things.
Which is also why I do not follow other entrants in this field. So I am sorry but I'd never heard of TR, or of Mozilla's offering.
It’s not that different than how’d you implement a multiplayer game. Take a real time strategy game (not quite the best example). But if you’re a client, you’d only be concerned with those you can see on the battlefield, especially if there’s a fog of war.
Anyways, you can also do things naively. Some RTS games just handed down the entire state to every client and let them figure it out. You can see how people would take advantage of that to strip away fog of war during online matches.
That Croquet was an effort to extend a then circa 25 year old project, the Smalltalk programming language,.
Smalltalk is more or less the original object oriented programming language (there was Simula before it but it has different goals). Smalltalk aimed to make it easy and fun to create GUIs and GUI-driven, 2D graphical, software.
Smalltalk largely flopped in the market although some commercial and FOSS versions survive. For instance the Eclipse IDE is an offshoot of one of these.
Some of the original Smalltalk team created Squeak, a modern colourful Smalltalk that is entirely FOSS. Squeak has been used to create lots of other things such as the children's educational programming tool Scratch.
Croquet was built on and in Squeak. Croquet extended Squeak into two new directions at once: 3D graphics, including hardware acceleration, and transparent networking.
Croquet could be used to build 3D apps and entire 3D environments, including 3D games and VR along with lots of other things.
But also, at the same time, the idea is that Croquet instances on different machines can talk over a network, using a protocol called Teatime, so that those instances are connected and can share data, live, in real time.
The idea is, as I understand it, that it makes stuff like multiuser video conferencing so trivial it's basically a no-code exercise.
It is trivial to build something like Zoom or Teams or Google Meet: you draw a room, place some picture frames on the wall, connect each one to the mic and camera of the local machine, and boom, you have a video conference in 3D, without coding.
It is meant to make much more complicated ambitious stuff easy. It extends Smalltalk and makes it able to do 3D as easily as Smalltalk did 2D stuff at Xerox PARC in the 1970s, and it makes it all network-transparent, so connecting instances is as easy as coordinating two Smalltalk windows to share data: literally a fun game for schoolchildren.
Xerox PARC's Smalltalk is the 1970s tech that was the original inspiration for the Apple Lisa in 1982, and a couple of years later, the cheap cut-down version, the original Apple Macintosh in 1984. That inspired Microsoft Windows, and Windows created an industry of cheap 32-bit PCs with integrated graphics and sound which is where Linux developed and thrived.
Croquet, in 2004, took this 1970s tech that predated (and caused!) the microcomputer boom and put it on the Internet with hardware rendered 3D.
Smalltalk is the original language that popularised OOPS and so which led to C++ and Java and Python and C# and .NET and Scala and Rust and Go and all that. It is also the language which inspired the Mac and GUIs... all GUIs.
Smalltalk also directly inspired later OOPS languages, such as Self. Self subsumes Smalltalk objects into "prototypes", using a Smalltalk-like syntax.
Self later inspired Javascript, which replaces the Smalltalk-like syntax with C-type curly-brackets syntax.
Now, OpenCroquet moves Croquet off Squeak Smalltalk and into Javascript instead. It is Croquet, ported from Squeak to Javascript, so it runs inside the browser.
I have a hard time not grinning when I read about a lot of these 'metaverse' 'hard-problems' that were seemingly solved by Linden Labs years and years ago.
and better yet, nearly all of the metaverse results look like a mashup of early 'There'[0] and SecondLife -- it's kind of bizarre how it all sort of ends up a the same place.
Oof “Mr. Melcher once described There.com's archetypal user as "the woman who is in her 30s, single, really overweight, lives in a small town." In 2003, Melcher stepped down as CEO.”
Honestly, I am not sure what I am looking at, too much corp-speak.
Even though I am in similar industry(I think). If anyone is looking for a simple multiplayer SDK for games, I am making one: https://docs.joinplayroom.com
Metaverse is dead, why companies still use that as a buzzword marketing tactic, no one is using metaverse.
Also, if it’s fully client based and no backend, why do they charge per minute?
The incredible Smalltalk developer Vanessa Freudenberg -- who besides being Croquet's devops person, also developed Squeak Smalltalk, EToys, Croquet, and the SqueakJS VM written in JavaScript, and worked extensively with Alan Kay -- was just tweeting (yeah, it's ok to deadname Twitter!) about reviving Croquet from 20 years ago:
I've been having fun reviving the Croquet from 20 years ago using @SqueakJS . It's not perfect yet, but a lot of the old demos work (sans collaboration, so far). This is pretty close to the version Alan Kay used to give his Turing Award lecture in 2004:
This is a version of Croquet Jasmine running on the SqueakJS virtual machine. Here is an early demo of the system from 2003. Alan Kay used it for his Turing Award lecture in 2004. While working on that demo, David Smith posted some blog entries (1, 2, 3, 4, 5), with screenshots uploaded to his Flickr album.
This is work-in-progress. Contributions are very welcome.
— Vanessa Freudenberg, December 2023
Dan Ingalls @daningalls
Yay Vanessa! This is awesome. These are mileposts in our history that now live again!
Vanessa Freudenberg @codefrau 7:40 PM · May 17, 2022
My company @CroquetIO announced #MicroverseBuilder today.
Each microverse is "just" a static web page that you can deploy anywhere, but it is fully 3D multiplayer, and can be live-coded. Portals show and link to other developer's worlds.
This is our vision of the #DemocratizedMetaverse as opposed to the "Megaverses" owned by Big Tech.
It runs on #CroquetOS inside your browser, which provides the client-side real-time synchronized JS VMs that you already know from my other posts.
#MicroverseBuilder is in closed alpha right now because we don't have enough #devrel people yet (we're hiring!) but you can join our Discord in the mean time and the open beta is not far away.
We are also looking for summer interns! #internships
And of course #CroquetOS itself is already available for you to build multiplayer apps, as is our #WorldcoreEngine, the game engine underlying #MicroverseBuilder.
HN really needs a better automatic-deduplication engine. E.g. If the same link is posted again months later, mark the original post as new again with an upvote, and the caption (if changed) as a comment...
Vanessa, it has always amazed me how you managed to square the circle and pull a rabbit out of a hat by the way you got garbage collection to work efficiently in SqueakJS, making Smalltalk and JavaScript cooperate without ending up with two competing garbage collectors battling it out. (Since you can't enumerate "pointers" with JavaScript references by just incrementing them.)
>The fact that SqueakJS represents Squeak objects as plain
JavaScript objects and integrates with the JavaScript garbage collection (GC) allows existing JavaScript code to interact with Squeak objects. [...]
>• a hybrid garbage collection scheme to allow Squeak object
enumeration without a dedicated object table, while delegating
as much work as possible to the JavaScript GC,
Have you ever thought about implementing a Smalltalk VM in WebAssembly, and how you could use the new reference types for that?
I would like to speed up some parts of SqueakJS using web assembly. For example BitBlt would be a prime target.
For the overall VM, however, I’ll leave that to others (I know Craig Latta has been making progress).
I just love coding and debugging in a dynamic high-level language. The only thing we could potentially gain from WASM is speed, but we would lose a lot in readability, flexibility, and to be honest, fun.
I’d much rather make the SqueakJS JIT produce code that the JavaScript JIT can optimize well. That would potentially give us more speed than even WASM.
>Where this scheme gets interesting is when the execution progressed somewhat deep into a nested call chain and we then need to deal with contexts. It could be that execution is interrupted by a process switch, or that the code reads some fields of thisContext, or worse, writes into a field of thisContext. Other “interesting” occasions are garbage collections, or when we want to snapshot the image. Let's look at these in turn.
This sounds similar to Self's "dynamic deoptimization" that it uses to forge virtual stack frames representing calls into inlined code, for the purposes of the debugger showing you the return stack that you would have were the functions not inlined.
I always thought that should be called "dynamic pessimization".
Debugging Optimized Code with Dynamic Deoptimization.
Urs Hölzle, Craig Chambers, and David Ungar, SIGPLAN Notices 27(7), July, 1992.
That paper really blew my mind and cemented my respect for Self, in how they were able to deliver on such idealistic promises of simplicity and performance, and then oh by the way, you can also debug it too.
This is what happens when one of a dozen press releases I get every day, all containing loads of hype, has a few buzzwords I recognise from pre-Windows pre-Mac pre-Lisa tech.
I asked the PR person some questions. They had no idea at all. So, they put me in touch with the CTO, I asked him the questions, and realised this was something huge and complicated. We had a video chat, he absolutely blew my mind with some of the demos, and I tried to boil it down into a relatively short article.
I guess I boiled it down too much if it came over like syrup. :-(
When I wrote "we previously called" that means "someone else from the Register said this in the past". The link was to a 2017 article. The real purpose of the backlink is to explain what Unity is to readers who don't know.
I personally am not enthusiastic about Unity. I am not a gamer or a developer. I am totally indifferent to it. I don't care in any way. I have bought one (1) new computer game in the last decade. I think it might have been written with Unity but I don't know and I don't care.
I'm impressed and enthusiastic about the technology behind Croquet, but I personally have no particular use for it myself. It is still cool tech, though.
But with all these mentions of democratizing and opposing centralization, the licensing model seems unclear to me. The Croquet Microverse is Apache-licensed but "built on top of Croquet OS" which seems to be proprietary with paid and centralized server. Does anyone understand whether at least the client side component of the Croquet OS, which interfaces with the Microverse, is open source so that alternative server implementation could be developed without legally dubious reverse engineering of the protocol?