Gaming in the Metaverse

PDF Version of this Paper

The Metaverse and Second Life

In the beginning of Neal Stephenson's Snow Crash, lead character Hiro Protagonist returns home after a rough day at work. He goes to his computer and logs into a virtual world known as the Metaverse, a world where anything imaginable can be programmed. Stephenson writes that

Like any place in reality, the [Metaverse] is subject to development. Developers can build their own small streets feeding off the main one. They can build buildings, parks, signs, as well as things that do not really exist in Reality, such as vast hovering overhead light shows, special neighborhoods where the rules of three-dimensional spacetime are ignored, and free-combat zones where people can go to hunt and kill each other (23).

The Metaverse functions as a canvas, bare when first created, but later fleshed out by savvy individuals and corporations. This sort of an immersive virtual world has long been the stuff of science fiction legend. To be sure attempts at implementing such an environment have been made, but technology has not been up to the task. Could that be, however, until today? Second Life, from Linden Lab, is a world that shares many of the fictional Metaverse's characteristics -- including the development of combat zones and other types of multiplayer games. Such work brings about an interesting question: In the future, will game development continue to occur as isolated projects or will developers and corporations start creating their products inside the virtual world of Second Life? These in-world games are a target of Linden Lab. In June the company hosted its first annual Game Developer's Competition. But does this desire translate into an environment that is conducive to game development? While Second Life provides a fascinating platform for study and experimentation, inherent limitations in the programming model seem to dictate that for now its in-world creations will be unable to match up to dedicated games.

Perhaps the most interesting aspect of Second Life is that it is an attempt to create a world entirely populated with user-designed content. Though text-based MUDs have long supported this sort of interactivity, graphical environments traditionally have not. Even last year Richard Bartle, a noted visionary in the field of gaming and virtual worlds, wrote that such a system was impractical. He considered the idea of allowing users to create free-form content, but noted that both performance considerations and user ability dictated that currently such a concept is infeasible. ``For the time being,'' he wrote,

graphical worlds who want to allow some degree of building are therefore pretty well stuck with using predefined components or restricting creation to artistically blessed players. That's for object creation; new functionality would need to be hugely controlled if it were to escape being employed as a tool for abuse -- so much so that it hardly seems worth bothering implementing (460).

Yet Second Life did implement the building of both objects and behavior, and made them available to all users. Tutorial content such as the ``Ivory Tower Library of Primitives'' introduces interested users to the concepts and basic tools of content development. Public ``sandboxes'' provide areas in which new creators can practice their skills without having to own land. The engine created by Linden manages the created objects and provides the framework for users to build content. This content is what users see -- for the casual user it is ``the game.'' Linden and its investors understand the importance of this concept. A late October press release announcing a new round of investment included a quote from Ebay founder -- and now Linden investor -- Pierre Omidyar.

Second Life has a vibrant community where content creators and consumers reinforce one another. Better experiences attract more users, which further attracts entrepreneurial developers to enrich the experience. Opportunities abound and value is determined by the community.

One of the main appeals of Second Life is its openness. A user can acquire whatever she can dream up, either by creating it herself or purchasing it from one of a wealth of in-world vendors.

The world of Second Life consists of a patchwork of ``sims,'' squares of land created for development. Users buy land, and on that land they are able to create anything they desire. The amount the user can build is limited to the amount of land that he buys, and this land is in turn limited by what he is willing to pay. Everything about the world exists on a collection of servers operated by Linden Lab. The content lives on these servers as a collection of objects. Vehicles, buildings, even creatures -- all are constructed out of a small collection of primitives which can then be manipulated and linked in order to form larger and more complex creations. The behavior of objects is then determined by assigning scripts to them. These scripts can do very simple things -- a display in a store might transfer a notecard when touched -- or they can be much more complex, even implementing some level of artificial intelligence. These primitives and scripts can then be controlled by the user. For instance, a vehicle is simply a collection of primitives formed into a familiar looking shape. Its characteristics are determined by the scripts assigned to it and the way these scripts interact with the game's physics engine. The scripts define the way in which the user will interact with the vehicle, creating the proper controls to allow the user to go forward, brake, turn, and so forth.

