Forterra Systems

jwatte@gmail.com

Virtual Worlds Interoperability MMOX Use Cases Requirements Virtual worlds, typically implemented as multi-user shared simulations, are becoming increasingly used for serious work in addition to the traditional uses of research and entertainment. Based on actual need identified by interaction with various customers when working on virtual world interoperability over the last four years, this draft summarizes the main interoperability functions required to satisfy those needs. From these use cases, requirements for the MMOX virtual world interoperability charter can be derived.

Over the past four years, Forterra Systems has worked with various customers to interoperate the OLIVE virtual world platform with various external systems, ranging from simple extraction-and-analysis tools up to full-on virtual world simulation interoperability. Based on this experience, the following five use cases have been extracted and presented for consideration as one basis from which to derive requirements for future vendor-neutral interoperability work. The use cases are formulated to clearly show the actions and affordances expected to be visible to end users, as well as showing what value interoperability brings to the table, as opposed to features implemented in a system specific manner.

User A uses virtual world system A that complies with MMOX simulation interoperability. User B uses virtual world system B that complies with MMOX simulation interoperability. User A wants user B to visit him/her in system/world A, and gets a suitable URL from his/her system (A), and sends this to user B using any transport (mail, IM, integrated communication, carrier pigeon, ...) User B clicks/activates this link. After a brief "loading" screen, user B sees user A in user A's environment, including a representative form of any simulated object in that environment. User B can interact at some level with the objects from user A. Objects that user B take out of inventory show up in some representative form for both user A and user B. User A can interact at some level with any objects that user B bring out of inventory.

The benefit is that users of different virtual worlds can invite and communicate with each other using the virtual world metaphore, regardless of the particular virtual world technology used for their "home base" virtual world.

Company A operates a chemical plant in city B. Company A uses virtual world system A to do simulation/training/command-and-control of its plant. City B has an emergency response organization that uses virtual world system B for training and scenario planning. At a defined time, company A and city B agree to connect their worlds for a defined duration to conduct a training excercise related to a fire in the chemical plant. At the defined time, a representation of the detailed model/simulation of the chemical plant shows up at the right address in the virutal world for the city workers. At the defined time, city workers (ambulances, fire trucks, etc) become visible to the chemical plant workers. Interactions between users of the systems include conversations (voice, simulated radio, PSTN). Interactions between users of the systems include a display of the fire as it propagates based on company A simulation models. Interactions between users of the systems include the ability for firefighters to pour water (or other agents) onto the fire, and have the simulation respond. Interactions between users of the systems include the ability for city workers to load a chemical plant worker into a city ambulance. At the pre-determined time, the interoperability ends; the city disappears from the company plant, and the company plant disappears from the city model. Session record/review capability used by the city in virtual world B includes all communications and interactions made in the system including those internal to company/world A.

The benefit, in addition to the Friend Invite use case, is that interoperability can be limited in time and (virtual) space to protect potentially sensitive information. Additionally, this use case shows the benefit of defining interactions between objects operated by one system with objects operated by another system, leading to synergistic simulation similar to that evidenced by the DIS protocol, but applicable to a broader, non-military audience.

A user of virtual world A has prototyped an interesting environment. The user decides to donate that prototype to an organization that uses virtual world system B. The user "exports" his/her prototype to a series of common data containers (textures, meshes, scripts, etc) of some standard format (e g COLLADA, X, FLT). All content that the user has created and owns (no matter what the permission) that is part of the prototype is included in sufficient detail in the export. All content that is part of the prototype and that A has sufficient permission for is included in sufficient detail in the export. No content that is restricted from this kind of use is included in the export, although a reference saying "an object with characteristics C named N was here" may be. The exported data is attributed (in aggregate) to user A. Organization B can load the exported assets into their virtual world. Meshes and textures in a well-known standard format shows up in world B as expected, with attribution to user A, no matter what technology the respective virtual worlds use. Scripting and interactive behavior shows up only if the destination virtual world implements a scripting or behavior system compatible with the source world.

The benefit is that work done to develop virtual world content for one world can be transported to another world with minimal manual intervention. While things like scripting and simulation algorithms may not transfer over (depending on the degree of implementation similarity between source and destination), the main 3D content, including meshes, textures and layout, does. Additionally, such transfer is shown to respect intellectual property rights of content that may have been re-used to generate the scene.

ISV A creates a system for analyzing movement of avatars in a virtual world. The product from ISV A can be connected to any virtual world or worlds implementing interoperability. When the tool is connected, certain patterns of movement are detected and flagged by the tool. The tool can report recognized actions through chat, or through introducing "flag" objects into the world. A virtual world user interacting with the "flag" objects can pull up a web page that gives information about the detected interaction.

The benefit is that development effort to generate various tools can be replicated across multiple virtual worlds, saving a lot of re-implementation effort for ISVs interfacing with the virtual worlds market. Additionally, the benefit of a commonly agreed external data representation enables formulation of standardized metrics and measurements, which is expected to greatly help research into the use and evolution of virtual worlds.

User of virtual world system A purchases a 'data logger' tool from company B. When attaching the data logger tool to the virtual world, the data logger receives information about all the objects, interactions and communication in the system. After the logger has been detached, the data logger tool can be seen as a separate "virtual world peer" and connected to by any virtual world using interoperability. The logger implements play and shuttle controls that allow the action from the original session to be re-played at a later time. Any attached virtual world peer will see the recorded actions. Enough data is available to the logger that search functions like "find the time when avatar X interacted with vehicle Y" can be implemented. Actions by avatars in the connected peers during playback do not affect the objects provided by the logger tool.

A generally agreed-upon data presentation and interchange standard, implemented using server peer-to-peer co-simulation of a shared space, enables a large variety of use cases. The Data Logger is interesting in that it shows how data can be both consumed, and produced, by systems that are not in themselves virtual worlds, yet provide clear benefits to users of virtual worlds. Like the use case Analysis, the ability to do this with any world significantly reduces the burden on ISVs. Additionally, one can consider the potential future markets that open up when virtual world record and playback (in full 3D, as opposed to a plain video stream) is a deployed, easy-to-use, generally applicable capability.

For purposes of these use cases, we can consider cases where "A" means "OpenSim" and "B" means "OLIVE," or use cases where "A" means Croquet and "B" means "Second Life," or "A" means Project Wonderland and "B" means "Multiverse.net" (although representatives from those two organizations are not yet participating in MMOX). The point is that interoperability does not require the source and the destination to be from the same technology family, use the same simulation technology, or even that the clients must understand protocols other than those native to the respective simulation system.

This document describes possible use cases of virtual world interoperability, and does not describe specific security related technology. The implementation of technology to provide functionality for these use cases needs to separately consider the security implications of such implementation.

This documents does not require any IANA action.

IEEE IEEE J. Watte