Virtual World System Interoperability Standard

I'm starting to collect my thoughts on the subject of virtual world interoperability system standards into this document, because the subject is becoming too big for me to keep in my head all at one time.

The basis of this document is to describe how the interoperability story of http://www.interopworld.com/members/node/22 can be implemented in reality, between heterogenous virtual world providers.

A persistent virtual world system is quite complex, involving both client and server software and hardware. It takes all the trappings of a networked multiplayer multimedia computer game, and adds persistency, communication, the ability for users to change the environment, and any number of services (collaboration, interaction, etc). There are several different technologies on the market that provide different trade-offs between values such as simulation accuracy, security, freedom, quality, cost, etc. The details of how the persistent world is simulated and updated on the participating client machines vary between different implementations. However, all of these platforms want to provide low-latency, real-time interaction between many participants. This real-time, 3D, interactive constraint makes virtual world technology very different from the 2D "text driven" web that came before it. Thus, different kinds of standards are necessary to make inteoperability work.

For interoperability to work in such a world, the server side of each system provider all need to agree on what the shared world looks like, and each provide a view of that shared world to the clients connecting to the same space. Because different servers have different capabilities, it makes most sense for each server to simulate the entities that are introduced by that server, and provide the other servers with information about how that entity affects the shared world. This way, all the servers simulate an overlapping area, and introduce their own entities into that shared area. Meanwhile, all of the entities in the area can be visualized to each client, through the exchange of entity effects, where basics such as position, looks and animation are included.

The main flow is as follows:

1. User 1 decides to host an invited session. This could be a one-hour conference, or a multi-year "permanent" exhibition.
2. User 1 describes the hosted session to "his" virtual world provider, who provisions for the session. This might be as simple as opening your island in Second Life, or involve renting server capacity by the hour using micropayments, or something else that is up to the provider (not the standard).
3. User 1 provides information about the session to other users. This information includes a locator URL and some credentials (such as an access code, password, or similar).
4. Users 2..N provide the locator URL and the credentials to their respective virtual world providers, after which they are "teleported" into the world as hosted by User 1. Each virtual world provider retains simulation responsibility for its users, within a copy of the given world.
5. Each virtual world provider hosts its own users, and the objects created by those users. The different hosts exchange telemetry data with the hosting "master" server, who updates all participants.
6. Any "non-native" object in a given virtual world provider server instance will be represented using some set of mesh, texture, animation and sound data; the rich model of that object will only execute on the host system for that object.