[Bugs & Requests][Wiki]

1.3. The Problems of Virtual Worlds

That a popular technology for creating virtual worlds has not been created is hardly for lack of trying. A quick web search will turn up projects with such names as Netverse, Interverse, Dive, 3Dsia, Meme, and Verse, each of which have goals very similar to our own. Add seven years of VRML development and the recent explosion of 3D online gaming, and one would think someone would have created a pretty good virtual world by now; a 3D companion to the web. A few companies peddle products that claim to do just this, but through the power of closed standards they have completely prevented widespread adoption of their technology.

The fact of the matter is that Virtual Reality is hard. The major hurdles include, but are not limited to: performance of 3D rendering, lack of standard file formats, network latency and bandwidth, resource discovery and organization, single points of failure, security, privacy, trust, ease of use (by users, content creators and programmers), control, persistence, extensibility, and finally the insufficiency of existing protocols and software in addressing most of these issues.

Let us look at these problems more closely, for it is in thinking about the solutions that we may begin to form a design for our VR system.

The first two difficulties, rendering performance and file formats, are something of a red herring. With the proliferation of hardware-based 3D acceleration in standard consumer PCs, beautiful high resolution 3D graphics can be rendered on nearly any system bought within the last three years. We believe 3D graphics are a solved problem in computing and extremely well understood. One needs only select a few commonly used file formats to support; files in other formats can be converted as necessary.

Network latency and bandwidth occupy by far some of the most difficult issues with multiuser VR. There are two fairly effective ways of handling latency: the first is to "push" updates where interested parties are notified immediately when something happens, rather than having to poll for changes; the second is to move more processing to the client side and make the network protocol describe action on a higher level. These measures also help reduce bandwidth usage. In addition, the design of a flexible network protocol must address the fact that requirements vary from application to application, and even during a session — the programmer must have some amount of abstract control over networking.

Resource discovery is the problem of knowing what things (objects, avatars, sounds, etc.) are in a world and how they relate to one another. For example, when you load a web page that contains a hyperlink to another web page you have not seen before, you have "discovered" that new web page. Furthermore, you understand that it is somehow relevant to the web page you are currently viewing. Without such hyperlinks the World Wide Web would be thoroughly useless. Similarly, the elements of a VR space must be able to seamlessly link to each other such that the whole is more meaningful than the sum of its parts.

For a VR system to be robust, it must not contain a single point of failure. The idea of a single massive server farm running the virtual world is not only bad design, but quite antithetical to the fundamental principals of the Internet, which are based on decentralized processing. The World Wide Web is again instructive here: if a single web server goes down, the effects are isolated to the immediate content hosted on that server, and the rest of the Internet continues on its way. Furthermore, the web democratically allows anyone with a bit of connectivity to host his or her own web site. Shouldn't VR cyberspace be the same way?

Security, privacy and trust are absolutely crucial elements of VR, yet are often overlooked. By using public key cryptography and digital signatures, users can verify the identity of another user — incredibly important in an environment where it is trivially easy to otherwise masquerade as another user for sinister purposes. For any real multiuser application, identity authentication and per-object access control is a neccesity. Encrypted communications is also a desirable feature, especially for particularly sensitive activities like e-commerce.

That VR needs to be easy to use in order to be popular is self-evident. To users, this means a seamless experience of moving from world to world talking to other avatars and other such activities. To content creators, this means ease of rapidly creating and arranging the elements of a world in an intuitive fashion. To programmers, this means ease of understanding the building blocks of the world, which should follow the principals of object-oriented design.

Control is a sticky issue in a truly decentralized system. A simple example is that of gravity. If an avatar is responsible for reporting its own position, it may freely ignore gravity and float around. To enforce gravity, all objects would have to give up control of their position to a central server. However doing so creates both a single point of failure and increases latency, two of the problems we most want to avoid! For gaming centralized control is of course necessary to prevent cheating, but if one considers other uses of VR such as socializing or commerce, such "cheating" gains the user nothing and is more like cheating at Solitaire: completely pointless. Furthermore, provisions for centralized control would only invite censorship later. System abuse (one of the stated reasons for system control) is better handled by each client, which could have a feature allowing the user to ignore the offending party.

Persistence is a feature that involves storing changes to the world can remain ("persist") for a long time. This is quite the opposite of the typical online game, where the battlefield is reset at the start of every new game. The software running the VR must be able to save and load in save states to secondary storage (files.)

Extensibility is possibly the single most important feature of a VR system. If cyberspace cannot grow to accommodate changes in technology, what's the point? The VR technology will be obsolete before it even makes it into wide use.

Finally, we do not believe that any existing protocols are up to the task of easily satisfying the many requirements of VR we have explored here. A VR protocol should be object-oriented, distributed, secure, extensible, and simple. It should integrate with existing infrastructure as much as possible, and minimize latency by immediately streaming updates to interested parties when the world changes.