XMUD Architecture

Overview

XMUD is an eXtensible MUD. At its core it is a distributed system composed of a group of object managers that control the state of the system, a security manager that verifies client identities, a series of clients that execute xmud objects, and a mechanism for verifying that requests are generated by valid objects.

Components

Server Side

Object Manager

Objects have a state that is composed of state elements. The object manager stores state elements into permanent media and allows clients to read, modify and lock any element. There are two versions of the object manager, the client and the server. The client is just a proxy that receives requests from local objects and forwards them to the appropriate object manager running on a server.

Method Verification

Given the distributed nature of the system it is necessary to verify that a request to change the state is generated by a valid method of a valid object. Lets say that we have a player object that has a move method. The move method based on the current position, direction of movement and speed determines the new position. The code for the move method will be executed at the client and and a request for a state change will be generated. It is possible that a player modified the code for move so that his character could move much faster that originally designed for. In order to prevent this situation the object manager may choose to re-execute the method with the orignal parameters and state in a trusted computer and compare the results with the ones provided by the original client.

Security Manager

Authenticates clients. Methods that modify the state of the system should present credentials. These credentials are verified by the security manager. The security manager also keeps track of the list of active clients, and serves as the initial point of contact between clients and servers.

Object Finder

Keeps track of the objects held by each server.

Object Loader

Keeps a list of objects that should be made persistent and loads them from the database using PSS.

Client Side Objects

Although this objects are executed mainly in the client a copy of them should reside in the server in case that method verification is required.

Object Manager

Holds the client side of the object manager. It acts as a proxy that talks to remote object managers and presents game objects with a local view of the world.

Client

Program that receives user gestures and presents a view of the virtual universe to the user.

Game Objects

The objects that actually make up the virtual universe reside on the client. These objects represent the entities that make up the game. A few client objects common to almost any XMUD world are: players, monsters, buildings, spells and items.

Objects have a state and methods. The state is a collection of state elements. A state element is just a group of serializable java data types. Methods that modify the state should a) lock the objects it intends to modify b) read the latest state of the objects it intends to modify c) generate a state change request d) send the request to the server. If the server determines that it is valid it would execute the changes and all other objects would see the new state.

This release provides a library that includes player and monster objects.

Player

Represents a living entity in the sytem. Keeps track of vital statistics, movement and behavior. Used as avatars for players.

Monster

A subclass of a player. It has an ai component that determines how the monster behaves (moves/talks/attacks).

Graphics Engine

Presents a 3D view of the world. Renders the terrain and objects in the virtual universe and checks the validity of movement with respect to collisions and terrain following. The world models are defined using VRML and loaded into the system using xj3d loader library. The engine has been writen using Java3D.

Networking

Communications are handled by using custom object serialization through a plain sockets protocol. This mechanism has been chosen in favor of CORBA for performance reasons.

State Storage

State is stored in a SQL conformant (MySQL) dat

Extending the system

Game Objects can be added to XMUD at run time. When first created an XMUD object will be placed in the server in a special sandbox that restricts input/output, a new object can not modify the state of the system. Once an object becomes trusted, through a voting mechanism, it may change the state. This restriction prevents situations like the creation of a thermo-nuclear bomb object that could destroy the entire universe.

The capability of run time extension makes xmud quite powerful. The world becomes dynamic and better reflects our reality. Nothing would prevent a person from "inventing" a television subsystem composed of tv sets, repeaters, antennas, and shows; adding them to the XMUD universe and allowing players to use it.