The Creation Engine

The Creation Engine No. 2

My personal blog, The Creation Engine No. 2, can now be found at http://jimpurbrick.com. My posts on the official Linden Lab blog can still be found here.

This Blog Has Been Assimilated

The Creation Engine is now part of the new grand unified theory of Linden blogging. To see just my posts on the new uber-blog, please go here. Thanks to everyone who read and commented on The Creation Engine, hopefully I'll see you all on the other side.

Locales, Boundaries and Portals

I finally got round to watching the amazing Half-Life 2 Portal Video and it reminded me of the locales and boundaries that I implemented in MASSIVE-3 (which were themselves based on the Locales in MERL's SPLINE).

MASSIVE-3 represented the virtual world as a partially replicated scene graph. Locales were frames of reference in the scene graph and boundaries were links between locales. Transforms on boundaries defined the locales relative positions, scales, rotations and rendering effects, allowing CC-TV boundaries to tiny versions of distant locales, boundaries to shadow versions of locales, torroidal universes of locales joined by boundaries which linked back on themselves and many of the effects which Richard Bartle suggests are impossible in a graphical virtual world.

We then added the concept of temporal transforms across boundaries which contolled the replay of events recorded in the target locale allowing links to locales in the past or to slow motion versions of current locales (we didn't manage links to the future, unfortunately).

Locales and Boundaries in MASSIVE-3 were lots of fun to play with and the Half Life video shows that they're even more fun with gravity and guns.

The Silver Bullet?

The Silver Bullet presents an interesting alternative to the algorithmic, Universal Turing Machine approach to computing based on behaving machines which are built of sensors and effectors linked to an environment. The proposal that Von Neumann machines emulate this parallel, synchronous model by simulating many simple independent behavioural units is very close to the implementation of LSL.

Certainly virtual environments map on to this model well, but I've often thought that  the Von Neuman architecture is ill-suited to distributed systems which fundamentally process many concurrent requests. Despite their fundamental concurrency these applications are often by necessity implemented using relatively small numbers of operating system threads processing events and having to store partial results across asynchronous I/O calls. It's an approach which breaks conceptually atomic operations in to a sequence of event handlers split on non-blocking I/O calls which all to often require programmers to implement the stack tearing manually, saving all the stack data to a heap object which can be saved until the I/O completes.

This is exactly the job which is automated by microthreading systems such as Java GoX, Brakes and the Mono microthreading support we've implemented for Second Life, so maybe those facilities will be more generally useful in the future.

HTTP Out

While we were adding llHTTPRequest and http_response to LSL, Zero and I were hoping that it would lead to all sorts of web 2.0 mashup hotness (as well as mixed reality robot control and massively multiplayer etch-a-sketch). So, its very cool to see Matt Basiat's SL Flickr mashup just days after the HTTP features were released in 1.10. Judging from the huge number of HTTP requests that have been made from SL in the last few days it looks like there are plenty of other projects underway too. Lets hope that ALAS is to SL what AJAX is to RL.

Second Life Kitchen, Real Life Cooking

The kitchen I designed in Second Life last summer now exists in real life. I did most of the work before I went to the Austin Game Conference, but we had to move our 500+ plus CDs out of the way before we could install the gas plumbing and the cooker - the conversion of our kitchen from bits to atoms was held up by the conversion of our music  from atoms to bits. Thankfully our music now exists as a collection of bits on a hard drive leaving room for more atoms in the living room.

In the end after designing the kitchen in Second Life I had to take a notebook of measurements to physical shops to buy most of the parts for the real kitchen, but all of the cupboard doors were ordered over the Internet and effectively 3D printed based on measurements copied out of Second Life prims and pasted in to a web page. It's easy to see how this could be taken further, kitchen suppliers could provide scripted modifiable models of their products which could be stretched and squashed in to the correct shapes and which automatically sent their final dimensions to the supplier for fabrication and delivery. All of the technology to do this exists in Second Life today.

I think the project also serves as a useful concrete example which sheds some light on some of the ephemeral issues surrounding Web 3.D, the Metaverse Roadmap and Overlay Worlds versus Mirror Worlds versus virtual worlds.

First, this project was fundamentally 3D. Although virtual world veterans quite rightly point out that a lot of what we do gains nothing from 3D, there are things that people do, like designing and building kitchens, that really are 3D and would really benefit from a 3D web.

I used a 2D planning tool before I turned to Second Life and it gave me little idea what the finished product would look like. Sharing plans or elevations on a 2D Web 2.0 app wouldn't have been anywhere near as useful as sharing the design in 3D with other people in Second Life. Designing the waste plumbing for the sink was one of the toughest 3D jigsaws I've had to solve. There are people who do things other than read and write blogs. There are activities that are better done in 3D.

The experience also demonstrated the utility of Mirror Worlds: virtual worlds designed to mirror the objects and locations in the real world sometimes seen as the poor cousins of either Augmented Realities, which annotate the real world with information or fantasy virtual worlds which exist as entertaining escapes from the real world. By building the kitchen in a virtual world I was able to extensively change it to create a speculative alternate reality and share my plans with others. The goal was not to simply annotate reality but to model it and mutate it to plan a possible future.

The shared virtual Mirror World also allowed me to show my family around the proposed kitchen without them having to come to Nottingham. In the near future I might decide to turn my laptop in to a Mixed Reality Boundary and hold a mixed reality party in the kitchen (the best parties are always in the kitchen). This model has already been used successfully by Electric Sheep, SLCC and recently Radio 1 to create virtual overflow mirror worlds which allow people attend real world events virtually when they can't attend physically.

The project also shows why mirror worlds should model the entire world rather than selected parts of it. As Second Life is mostly a traditional escapist virtual world my micro Mirror World kitchen exists as a tiny bubble of alternate reality in an arbitrary corner of the Linden Village in Ambleside. If I could just have gone to the appropriate place in a complete mirror of earth I could have started with a standard model of my house, made my modifications there and seen how my kitchen fitted in with the view out of my mirror world window. It's very unlikely that my little house in Sherwood would appear in a mirror world that selectively modeled the real world. Most people would never visit and my virtual next door neighbour might be miles away, but my house should exist so I can undertake projects like this. In a world where space is cheap and everyone can teleport, who cares?

I'm sure there will be lots more experimentation with mixed realities and mirror worlds in the near future, especially with Google now building virtual worlds. In the meantime I'm glad I finally have a finished kitchen. Building a virtual kitchen in Second Life was useful and lots of fun, but a meatspace kitchen is better for cooking meat.

Below: Old Virtual Kitchen, New Virtual Kitchen, Meatspace Kitchen.

Microthreading Mono

Being able to add an independent, event driven program to any object in the world makes scripting in Second Life really intuitive: you add a script and your object becomes an independent agent able to sense its world through event handlers, sit and think and then effect the world through library calls. It's a model that works equally well whether you're coding a fish which swims around looking for food or an information post that just hands out notecards whenever it's poked.

It's an approach that quickly leads to lots of running scripts. Some of the more complex regions constantly run 1000s of scripts. Abbotts Aerodrome runs around 2000 scripts and while most of these are of the give notecard when poked variety they could just as well be calculating PI or running SETI at Home, which means they all need to behave as if they were independent processes running concurrently within the simulator.

Supporting such high levels of concurrency has been one of the major challenges in integrating Mono in to Second Life. Although Mono and the CLI support the concept of independent threads of execution, each Mono thread maps on to an operating system thread which tend to be fairly heavyweight. By default most operating systems reserve megabytes of memory for each thread and don't cope with more than a few dozen running concurrently. Even reducing the allocated stack size to 32K and using the latest thread libraries on Linux doesn't get you much past 1000 running threads before the system starts to wheeze.

The other difficulty with Second Life scripts is that they can migrate between simulators while they are running. You are perfectly entitled to write a script which never stops running and then to tie it to a rocket that you fire in to another region. This is relatively easy to do when all of your script state is in a single 16K block, but much harder when your script has been Just In Time compiled to machine code and its state is scattered throughout memory, registers and an operating system thread.

The solution we implemented for Second Life was to use RAIL on top of .NETs Reflection and Reflection.Emit facilities to inject microthreading in to the script assemblies, an approach used by the JavaGoX and Brakes projects to implement mobile agents in Java. Our microthread injector searches through the script assembly finding points where the script should yield and inducing the types on the stack at those points. It can then inject extra opcodes in to the assembly which copy the stack in to a heap object and cause the script to yield. Whenever a script yields we can restore another script from its previously saved heap object and start it running again, allowing us to schedule many microthreaded scripts on a single operating system thread. By marking the heap objects as serializable we can then just use the standard .NET communication facilities to migrate scripts to remote simulators where they can continue running.

The approach is memory efficient as the memory needed to save the microthread is allocated when it yields, so a large amount of stack space doesn't need to be conservatively reserved up front for the thread. The problems with this approach is that it is expensive in CPU time spent switching microthreads and the space taken up by injected opcodes.

An alternative approach to microthreading Mono has been taken by Tomi Valkeinen who has written some very funky code (inspired by Eve Online's use of Stackless Python) to save and restore the native stack to switch between microthreads. This approach should be a lot faster than opcode injection. We can't currently use Tomi's microthreads for Second Life as the saved stack may contain pointers which can't be transferred to a remote machine, but it may be possible in the future to use Mono's garbage collector to identify the pointers in the native stack and twizzle them in to a form that can be sent to a remote machine.

It would be very cool to build a library which automatically switched between Tomi's microthreading implementation on Mono and Linden Lab microthreading on .NET. People could then build portable microthreaded applications which take advantage of Mono's native microthreading when it's available.

Free To Play! Pay For Stuff

A really interesting GDC session I went to yesterday was the "Free To Play! Pay For Stuff" round table discussing business models for online worlds based on digital item sales hosted by Daniel James, CEO of Three Rings Design, and Matt Mihaly, CEO of Iron Realms.

Three Rings' Yohoho! Puzzle Pirates allows players to purchase Doubloons for RL money and their forthcoming game, Bang! Howdy will also use a "Free To Play, Pay For Stuff" model. The Iron Realms games allow players to buy currency which can be traded between players and used to buy digital items which become bound to characters, preventing the resale of items. Another model was described by a number of developers of digital Collectable Card Games (CCGs) which sell randomly selected digital cards of differing rarity to players. In this model the secondary market between players is important and adds value as players are prepared to pay for potentially duplicate cards when they know they can sell them on. Digital CCGs weaken the important scarcity of cards present in RL as players are able to trade with all other players and so all cards are always available, but scarcity still works to a lesser extent. Adam from Purplex City pointed out that digital item or mixed reality CCGs allow far more tracking and analysis of card trades and uses over physical card games.

While the previous models are based on selling digital items created by the developers of virtual worlds, there was some discussion about Second Life and There.com which allow the sale of user created content. A lot of concerns were expressed over the sale of  copyright infringing content uploaded by players. Although There.com's model of checking and approving user created content when it is uploaded initially seems to protect against copyright infringement there was some concern that the process would make There.com more legally responsible if copyright infringing material was accidentally allowed to be submitted. There were also some concerns over Second Life's model of allowing all uploads and then removing infringing content when take down requests are received. While some people worried that Second Life could not be considered a common carrier and that the analogy to web hosting didn't hold, others were happy that Second Life could not be held responsible for copyright violations without every web hosting company being made responsible for its content.

A major attraction of digital item sales models is the ability for people to pay different amounts to based on their circumstances. Whereas flat monthly subscription fees cannot be set to levels that some players are willing to pay without becoming insurmountable barriers to other potential players, digital item sales allow every player to pay what they are willing and able to pay. Digital item sale models allow larger communities, subsidised by a minority of players and allow money rich, time poor players to play alongside the time rich players found in traditional subscription games. The criticism that digital item sales allow players to "buy the game" was countered by Matt Mihaly who argued that digital item sales allow games like golf: although players can buy better clubs, they need skill too and that subscription games allow players to "buy the game" with time anyway. The more pragmatic arguments were that if games don't allow Real Money Trade (RMT) it will happen anyway and the money will go to 3rd parties like IGE. Business models that allow digital item sales allow the developers to keep the money, for players to pay what they can and for the games to generate more revenue: some of the figures revealed were $20/user/month for Puzzle Pirates, $50/user/month for a Korean digital item sale based game and $50-60/user/month for the digital CCGs - all figures that are significantly higher than the monthly cost to play a typical subscription based game.

The question of whether digital item sales implied digital item ownership provoked some of the most interesting debate. Can digital items stored on servers run by developers ever be owned by users? Does selling digital items create a greater expectation of ownership than selling subscriptions? Do RL legal precedents set by cases of digital item theft take the decisions out of developers hands? What happens when developers want to stop running a world which contains digital items owned by its users? Although online worlds have been shut down before and players have threatened but never carried through legal action, would the situation be different if players own digital items sold to them by developers? Mike Sellars used the analogy that buying a digital item was like reserving a deck chair in a country club - you purchased the right to use the deck chair, but not the right to take the chair home. Steve Jackson argued that legislation will rule on digital item ownership and that RL already distinguishes between different types of property with different limitations: land can be owned but not moved. Without ownership are digital items are just things which we can play a trading game with, but don't want to be left holding when the music stops?

CC in SL in RL CC Salon

Hamlet was talking at the First Creative Commons Salon just after I arrived in San Francisco, so I went along partly to catch up with Hamlet and partly because things like Creative Commons Salons just don't happen very often in Nottingham. The talks by Josh Kinberg of FireAnt and Eddie Codel of Geek Entertainment TV mainly focused on the kinds of remixes and mashups are possible using CC licensed works and on technologies for easily sharing media using Creative Commons licenses while Hamlet talked about Lawrence Lessig's early influence on Second Life, his more recent talk in Second Life, Zarf Vantongerloo's CC machine and the Creative Commons and Free Culture efforts that have been gathering steam within SL over recent weeks. It was an enjoyable if slightly chaotic evening and with it's Flickr photobooth and 1337 address, Shine was the perfect venue. It was also an interesting first peak in to one of the geeky San Francisco events I often see advertised in mails sent around Linden Lab, but can't normally go to.

Below: Hamlet at the CC Salon, CC in SL in RL CC Salon

See also: Lindens in the Flickr photobooth.

Aren't You A Little Short For A Stormtrooper?

I'm currently in San Francisco for GDC and to visit the RL Linden Lab office to see the many Lindens that I haven't seen in RL since the end of 2004 and to meet the many new Lindens that have joined the company since then. The last time I was here Linden Lab was overflowing the old office in 2nd Street and preparing to move to the current office in Sansome which is now overflowing itself, so there are lots of new faces.

It's weird meeting the Lindens in RL which I've been working with in SL and via IM and email, but have never met or seen before. In many cases people appear very different to how I imagined them, to the appearances that I sub-consciously pieced together from SL names, avatars and IM and email mannerisms. It's very much like seeing a film after reading a book and the characters being different in the film to how you imagined them. When I've met some of the Lindens in RL I've almost thought: "You're not how I imagined you at all, you've been really badly cast"! It works both ways of course: when I arrived I think a lot of the Lindens expected me to be older due to my Linden name and avatar.

The other thing that's very strange is being called Babbage in RL. For the many Lindens who know me as Babbage Linden and who have never met me in RL it's completely understandable, but it still feels weird. Like Hamlet and Gwyneth Llewelyn becoming better known than their RL selves it seems that the membrane is leaking and that I am becoming Babbage. Certainly at Linden Lab Babbage Linden is familiar and Jim Purbrick is the stranger. After reading about Hamlet googling Hamlet I tried the same test for Babbage and sure enough, The Creation Engine is listed in the top 50 results. Maybe I need to get used to living in the shadow of Babbage Linden.

Below: No Turning Back, On Ocean Beach with Ali and Luke, Working Hard at Linden Lab, Cable Car On Powell. More pictures in my Flickr photostream.