An important exception to this creation via primitives is that of avatars. The avatars in Second Life are human figures that can be posed, animated, and which the user can manipulate using a variety of appearance controls and clothing textures. Additional appearance changes can occur through attached items. For instance a character wishing to have a tail would obtain a tail item and then attach it to his avatar. The item would then be linked to the user and would move and animate with him accordingly. Animating avatars is important in Second Life, where it seems the world's favorite pastime is to go to a club and dance. Complicated maneuvers can be automated via objects like ``dance rings.'' These rings contain scripts that will animate the avatar and cause it to perform all manner of performances the player most likely could not emulate in the real world. This sort of activity is so popular that walking or flying around the map and browsing the listed events it would be easy to conclude that clubs and dancing comprise the entirety of this three-dimensional world of make believe.

Creating Games in a Virtual World

Dancing isn't the only thing to do in Second Life, however, and inside of the virtual world there have arisen groups of developers interested in using Second Life as a platform on top of which to build games. While simple casino games abound, particularly of interest are the MMOGs, or massively multiplayer online games. These games exist wholly inside of Second Life, as functionality and behavior attached to in-world objects. In a way these games are a natural extension of the Second Life platform, which provides a physics engine and all the social aspects needed for multiplayer online gaming. What it doesn't provide is rules and procedures. Those are left to the imagination of the users. Though these games are clearly a desired part of the world -- the Developers Competition being an attempt by Linden Lab to nurture this segment of the population -- even they are not directly created by the company. Instead the games are programmed just as is anything else in-world: by attaching scripts to objects. Inside those scripts are the behaviors that govern gameplay and the player's experience. One particular game still in the development phase is DarkLife, an RPG set inside the metaverse. The game's description positions itself inside the wider world. A large but thin book titled ``The World of DarkLife'' fills in backstory -- or lack thereof -- for the players.

DarkLife is set on the island of Navora, once a quiet corner of the multiverse but now brimming with trouble. The quiet fishing and trading town with its pretty woods and ancient castle has found its borders troubled as odd creatures have moved in.

No one knows where they came from, only that they are dangerous, and so the call has gone out to push back the dangerous beasts and keep Navora safe.

The reference to the multiverse is an acknowledgement that the DarkLife game exists as a part of the greater world. Though the game might wish to create an immersive environment for its players, the constraints of its environment prohibit it from being fully so. First, players have the ability to teleport off the game island and into another part of the Second Life world at any time. The game is unable to force them to stay, because fundamentally the game is just a collection of objects that communicate and share behavior. Its rules are still governed by the fundamental characteristics of the world, and though the world may allow the developer to disable for instance flying in a given landmass, it does not allow her to prevent players from teleporting.

Not ``In the Game,'' but ``Wearing the Game''

One interesting characteristic of gaming in Second Life is that a player doesn't really enter the game, but instead wears it. Though MMOGs in Second Life do have defined landmasses in order to allow for themed landscaping, development, and creatures, the space itself does not constitute the game. As mentioned earlier, behavior (scripts) is attached to objects. Therefore, in order for a player to participate in a game, he must obtain the game's behavior via some object that possesses the game code. For DarkLife, this behavior comes via a backpack. The choice of a backpack came from necessity. The DarkLife developer, whose Second Life name is Mark Busch, explains:

the problem with secondlife is that you don't get access to any database of some kind

so every interactive thing must be an object

and because the game is so widely spread people have to take that interactivity with them

hence a backpack :)

