Multi-User Environments With Moving Worlds

January 30, 1996

There are many possible architectures for building multi-user worlds. Some systems will be based on a client server model, others will be based on a peer to peer model possibly using multicast communication, still others will find some middle ground.

One of the goals of the Moving Worlds proposal is to provide the functionality needed to build these different models without dictating which approach should be used. All of the likely models for multi-user worlds would use Moving Worlds features in the same way.

This document highlights the common requirements for all multi-user worlds and points out the parts of the Moving Worlds proposal that address those requirements. An example demonstrates one possible implementation of a multi-user world.

General Approach

There are two aspects to a shared multi-user world:

  1. Sharing the state of a world: whether the doors are open or closed; where movable objects are; starting animations simultaneously; and so on.
  2. Exploring a world, while seeing avatars representing the other people who are in the world at the same time.

The second aspect is a special case of the first in that a special object -- the user representation, or avatar -- is shared among browsers viewing the world. This document discusses the specific case of shared avatars and then generalizes the functionality to support any shared item.

The approach is the same for both the specific and general cases. One or more Script nodes are put into the world, each specifying either a general-purpose or an application-specific applet which carries out the network functionality. For each node containing shared information, either Routes are added between the appropriate events and the Script node, or the shared node itself is passed to the Script (which can then get and set the node's fields). The former approach should be used when information is needed every time the relevant node changes; the latter should be used when shared information is only needed occasionally.

Requirements for Supporting Multi-User Worlds

To support shared multi-user worlds, the following basics are needed:

Pieces Left Out

The goal of this document is to give potential users and implementors of Moving Worlds a feel for how multi-user systems could be built. However, one strength of the Moving Worlds proposal is that it balances simplicity against flexibility. There are thus many interesting and important aspects of distributed systems that this proposal makes no attempt to address. These areas are open, and the choice of how to solve them is left to the system builder. They include:


Separator {
  DEF bar BoxProximitySensor { }       # To detect our own position
  DEF foo Separator { }                # Avatars are added here
DEF baz Script {
  eventIn SFVec3f    position
  eventIn SFRotation orientation
  field SFNode       avatarRoot IS foo
  behavior ""
ROUTE bar.position -> baz.position
ROUTE bar.orientation -> baz.orientation

This example needs rewriting to match the final version of the API, 
but it should be close enough to give the general idea.

class MyNetworkProtocol extends VRMLApplet implements Runnable {
  void start() {
    # spawn thread to monitor network
  void eventIn(Event e) {
    # send position and orientation events to server
  void run {
    # monitors network,
    # on receipt of appropriate events from network calls
    # sends add, delete, change events to avatarRoot.