Competition for SL

There is Second Life in town, but it’s of course not the only player here at the moment, though the most popular. At least one competitor exists, that has its roots in the academic area and has much broader goals than Second Life: Croquet.

Croquet has far more ambitious goals than Second Life ever could hope to have. To cite their website:

Croquet is a powerful open source software development environment for the creation and large-scale distributed deployment of multi-user virtual 3D applications and metaverses that are (1) persistent (2) deeply collaborative, (3) interconnected and (4) interoperable. The Croquet architecture supports synchronous communication, collaboration, resource sharing and computation among large numbers of users on multiple platforms and multiple devices.

And, in contrary to Second Life, all components of Croquet are already available as Opensource (seems like a BSD-style license to me), so anybody who wants can install a Croquet server whereever he wants.

Though SL has already a high learning curve at the beginning, Croquet has an even bigger, and the underlying concepts and principles differ very much. For example, no currency in Croquet at all, Croquet is more like kind of an in-house tool and such. Though it’s competition to SL.

Well, one of the principal architects of Croquet, Julian Lombardi, wrote in his blog now an article about „Metaverse Scalability“ and took Second Life as an example for old architecture, which should have been obsolete by ages and that Croquet is architecturewise far more advanced and ahead of SL.

Before Mr. Lombardi began working on Croquet he was designing ViOS, which could be viewed as one of the ancestors of Second Life.

The first of his key statements is this:

Virtual environments such as multi-user flight simulators and first-person shooters rely on many independent server sessions that are limited to a relatively few users at any one time. Massively multi-user metaverses, on the other hand, require the client to be updated as fast as things happen within the environment. This means that large-scale metaverses need a lot of horsepower in the server layer since every move and every action of every avatar must be conveyed to every client. This puts a tremendous load on a few servers for even the most trivial of interactions.

Well, that’s of course true and the reason why there is a limited number of avatars per region only. But that alone is nothing new and it also depends on the game. When all stuff is being preinstalled on the hard drive and you don’t have to stream inventory in, you can with ease handle 1000s to 10000s of players on one server. Many MMORPGs are able to do so.  But SL does not only stream inventory, it does also execute user scripts, therefore it needs much more computing power per avatar.

Other main statements are:

Our strategy back at ViOS, Inc. was to simply re-tune the system and put up more servers as the loads increased – hoping for the best. That approach would work well for Intranet applications that serviced relatively small numbers of clients. It even worked well for ViOS‘ initial user base of around 15,000 unique users. Problem was that once we had several thousand simultaneous Viosians tooling about in the landscape, they began to overload our interactivity servers, resulting in performance problems and service interruptions. Since there wasn’t a lot of cash flow or investment capital during the 2001 post dot-com financial downdraft, we were unable to add servers at a rate that could meet the demand. If we had, it might have led to another few years of success for the ViOS metaverse platform – but sooner or later we would have been brought down by fundamental flaws in our approach as a bottlenecked client-server based architecture.

[…]

By contrast Second Life makes money by controlling who can create islands and how those islands are linked to each other. It also has a very similar technical architecture to that of ViOS – a vintage twentieth century client-server architecture with with single points of failure, inertia, and control. It’s been interesting to watch Linden Lab’s struggle with the inevitable technical problems faced by Second Life as a result of its recent popularity, constrained architecture, and non-scaling technical approach.

So… you could state Mr. Lombardi’s article unter the sentence „Lessons Second Life should have learned from ViOS and why Croquet is such a much better approach.“ Who would have thought that…

It’s interesting that he speaks of single points of failures and a non-scaling technology base. LL thinks, of course, otherwise. So, the future is going to show us who is right about that one.

And, of course, Croquet is the solution to all this problems:

The Croquet technology has been developed with these lessons in mind. It is designed to scale in support of interconnected multiverses of millions of users without the need for any dedicated server infrastructure. Croquet’s architecture makes it possible to develop metaverse applications in which, anyone can freely put up content in islands of any size, interlink those islands with any number of other islands, and control access to those islands.

The problem is just that not really much use Croquet in those days. The media hype is focused on SL. So… this reminds me a little of VHS vs. Video 2000 in earlier times. Croquet as the Video 2000 and SL as VHS and we all know who had won this battle.

I think all tools in this area have their right – and need – to exist. But if Croquet can really scale will first be known when thousands of people are using it. Until then it has maybe been designed with that goal in mind (SL has been designed for 100.000 concurrent logins, too), but only a test of this technology under real usage is going to show us the truth. Period.

Well, of course there are already some adopters, like the University of British Columbia who is moving their learning group from SL on UBC island to Croquet according to this blog post. Why? The math must be simple: Croquet claims to be technology wise superior, it’s full opensource, so you can get your own Croquet server without renting it. So Croquet is cheaper. It would be interesting to watch their experiences with it.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert