What I learned about virtual worlds by helping found OpenSim

When we started OpenSim many years ago (back with MW, lbsa71 and many others who have since drifted on), we had grand ambitions. Yes, it started as a fun tinkering project that we spun out of our original activities — understanding Second Life from the code we collected in libsecondlife. But we quickly saw the potential to build a new virtual world that could scale to a larger audience than Second Life ever achieved. (Even during Second Life’s peak of 2006 to 2008, it was common knowledge that it was failing to retain new users.)
Early OpenSim developers in 2008, from left to right: JustinCC, Adam Frisby, Charles Krinke, IBM’s David Levine, Adam Johnson, Mike Mazur, and Jeff Ames. (Image courtesy Adam Frisby.)
For a while, there were some big names adopting the project in droves. Nearly every major tech company had some involvement — or at least one employee contributing — to OpenSim at some point. IBM had an entire team of OpenSim developers and was running internal conferences using the project. During my involvement, the OpenSim software was downloaded hundreds of thousands of times. In the years since, it’s found its way into many surprising places, from NASA to university courses.
It’s gratifying to see OpenSim still soldiering on 12 years later, in great part through the efforts of the educators who’ve embraced it, and through worlds like OSGrid, which maintains a small but dedicated user community, along with a host of other enterprises, projects and grids using the software.
And while OpenSim didn’t become the breakout success we hoped it would, I learned a lot from it, about building virtual world platforms — and what they need. (I had some follow-on lessons from the years I spent building other virtual worlds for various entertainment partners too, but that’s another story – and another article.)
You can’t build just half a platform
This was our original mistake. Having the Second Life viewer around gave us a leg up — we only had to build half the project. But without any ability to modify the viewer, we could not customize OpenSim’s user experience, or make real architectural improvements. A few side projects like the Open Metaverse Project had, in hindsight, a better idea — and probably deserved a bit more support than they got.
The Second Life viewer was eventually open sourced, and later, relicensed so developers could improve it — but the combination of a monolithic viewer codebase, and too much momentum to simply clone Second Life, killed any real attempts to do it properly.
That’s not to say people haven’t tried – for example, the team over at realXtend made a strong effort at it. But ultimately, I think this was the biggest mistake we made.
Virtual worlds shouldn’t reinvent the wheel
This is true of Second Life and OpenSim, and numerous other virtual worlds and MMOs — attempting to build key features and functionality by creating them from scratch, when better options already exist.
At the time, the list of free or cheap 3D engines could be counted on one hand — Torque, Ogre3D, Irrlicht, etc. But today, we have dozens of fantastic high-end options, including Unity, Unreal, Lumberyard, CryEngine, and Unigine. If you were willing to shell out real cash, Unreal, CryEngine, id Tech and others have been available throughout.
Building your own graphics engine from scratch, however, is a dumb idea. It’s an insanely complex bit of software. Throw in a few thousand graphics cards and chips, various drivers, and you’ve got the recipe for a monumental headache on compatibility and support, let alone trying to stay up to date with the latest and greatest in 3D features. Trying to build your own is just going to result in you wasting a ton of talent reinventing the wheel.
OpenSim developer meeting from 2009. (Image courtesy Adam Frisby.)
Like graphics, virtual world networking is hard. Scaling a robust high-bandwidth, real-time protocol is one of computer science’s hardest problems — tools like Raknet (now open source!) make it a lot easier. Easily half of all the effort that went into OpenSim was working on solving the thorny problem of, “this protocol is complex and requires sending way too many small packets”.
But we didn’t even need to do that.  A lot of the problem was streaming heavy data (like textures) which are decidedly not optimal for a UDP-based delivery system. The Internet solved this problem in 1993 with HTTP; the fact OpenSim didn’t use that for the longest time was a fruit of the viewer — it didn’t support HTTP-delivered textures until recently in its history.
Graphics and rendering are hard, so send that to middleware. Low-level networking and reliability are hard, so outsource that. Lots of hard scaling problems have been solved already by incredibly clever people — load balancing and mirroring make many problems go away. The standard Internet already has a pretty robust content delivery system, so use it — especially for delivering large files like textures and 3D models, which are ideally suited for technologies like HTTP.
It’s staggering to imagine the opportunity cost of so many development hours that went into feature reinvention in OpenSim that could have been spent elsewhere — like, for example, friction-free accessibility.
Which takes me to my next point:
Virtual worlds must be accessible — immediately
Even among gamers, the percentage of people willing to downland and install a client, then endure a time-consuming, multi-step login process, is vanishingly small. For the same reason, web and mobile access matter too. We know from our own efforts that if you want someone to download or install something, half of the people who sign up, won’t.
Today’s consumers don’t use desktops either – the web today is mobile, and I find myself using my phone more and more, switching only to my desktop to get work done. You need to be where the users are – and that, in my opinion, means friction- free and device-agnostic experiences.
Virtual worlds must be future proof
Graphics standards from 2003 are not the same as graphics standards in 2018, or more key, 2025.

Read the latest from Hypergrid news