Programming Second Life

Montréal.
There are about eight powerpoints in this auditorium, and this time I've come in early enough to plug into one - towards the end of the previous keynote here at OOPSLA I had to switch to taking notes on my PDA as my laptop ran out of steam. The second shared keynote between OOPSLA and WikiSym 2007 today is by Jim Purbrick and Mark Lentczner (or, Babbage Linden and Zero Linden), and we're going to hear about Second Life as a programming environment. Of course we also heard a lot about Second Life at AoIR last week, and I'm quite enjoying these presentations - if nothing else, they certainly have great visuals.

Jim begins by giving a quick overview of Second Life as an avatar-based, immersive, and persistent 3D multi-user virtual environment, with between 30,000 and 50,000 users online at any one moment. The world of Second Life has been built almost entirely by its residents, of course, and users own what they create in the space - this means that commerce within the environment is possible, and that content created in the game can be sold outside of it, or content from outside the game can be sold inside it.

Second Life is not a game, but a virtual environment, but games exist within it - and Jim notes the Tringo game which has become very popular within it: a combination of Tetris and Bingo which was created by an Australian software engineer inside the game and has now been licenced for the Gameboy Advance hand-held game system. Another common trend in SL is the increasing amount of live performance taking place in the space, some of which also have commercial aspects, and some of which have involved well-known first-life artists. Further, there is also a growing trend towards the creation of machinima in Second Life, especially so as it's possible to build sets, costumes, and props in this environment more so than in more narrowly game-oriented spaces.

And even many conferences now have a Second Life equivalent. Such events are obviously highly social, too, and (much like first-life conferences) the event becomes the kernel for a social occasion. There are now even charity events in Second Life, indeed - the American Cancer Society now orchestrates sponsored walks in the space which become virtual sightseeing tours past commercial spaces which donate their proceeds to the cause.

What is common to all of this, and to Second Life in general, is the great potential for experimentation - and the crowdsourced aspect of this environment means that elements of the space are developing rapidly, and in unforeseen directions. There now are virtual oceans, populated with virtual fish, many of which were created by a (previously) non-programmer in England who has now entered into a career in artificial life simulation. 43% of user are female, their median age is in the 30s - so these are not necessarily typical programmers. 15% of residents code, 30 million scripts are running, 25 million source files run 2.5 billion lines of code at present - Second Life is a massively multi-user programming environment.

And yet, Mark now notes, the language that all of this takes place in is a broken language: the structure of the programming language is old-fashioned and out of date by modern standards. The run-time environment for this language are the prims (geometric constructs in the space) which exist in objects, which in turn are placed upon the land - the scripts are the guts of the 3D object, and the 3D object exists in the world. Scripts can't do standard things common in normal computing environments (read and print, communicate with hardware), but can communicate with one another, with other objects, with the Web via HTTP, and can sense the environment and interact with avatars.

The current language employs a textbook virtual machine, modelling physical environments, and runs relatively slow. This is all wrong, Mark suggests - the language library is awkward and inconsistent, only 16kB are available per script, and few modern programming objects exist in the language (no user-defined types, arrays, classes, include files, libraries, shared memory, or versioning). But at the same time, such problems are micro-scale - on the macro scale, due to these characteristics, code exists in small units, the language allows for message passing concurrency, a fast development loop, code reuse with microeconomy, and massively concurrent programming. The language also ties into the in-space economy, as small code components are traded between programmers for Linden Dollars.

What this language solves are crucial problems which are otherwise typical in such environments: massively concurrent programming, localised state changes, enforced independence of code, object migration between regions, and an intermixing of code from thousands of programmers are all already taken care of. The fix for micro-level problems, then, isn't clear: what support libraries can support some 100,000 live scripts without trouble; how can such libraries be upgraded without crashing a large number of the millions of scripts created by the 15% of residents who programme, yet are not professional programmers; how can persistent states be managed in this environment? Also, in spite of all the problems, users build a great deal of very exciting spaces, and shouldn't be discouraged from doing so.

Jim takes over again to outline what solutions may be able to applied to these question. Language plurality may need to be supported, and he points to Mono as supporting this. The Second Life language LSL could run on CLI in Mono, which would also enable other languages to run alongside it on CLI as well; in the process, solutions to other problems may also be able to be found, and a further embrace of open source may also follow. However, this is relatively easy in a sandbox environment, but not in the massive, multi-server environment of the live Second Life. There is no single state for scripts, and the solution here is to serialise threads with call and jump yields and stacks at the yield point. Such stacks mean that threads can be transferred relatively easily to neighbouring regions where necessary. (Jim now demonstrates this model.)

Further, there's a plan to multiply the number of worker threads to better support the significant level of concurrency (some 10,000 scripts per region in Second Life). And because Second Life scripts are unlike those of desktop applications which have very defined startup and shutdown times, but may be running virtually all the time, there is a plan to introduce a set of application domains which store scripts for regions, and which may be given or denied runtime resources depending on whether they contain any running scripts at all. Further, memory consumption is another issue, and there is another workaround which is currently being implemented.

By now, LSL compiles to CLI, and most CLI assemblies have been translated. There is a simulator which runs LSL2 and CLI scripts, and there will be public tests of LSL on Mono in the fourth quarter of this year. This has also contributed to a fairly massive speedup of processing - by a factor of 20 to 200 for math-heavy applications. Jim also pleads with the programmers in the audience for what he calls 'better hammers': lightweight threading and lightweight application domains, and resource limits which are based on the land owned by a user in Second Life.

Mark now adds to this that even in spite of the current shortcomings of the programming environment in Second Life there is plenty going on in the space, and given the fact that some 15% of users do programme in Second Life there is something very significant going on here. Code development is a form of communication, and Second Life can be characterised as a virtual world for programming - Linden's own Studio Icehouse, a team of eight developers from locations across the U.S. and England, is one example of this.

First and foremost, this team operates within Second Life itself. They use spatialised 3D voice communication functions which are now available in this environment; they share slides and communicate using Twitter (within Second Life). Additionally, they use the shared text editor SubEthaEdit for sharing coding tasks and design, and a shared terminal programme called Screen for coding. This takes place on a number of screens in front of every programmer at any almost one point. What's lacking here is close integration with some more traditional tools, an ability to quickly see each other's screens, and decent collaborative whiteboard systems.

This points to a need to re-imagine integrated design environments. They need to facilitate communication, connect programmers, allow for both intentional and casual communication, and provide a workspace for people (rather than simply for coding). Fortunately, Mark says, Second Life now provides some of this. (And the two Lindens now finish their presentation by popping into the Studio Icehouse space in Second Life.)

Technorati : Second Life, WikiSym 2007, parallel computing, programming, software development, virtual environments
Del.icio.us : Second Life, WikiSym 2007, parallel computing, programming, software development, virtual environments