Virtual World Interoperability Use Cases

Use case "Friend Invite"

1. User A uses virtual world system A that complies with MMOX simulation interoperability.
2. User B uses virtual world system B that complies with MMOX simulation interoperability.
3. 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, ...)
4. User B clicks/activates this link.
5. 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.
6. User B can interact at some level with the objects from user A.
7. Objects that user B take out of inventory show up in some representative form for both user A and user B.
8. User A can interact at some level with any objects that user B bring out of inventory.

Use case "Collaborative Training"

1. 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.
2. City B has an emergency response organization that uses virtual world system B for training and scenario planning.
3. 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.
4. 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.
5. At the defined time, city workers (ambulances, fire trucks, etc) become visible to the chemical plant workers.
6. Interactions between users of the systems include conversations (voice, simulated radio, PSTN).
7. Interactions between users of the systems include a display of the fire as it propagates based on company A simulation models.
8. 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.
9. Interactions between users of the systems include the ability for city workers to load a chemical plant worker into a city ambulance.
10. At the pre-determined time, the interoperability ends; the city disappears from the company plant, and the company plant disappears from the city model.
11. 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.

Use case "Scene Transfer"

1. A user of virtual world A has prototyped an interesting environment.
2. The user decides to donate that prototype to an organization that uses virtual world system B.
3. 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).
4. 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.
5. All content that is part of the prototype and that A has sufficient permission for is included in sufficient detail in the export.
6. 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.
7. The exported data is attributed (in aggregate) to user A.
8. Organization B can load the exported assets into their virtual world.
9. 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.
10. Scripting and interactive behavior shows up only if the destination virtual world implements a scripting or behavior system compatible with the source world.

Use case "Analysis"

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

Use case "Data Logger"

1. User of virtual world system A purchases a 'data logger' tool from company B.
2. 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.
3. 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.
4. 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.
5. Enough data is available to the logger that search functions like "find the time when avatar X interacted with vehicle Y" can be implemented.
6. Actions by avatars in the connected peers during playback do not affect the objects provided by the logger tool.

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 on the list).