Use cases to guide chartering MMOX interoperability work
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.
Distributed Interactive Simulation
IEEE
The High-Level Architecture
IEEE
The Live Entity State Stream protocol
J. Watte