IEEE Internet Computing: VWRAP for Virtual Worlds interop

Tentative skeletal pre-draft of a possible article. --- Remember the wiki motto, "Be Bold." :-)

Introduction

• <<<Set the scene with an epic literary start>>

Mankind is an imaginative, storytelling species. From our first glimmers of intelligence in the wielding of a bone as a weapon, through to today's visions of our future among the stars, we have always imagined new worlds that are different to those of yesterday. We have continually redefined our physical world through progress, created innumerable fantasy worlds through sheer imagination, and told stories about past worlds and future worlds to keep our culture and visions alive. Some new worlds we have even reached physically by departing from our little planet of origin into the darkness of space. We're really not happy with just a single world.

Computing is a microcosm of everything else that Mankind does, so it's no surprise that our worlds of the imagination have become part of this new space as well, indeed an essential part. We call our computer-driven worlds virtual worlds, although the adjective is oddly superfluous. As has been the case with all our worlds throughout history, these CPU-assisted worlds gain their immersive reality as worlds entirely within our minds.

This article is about a small corner of the huge space of virtual worlds, a corner in which one large established virtual world and a constellation of small newer ones share sufficient commonality that a desire for interoperability between them has taken root, under the auspices of the IETF.

A brief history of virtual worlds

• <<<The only thing I can bring to this section is a small acquaintance since 1996 with what became ActiveWorlds, a decade of excessive online gaming in 3 major MMOs, and 5 years of Second Life + a little Opensim. I don't consider this a usable background for writing even a brief history of VWs. Morg>>>

The Second Life virtual world model

• <<<Intro to Linden Lab and the rise of SL>>>

• <<<Description of the SL grid/simulator/client architectural and virtual space model>>>

At the outermost level, the Second Life architecture is comprised of a large number of region simulators, each of which implements a 256m x 256m unit of virtual acreage. These simulators and their separate regions are organized into a grid, which is a 2D-tiled flat virtual world. A user's client application or viewer connects to this world, which gives the user an identity and a virtual presence at a single location in one specific region. Client controls then allow free movement within the current region, transparent crossings into adjacent regions, and teleport to remote regions of this virtual world.

• <<<Description of the SL data model --- it's obvious to us, but not to everyone!>>>

Grids, simulators and clients are the macroscale entities of the Second Life platform, but this architectural view says little about virtual worlds as an immersive experience. That experience is provided by the visible and audible components of the 3D world as displayed by the SL client application, which renders the 3D graphics objects as a 2D projection for the screen and delivers spatialized audio to the user's sound system.

In order for the client to do this, those world components (termed "assets" and "objects") are streamed from the simulators to each client whenever they are in visualization range, and cached by the client for future use. This data model is a fixed point of the world architecture of Second Life. The fact that user generated content is copied to clients by design has fundamental implications for non-technical issues such as object ownership and copyright which often arise.

The main components of the virtual world which together provide the immersive experience are avatars which are the visible instantiation of a logged-in user, assets such as textures, animations and sound files, and objects which are user-built assemblies constructed out of parametrized geometric primitives. The client-side rendering of these miscellaneous components creates a mashup of these visual elements on the screen, and if done well, the end result is a highly believable and hence immersive representation of the user's avatar within an imagined world.

It is worth noting that the concept of mashup provides a useful alternative way of thinking about interop. Virtual worlds interoperate whenever the mashup displayed by a client contains components from more than one virtual world. This is an effective definition which avoids the pitfalls of trying to define interop architecturally amid the many and varied VW architectures in use today.

Opensim and open source virtual worlds

• <<<libsecondlife and reverse engineering of SL protocols>>>

• <<<Founding of Opensim project and goals>>>

• <<<OSgrid and other Opensim-based grids>>>

• <<<Interop mechanisms available in Opensim>>>

• <<<User expectations for the SL/Opensym ecosystem>>>

Defining the VW interop problem space

• <<<LL+IBM, founding of the AWG, and scary numbers>>>

• <<<The OGP agent domain + region domain model>>>

• <<<One-sentence description of capabilities>>>

• <<<The OGP interop trial of Summer 2008>>>

• <<<Taking OGP to the IETF --- MMOX and problem space overload>>>

• <<<Narrowing the VW interop problem space: OGPX>>>

VWRAP: a services model of VW interop

• <<<Extending OGP to multiple VWs through policy-defining RDs == OGPX>>> (acceptable simplification?)

• <<<A successful OGPX BoF, and the foundation of VWRAP workgroup>>>

• <<<Brief description of expected VWRAP services>>>

• <<<High level overview of protocol entities>>>

VWRAP: the work ahead

• <<<Goals, rough timeline, and open invitation>>>