Is a Universal Virtual Worlds Viewer possible? March 20, 2009Posted by justincc in opensim, opensim-dev, opensim-grid, opinion, secondlife, virtual-environments, virtual-worlds.
Introduction – the Problems of a Universal Viewer
In common with quite a few other people, I’ve speculated before about a very different internet architecture for virtual worlds from that of the current Second Life. Instead of virtual worlds comprised of big ‘grids’ of simulators sharing central services, there would be a much larger number of independent virtual environment ‘sites’ on the internet. You could visit a site just by typing its URL into a viewer’s address bar. Your virtual environment inventory and appearance would not be maintained by any particular site – instead it would come directly from your own machine.
As you can see, this very much parallels the way in which one visits websites with a web browser today. But for this to work, there must be a single set of protocols to provide virtual environment functionality (much as HTTP and HTML provide common web functionality today). And if one is to get to this single set of standards then the virtual environments that it encompasses need to have a fair amount in common. The only problem is that different virtual environments arguably don’t have all that much in common.
For instance, suppose that you find an LSL (Linden Scripting Language) script which allows you to close, lock and unlock a door. This script runs quite happily in the virtual environment of site A. However, you then take that into your inventory and then decide that you want to also use it at site B (let’s ignore both the question of whether LSL is a desirable language to use and the broader issue of running user scripts at different sites).
In order to run that script at site B, that site would need to provide a suitable execution environment. Among other things, it would need to
- Provide an event model which can provide touch, timer and sensor events
- Understand that UUIDs can be used to reference sounds and textures in the system
- Know that speech can occur on different ‘channels’
- And provide a way for ‘objects’ to communicate messages between themselves.
Naturally, there isn’t much of a problem if site B is running exactly the same protocols as site A (e.g. site A is OpenSimulator with the Second Life protocol and site B is a Linden Lab system). But what if site B is operating on another platform, such as Project Wonderland? In order to run that script on a Project Wonderland site, it would need to be able to emulate all the bullet points above as well as provide the ability to execute the LSL. I’m not familiar with the architecture of Project Wonderland but I’m presuming that some of this could be quite awkward, possibly to the point of impractability.
Of course, LSL and Second Life script execution environments aren’t a fixed point. It may be possible to come up with a compromise common execution environment that spans different virtual world architectures, though this is far from a foregone conclusion without getting into the really nitty-gritty details.
Execution environments are, however, just the tip of the iceberg. Different virtual environments may also have
- Different ways of matching processing power to topology (e.g. they won’t tie machines to emulating fixed size regions)
- Fundamentally different ways of graphically representing objects (e.g prims versus meshes)
- Or even a completely different system architecture (e.g. Croquet’s peer-to-peer approach versus Second Life and Project Wonderland’s client-server architectures).
It is difficult to imagine how a single set of protocols could span rather disparate systems.
LESS is more? (groan)
Jon Watte, the CTO of Forterra Systems has a very interesting alternative to the one protocol fits all approach. This is the LIve Entity State Stream (LESS) protocol that has recently been batted back and forth in the Internet Engineering Task Force’s (IETF) Massively Multiplayer Online X (MMOX) mailing list. Rather than specify the protocols for a large part of the virtual environment in order to enable direct inter-world avatar travel (as the Linden Lab initiated Open Grid Protocol (OGP) tends to do), LESS aims to establish telepresence between disparate worlds. Instead of travelling directly to another environment, a space in your local environment would be set up to mirror a space in the remote environment (that is, if there is a cube in the remote environment at relative co-ordinates of (2,2,2), you also have a cube in your local environment at (2,2,2). State changes for these objects in the remote environment are mirrored in your local environment (e.g. if the remote cube moves to (4,4,4) then your local mirror cube is moved to (4,4,4)) and vice versa.
This avoids the problem of having to harmonize rather different virtual environments. It may also have security advantages – if company A using Second Life and company B using a Forterra Systems installation want to hold a joint virtual meeting, then they don’t need to both implent a universal protocol and allow direct system access for each other’s users. Rather, they could just establish a temporary telepresence connection between the two systems that could be torn down once the meeting was over. In a very small way my own Parallel Selves Message Bridge mirrors this approach since it transmits Instant Messages between proxy selves on different systems, rather than directly via some shared common mechanism.
But just as telepresence in real life is somewhat lacking, so may be virtual telepresence (leaving aside any remarks about any virtual environment being less satisfying than a real one :). The dream of being able to freely move between virtual worlds, as we’ve seen from the popularity of the Second Life teleport experiments and OpenSim’s own Hypergrid architecture, is a pretty strong one.
There may well be room for both common clients and virtual telepresence, at the cost of abandoning any idea that there will be a single universal client for accessing every virtual environment. Those environments that are similar enough to implement a common protocol can share a common viewer. Where the incompatibilty between environments is too great to overcome, or even for other reasons such as greater security, a virtual telepresence approach could be employed to share communication and simlulations between virtual worlds.