The dream of a universal "virtual world browser" using a standard protocol for interacting with a number of different worlds, similar to a number of different web pages, is attractive to anyone who has read "Neuromancer" or "Snow Crash." However, technically, that's a huge task to accomplish, and there is currently very little end user demand for such a client. Anyone creating an implementation would have to do it almost entirely out of speculation. History shows that standards created without clear current demand are seldom successful.
As an alternative, I propose starting the virtual world interoperability train by connecting existing services at the back end. This suggestion is based on having solved that kind of interoperability for a number of different customers already, and seeing a clear desire to achieve more integration among enterprise customers, who actually want to pay for the feature. Standards with customers tend to be more effective, and easier to implement, to greater success.
As a use case, to work through some of the areas needing attention, I use the following scenario, which is not far from what we're doing today, although without the benefit of interoperability standards:
- Company A operates chemical plants. They also use virtual world platform Q for training and simulation.
- City B uses virtual world platform S for city planning and emergency management. One of the plants of Company A is located in City B.
- City B wants to run an emergency preparedness scenario involving a large fire at the chemical plant.
- Company A has a nice, detailed simulation/model of the chemical plant in their virtual world.
- City B has a virtual view of the city in their virtual world, but no specifics regarding the chemical plant.
- Employees of Company A log into platform S to participate in the scenario, as usual (no big IT deployment needed).
- Employees of City B log into platform Q to participate in the scenario, as usual (no big IT deployment needed).
- Company A employees see city firetrucks pull up to the plant on the streets outside, and enter the plant.
- City B employees (including emergency responders) can enter the chemical plant, and see the results of the high resolution simulation (which may simulate things like chemical fires and plume dispersal).
To achieve this scenario, a system that interconnects the two back-ends of Company A and City B would have to deal with agreeing on the duration and "virtual area" of the exercise, agree on the content (terrain) used within the area, and agree on what entities take part of the simulation and how they interact. That's still a big mouthful, but it's something that has been done successfully in the military space for 20 years using the DIS protocol (*1).
While DIS has served the military well, it is not quite suitable for an enterprise or consumer class virtual world interoperability protocol for two reasons. First, it hard-codes a lot of military knowledge into the protocol, while leaving a lot of things interesting to civilians out of the equation. Second, it is based on a peer-to-peer, trusted-network model with sizeable PDUs being broadcast between participating peers. However, taking the benefits of DIS, such as a well-defined wire protocol, a reasonable terrain/entity/interaction division, and the good results being had with an "entity telemetry" approach, should be seriously considered when defining a new protocol for virtual world interoperability.
With that in mind, the areas that may need to be addressed by a back-end system integration include:
- Physical connectivity between the instances of platform S and platform Q. May be as simple as a TCP tunnel using a firewall hole, or as complex as a PKI VPN or SSL solution.
- Agreement on playbox (area of simulation) and duration of the scenario, to avoid a connection to linger longer than necessary, and to avoid problems like City B employees teleporting to other chemical plant areas in different cities of the virtual world of Company A.
- Agreement on the terrain (ground and buildings) of the scenario, so everyone sees the same thing, and nobody "runs through a wall."
- Agreement on high-level information about entities in the simulation ("people" vs "vehicles" vs "trees").
- Agreement on voice and text communications between the simulations.
- Agreement on finer detail information about entities — what do they look like; how do they animate.
- Agreement on user interface for cross-simulation entities; for example how to present a simulated 2D plant status panel to a city worker.
- Agreement on interaction between entities, for example:
- what happens when a firetruck collides with a Company employee.
- what happens when water is poured on a chemical fire.
- what happens when a City employee pushes the "intercom" button at the gate of the plant.
- Agreement on the exchange of instrumented data from the simulation, to help in run-time management and post-scenario analysis and review.
This is certainly a large nut to crack, and probably can't (or at least shouldn't) be done in a single big effort. However, I believe there are pieces from this list that can be knocked down relatively easily, and provide good value to existing customers — which means that implementation doesn't need to be on speculation, but can be driven by real needs, and real money, which is always a benefit when making sure that standards serve the needs of stakeholders, rather than the needs of creative engineers and academics with big dreams but little guidance from market demand(*2).
Footnotes:
(*1) Other approaches, such as HLA or TENA, have not received enough adoption to be widely accepted as successful. HLA has problems with cross-vendor interoperability, because it doesn't specify a wire protocol; moving a simulation from one RTI vendor to another requires significant engineering effort. We have also found that, in practice, HLA is also not suitable for an open-ended, general-purpose system with round-the-clock operation. As support for this view, note that large interoperability exercises, both demonstrations and for effect, are still largely based on DIS, unless significant engineering is put into the exercise pre-event.
(*2) An anti-example of a useful standard would be X3D, which simultaneously specifies too much detail, such as an Open Inventor style scene graph, and javascript bindings to the world, and too little, such as what a client/server model would look like, or how to migrate objects between hosts. As support for this view, VRML/X3D has been around for 15 years, with very little industry adoption, whereas a format like COLLADA is only 2 years old and already outstrips X3D content in amount and quality.