The pack manages all the player's characteristics, including health and stats. None of these attributes are directly attached to the player himself; they're just variables in the code run by his backpack. The monsters that roam Navora do not attack players, they attack backpacks. Certainly when attacked it is the player from whose avatar blood is animated to flow, but both the attack and the player's response are managed by the code on his back. An attack occurs when a monster, who is constantly sending its location out in a chat whisper, finds a response¹. The backpack returns its location and the two trade back and forth information on the characteristics of the attack. Yet if a player simply removes her pack the monster is left bewildered. To it the player is now invisible, though she's still standing precisely where she was while being attacked. The world is exactly as accessible to non-players as it is to those who are participating. No true roleplaying game would accept non-players breaking into the game world as virtual voyeurs, but in Second Life it is something that is nearly impossible to prevent. This causes a disruption in the immersiveness of the game. Bartle says that the ``key to immersion is persuasion. The more persuasive an environment is, the easier it is to become immersed in it'' (239). But how can a player be persuaded that he is in a dangerous forest when a non-player walks flippantly up to the very scorpion that has just been causing his health no end of damage? Game designers can incorporate measures to encourage compliance, but they cannot mandate it. In DarkLife players are teleported into the building where they can purchase their backpack. Directly next to the teleport location are the books containing the aforementioned ``World of DarkLife,'' one entitled ``READ ME FIRST!,'' and a final one containing the game manual. Yet if users choose to ignore these elements or enter the island in some other manner, neither the game nor the developers can do anything to stop them.

Scripts in the Hands of an API

This discussion of immersion raises an important point: games in Second Life are at the mercy of the API² Linden Lab presents to developers. Programming in-world happens in what is called the Linden Scripting Language. This language is unique to Second Life. Though in appearance and syntax it shares much with commonly used languages like Java and C++, LSL is not a general purpose language. Instead it contains a set of functions very specific to Second Life. Developers can use these functions to create in-world behavior, but the limits of LSL and the Second Life architecture are the limits of what they can create. For instance, as talked about earlier the game of DarkLife exists in the backpacks. The user's backpack determines everything that occurs to him in-game. This design violates what is perhaps the most important maxim of MMOG design. Bartle isolates this warning in its own block of text (emphasis his):

Important: Absolutely no decisions with regard to what happens in a virtual world can be delegated to a client. No decisions. That's no decisions.

His forcefulness is not unwarranted. If there is a lesson to be learned from the past years of MMOGs, it is that users who want to cheat the system have far more time and talent on their hands than anyone wants to give them credit for. If there is a way to cheat, they will find it, and allowing the client to provide authoritative answers is clearly a vulnerability. In Second Life the situation isn't exactly the same, but the concepts still apply. Though the scripts that control DarkLife run on the server, they are controlled by objects. These objects are in turn controlled by the user. Though the user cannot get into the backpack object to modify its functionality, it would be possible for someone with talent to write her own backpack object, one which communicates with monsters in the same manner but which internally does not respect negatives such as damaged health. So in Second Life the risk is not on the client-side, it is instead in user-supplied server-side content. While this may seem a highly academic distinction, it is important. Because all content is user-supplied and unprivileged, Second Life does not distinguish between DarkLife code and malicious user-code. To the server both are equal-class citizens. There is no higher power to which to appeal and assure that game code is working correctly. The security of game communication rests on the obscurity of its chat channels, and these are only obscure due to the processing time it would take for a malicious user to scan through the available channels. Many developers hope that future API enhancements will improve this situation. Perhaps truly authenticated communication support could be added, so that the backpack could be sure it is talking with a valid monster and a monster could be sure it is being slain by a backpack that is following the rules. Or perhaps the elements of the game could communicate with a controlling entity. A recent version of the game introduced XML-RPC functionality, which allows scripts to communicate with applications external to Second Life. For instance a game like DarkLife could use an external server to handle all in-game logic; the backpacks would serve to animate and communicate with the user and relay actions to the external server via XML-RPC commands. The server would then determine their outcomes and relay them back to the backpack. Such a design would be far more in line with accepted roles for clients and servers, but instituting another layer of servers could have negative influence on performance.

No Shortcuts in Execution

