... world.¹

For large scale Role Playing Games, multiple servers are sometimes present; however, each handles a disjoint portion of the game world or simulates parallel, disjoint universes. Hence, the system is basically equivalent to multiple client-server systems.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...delta-encoding.²

A third mechanism sometimes used to limit bandwidth costs is prioritized rate-limiting by dropping ``less imporant'' object updates. Since this mechanism can be used to limit bandwidth arbitrarily (with a corresponding loss in fidelity), we do not discuss it further.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... bottleneck³

The bot AI code consumed significantly less cycles as compared to the filtering code, and is not a bottleneck in these experiments.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... manner.⁴

In our implementation we use a simple last-writer-wins protocol and have observed that this loose synchronization is sufficient for even a fast-pace game like Quake II.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... store.⁵

In practice, our implementation also provides adaptor interfaces to support existing object store implementations, such as that of Quake II. Indeed, we only really had to interact with the original Quake II code during object construction, deletion, and one spot in the original game loop, though we made optimizations to other parts of the code as well.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... tunable⁶

Mercury allows for faster routing if more long-links are maintained.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... replicated).⁷

Another option would be to fetch pointers lazily only when they are deferenced by the application. We may add this feature in the future.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... maintained, ⁸

We note that this goal may be in conflict with fault tolerance since we essentially eliminate backups, but the issues can be handled in an orthogonal manner (e.g., just ensure there is always at least one replica).

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... cases⁹

First, some visual and audio effects generated by think-code in Quake 2 such as explosions are unreliably multicast to all clients in a visible area; since these events do not actually modify object state, in our distributed implementation the events were only send to clients on the node that executed the think-code (i.e., the node that had the primary). To overcome this, we also broadcast such events to nodes maintaining replicas of the object which generated the event so that clients on those nodes will also ``see'' the effects as well. Second, to simply our serialization code, we disabled ``dead bodies'' and ``gibs'' (since they were were created by mutating existing objects rather than constructing new ones, it was difficult for our serialization code to determine when such an object was ``new''). We also note that we have only implemented functionality for all player, missile, and item objects and have not yet implemented functionality for some game objects like moving platforms, though we do not believe it would be a significant challenge to do so.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... bots¹⁰

We used the AceBot bot, written by a third party.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.