Moving Worlds - MultiUser

Intro

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 MW proposal is to provide the functionality needed to build these different models *without* dictating which approach should be used. The features described would be used identically in both models.

This appendix highlights the key base requirements that any multi-user world has in common and shows which parts of the proposal address those requirements. We then give an example to show how this might be implemented.

What we don't discuss

The goal of this appendix is to give potential users and implementors of MW a feel for how we think multi-user systems should be built. However, the strengths of the MW proposal is that it balances simplicity against flexibility. As such, there are many interesting and important aspects of distributed systems that we make no attempt to address in the proposal. These areas are open, and the choice of how to solve them is left to the system builder. These areas include:

Key requirements

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; animations starting at the same time etc.
  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. In this appendix we discuss the specific case of shared avatars and then generalise the functionality to support any shared item.

For both these cases, the approach is the same. One or more Script nodes are put into the world, specifying a general purpose, or application specific applet which carries out the network functionality. For each piece of shared information, either Routes are added to and from the appropriate events to the ScriptNode, or the node itself is passed to the script which can then get and set fields. The former is used when information is needed every time it changes, the latter when it is only needed occasionally.

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

Example

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 "http://xyz.com/mynetworkprotocol.java"
}
ROUTE bar.position -> baz.position
ROUTE bar.orientation -> baz.orientation

This example will need rewriting to match the final version of the API, 
it should be close though

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.
    }
}