The limited nature of the Second Life API means that the in-world developer has less tricks for optimization at his disposal. Performance is always going to be a problem for Second Life. The nature of user-created content is both friend and foe to virtual world. It adds an amazing dynamic to the world, but it also means that there is no set of Second Life objects that can be cached once on each client machine and then used again and again. Users can upload custom textures for their objects, and for each location one visits in Second Life a new set of textures and objects has to be sent over the network and then rendered. Similarly, the sim server can never make assumptions about how an object is going to work, since the user may have coded the object's behavior in a way different from what the server is coded to expect. As Bartle notes, ``Loops can't be detected, only assumed: The virtual world's engine can stop a player-created loop after a million iterations only to screw everything because the critical million-and-oneth iteration never got to execute'' (460). Every script must be executed to the letter. Traditional game developers tune every last ounce of their creation, or pay the price in poor performance. Second Life, though, through requiring development occur in the limited scope of LSL, hamstrings such tuning. There is no ability to get ``close to bare metal³.'' The higher-level language nature of LSL leads to code that is more complicated than it would be if written for a dedicated environment. This necessarily makes it less efficient.

To illustrate more fully, it may be useful to consider an example from hardware. The FPGA, or field-programmable gate array, is a wonderful idea. Traditional processors are some of the most complicated structures in modern engineering. Developing a processor design and taking it through the fabrication process costs millions upon millions of dollars. The FPGA revolutionizes that process. Instead of having to go through the expensive process of fabrication, the processor structure can be programmed into the FPGA. The FPGA contains generic switch and routing capabilities that can be constructed into a design that perform the logic functions of the processor desired. This is superior to emulation because the processor functions are mapped into the processor itself, instead of having an emulator layer translate the given instructions into something the particular processor can understand. The processor is the processor desired instead of simply something different that can accept its instructions. And yet traditional processors continue to exist because FPGAs suffer in terms of both speed and density. Because they target the widest possible number of applications, their structure is too generic to optimally implement any of them. FPGAs can do a huge number of things well, but none of them perfectly. Additionally, FPGAs suffer problems related to density. In order to have all the generic capabilities that allow it to be so adaptable, an FPGA must contain far more hardware logic than would a dedicated chip. This makes each FPGA more expensive than a similar dedicated chip (though certainly the overall costs of a low count run are cheaper with an FPGA than they would be with a dedicated chip), and also makes it bigger. A game written in Second Life is exactly the same. Second Life is the FPGA, able to do just about anything. The game design can be implemented into the generic Second Life logic, and it will run, but it will never be able to run as efficiently as it would when written as a piece of dedicated software.

Only Time Can Tell

It is still too early to say whether MMOG development in Second Life will really take off. Those creating game content now are doing so while Second Life development concepts are still in their infancy. The ground that this round of developers tread will no doubt be covered again by future development, with programmers who will be able to learn from the present-day in order to do everything just a little bit better and be just a little bit more efficient. Then even newer developments will come along, and the whole cycle will continue to repeat itself. Each round of development will continue to squeeze just a bit more performance out of the engine, and further API development will enable new sorts of behavior that before simply wasn't possible.

But even as gaming in Second Life adapts, it will continue to remain slower than dedicated solutions. The model simply requires this: the additional layers are bound to produce extra overhead no matter how effectively they are optimized. Where Second Life is poised to thrive, though, is in the gaming niche analogous to that of FPGAs. Even though it's slower, and even though it's a little more complicated, it's still cheaper and easier than developing a custom solution from the ground up, and the built in curious userbase of Second Life means that games will always be able to find players to check them out. While iD definitely won't be releasing Doom 4 as a Second Life sim, the Linden virtual world is ideal as a platform for small teams of hobbyist developers to give life to their ideas.

1: The Second Life engine supports four billion chat channels. The DarkLife developers chose a certain few to use for a constant back-channel of conversation that goes unseen by players. This is the backbone of communication between in-game objects.
2: Application Program Interface
3: ie. to remove all unnecessary layers and components, getting as close to the machine speed as possible.

This document was translated from L^AT_EX by H^EV^EA.