So, how good is OpenSim?
With so many recent “bad news” presented to SL residents — the change of openspace sims into “homesteads” is just one of the latest, and there will very likely be more — it’s not surprising that many look for alternatives. MMOGs and MMORPGs can provide some relief for anyone too frustrated with LL’s recent attitudes — at least they’ll find friendly and tight-knitted communities there to give them some support, but also a lot of fun and entertainment. Soon, however, the hard decision has to be made: going back to Linden Lab’s fold, or seek an alternative?
Luckily for many, OpenSim is not the crippled and broken technology solution from “last year”. From little more than a cute toy, it became a workable platform. But how good is it really? Well, here’s an example. It starts with the worst-case scenario: slow logging in, multiple sim crossings with confused attachments, 8000+ prims being streamed across two sims (which is what happens on a four-sim-corner), and the SL viewer being thoroughly confused about where it is — at some point, the avatar was in one sim, the camera on another, but the grid thought my avatar was on a third sim!
After that, a longer sequence of OpenSim at its best. Really, you won’t notice it’s OpenSim, except for the lack of my Animation Overrider (I did manage to compile it, but I still haven’t done any animations for it!)
Convinced? Well, perhaps you are 🙂 Or perhaps the logging-in sequence freaked you out. If you’re looking about the user experience with OpenSim grids ran by third parties, you can read all about it on Prokofy Neva’s blog. He’s quite honest with what you should expect when entering OpenSim with the mindset of looking at it as a real alternative to Second Life — and from the perspective of someone that is going to use a third party’s services to connect to a different grid than LL’s, it’s only natural that comparisons are made.
If you’re looking for more information about the technology, do read on 🙂
OpenSim is a reverse-engineered application running on top of .NET/Mono. What this mostly means is that the developers of OpenSim don’t really know how LL’s servers work. All they know is what the SL client expects to receive in terms of communication. Thus, the SL client, to a degree, defines how an OpenSim-based grid ought to work.
This mostly means that some limitations that are built-in in the client will also show up on OpenSim. Typical examples: OpenSim also has prims; there is also a 25-group limit (OpenSim currently has little or no support for groups though); sims are 256×256 m in size and the map is tiled; avatars just have one type of skeleton… and so on.
On the other side of things, of course, some limitations are built-in on LL’s servers — and here is where OpenSim can shine in all its glory. There are no prim limits (default is… 45,000… but you can change that if you wish). There are no avatar limits. Uploading textures costs nothing. And so on — these are really arbitrary things set by LL which can be changed at will from OpenSim’s configuration files.
Then, of course, OpenSim’s technology is “unstuck” from LL’s. We don’t exactly know how LL’s servers really work, except that they use a lot of open-source technology. What we know is that it lacks modularity. You remember the issues with Havok, and how it was soo hard to upgrade it? Or how Mono took a year and a half to be deployed? Or how LL’s “bug fixing” tends to create new bugs elsewhere?
Well, these are symptoms of what is generically called monolythical programming. While we cannot be sure of it, of course, at least it seems that at the very beginning of Second Life’s server development, we had a single block of code. Adding or changing it seems to be insanely difficult. Some of you might have noticed that Linden Lab is attempting to introduce the new 1.25 version of the server software, which allegedly has few dramatic changes (they even call it “Featurettes Batch #2)… for over two months, with several deployment failures. These come apparently from bugs having been introduced by slightly changing the code here and there. Good code ought to introduce features without introducing new code. There are always problems, of course, but it seems that as time goes by, this gets harder and harder to do.
Contrast that with OpenSim’s modular approach. The early versions were quite pragmatic: get to the point where an avatar can log in to a stand-alone server without crashing immediately. Once that’s done, add extra features on external modules.
