Second Life Cory Ondrejka adieu: virtual world design history

A tip of the hat to newly-former Linden Lab CTO Cory Ondrejka, here is excerpts from my interview with Cory from March 2007. The interview does not explain the “irreconcilable” differences that CEO Philip Rosedale cited in his notice on Cory’s departure. It does though nod to design fracture points that appear to have escalated for the Second Life platform. ‘Nuff respect to someone who has been a really interesting originator and player in this virtual world field…I don’t think we’ve heard the last word from CO yet. File this one under virtual world design history.

Question for all: what are your thoughts on what the most important design issues are for VWs right now?

Transcript San Francisco, Linden Lab, March 13, 2007

This is an excerpt from my interview with Cory Ondrejka, the CTO of Linden Lab (LL) and the primary author of the Second Life world design and scripting language. We talk about two main things in this selection that are pressing issues for virtual world users and designers across platforms:

Scalability
Build tools for user created content (UCC)

PGL: What does scalability mean for Second Life (SL)?

CO: Scalability for SL primarily means being able to increase the number of simultaneous users. We can increase the number of sign ups all day long and we can increase he number of simulators we connect to all day long. Simultaneous users, that’s the crux. Right now we are approaching 40,000 simultaneous users. Which is to my knowledge this is the largest single shard simultaneous user space that has been built. Eve Online is very close, but I think we have finally caught them.

PGL: How are they designed that they have been able to handle those kinds of numbers in advance?

CO: They do nothing like the transaction load that we do. They’re not doing rigid bio dymanics over the whole thing. They are ships flying through space, largely not in contact with each other. If you’re going to simulate something do that ;-). Also, they took a very specialized hardware solution to try to scale while we don’t. Eve Online may never have to get to 80,000 simultaneous users. We want to make sure that we can get to 40 million. It’s a different set of requirements and we’re willing to take some short-term pain to make sure we can get there. And so, scaling for us is figuring out how to manage database load. And we know how to do it so for now scaling has become how fast can we hire. How fast can we get high quality developers working on the problem, because a lot of it is not rocket science any more. Well, it’s rocket science but it’s not magic any more. We know what to do. It’s just a matter of doing it. Which is a great position to be in.…The benefits of doing long-term basic research could be enormous. Because nobody knows yet what the right long-term research is in this space. We don’t know anything yet.

PGL: A friend from the Media Lab asked me, why didn’t Linden Lab (LL) write it in Mono [open source software project to develop and run.nET client and server applications] originally? And we both came to the conclusion that it did not exist.

CO: It did not exist. [Laughs]

PGL: what did you start with in 2000?

CO: C++, Windows and Linux (for cross-platform use).

PGL: Was there precedent or did you have to write everything from scratch?

CO: Well, there were a lot of game engines out there. But to the best of our knowledge, nobody had done the terrain compression scheme using lossy compression to stream height fields. This was new. The cellular automata architecture, which is the simulator grid, did not exist, so we created that. Might there have been a graphics engines that could have drawn height fields––yes, probably, but that’s not hard to write. And as it turned out, because we switched to this primitive model, of building out of geometric primitives, it’s really good that we did not did grab an off-the-shelf engine, because no off-the-shelf engine is assigned to draw very high numbers of low-poly objects.

PGL: Can we talk about primitive modeling (prims) for a minute?

CO: Until the summer of 2001 we did not even have people in the world. We had spaceship flying around and floating eyeballs. Though we had rudimentary creation tools, we did not necessarily know that we wanted people in the world. Then we had the first creation tools and saw the first evidence of people building stuff and realized that people wanted to build human things. And as soon as that happened, we said, Oh, we need people. Oh crap. And so, fall 2001 the scripting language went in, avatars went in.

One of the biggest challenges was: how do we make avatars that are as flexible as the building system of the rest of the world? So we had a lot of competing ideas around that. Richard, one of our developers, and I came up with the idea of what if there was this really complex parameter space, a very large design space where we let you in real time move through it. We designed this with the idea that, well, there were going to be a lot of local maxima [points in the domain of a function at which the function takes largest value]. And local maxima will be viewer dependent. So “put all the sliders to the right” won’t be the solution that anyone comes up with. Or at the very least, “all the sliders to the right” is unattractive.

This goes back to a question you started to ask a while ago: why the focus on real time? If you are going to take people through complex design spaces, it’s got to be interactive. You can say to people, “Here are the 300 sliders to define a human,” which is an unimaginably complex design space. Then anybody can say, “Do I like my nose bigger or smaller?” Especially if other people can be there with you and say, “Hey, no on no, I like it smaller.” So that was a pretty big deal. That’s when the objects went from being just cubes and spheres to being profiles and paths, which is why you can cut them and twist them and do all those things to them.

PGL: So the primitive-based design system is made for greatest degree of real time collaboration?

CO: Yes, the advantage of primitive is that the editors are all built into the system, which means that when the Ferrari drives by you can say, “Hey how did you build that Ferrari?” And they can show you. From an education-theory standpoint, things like one-demand learning, peer-to-peer learning, situated learning, are reinforced by the fact that the tools are embedded. [It reinforces co-creation] in a way that “Step one, go buy Maya” doesn’t. Right? That said, we will eventually have to support polygonal models, because that is how the world works.

PGL: Which is not so much for the SL users as they exist, but for a burgeoning pro industry.

CO: Yes, that’s right. But the trick is going to be how do we do that without hurting the community? And I’m not smart enough to know the answer to that question yet.

PGL: It’s a tough one. Do you think it’s really necessary? Why does LL have to solve the problem for the minority use, the professionals?

CO: I don’t think it’s that we have to. It’s whether we want to or not. There are advantages to being able to render the scene faster. And right now there are a host of experiences that you cannot build in SL: anything really interactive, anything really action based. And so, why don’t we enable that. And polygons end up being a piece of that, probably, maybe.

Also, while we have this incredibly talented set of users, there is nothing wrong with having a minority of experts comes into a space. This is the heart of one of Wikipedia’s problems. On the plus side, Wikipedia would be better if you had the amateurs and the experts playing nice with each other. Now, of course this is always the problem. The experts have lingo, jargon, and certification–all the things that separates experts from amateurs. Experts actively encourage this. Anything you can do to break down those boundaries, there are advantages to that. So if there were poly-editing tools in SL or mesh editing tools, for example, well, that becomes a way to become a good poly-mesh builder. Well, that would be pretty cool. If you can learn to build well with primitives, you can probably build with polys. But I don’t think we know the answer to that yet.