21.4 A Multiuser Domain

A multiuser domain, or MUD, is a program (a server) that allows multiple people (clients) to interact with each other and with a shared virtual environment. The environment is typically a series of rooms or places linked to each other by various exits. Each room or place has a textual description that serves as the backdrop and sets the tone for the interactions between users. Many early MUDs were set in dungeons, with place descriptions reflecting the dark, underground nature of that imaginary environment. In fact, the MUD acronym originally stood for "multiuser dungeon." Some MUDs serve primarily as chat rooms for their clients, while others have more of the flavor of old-style adventure games, where the focus is on exploring the environment and problem solving. Others are exercises in creativity and group dynamics, allowing users to add new places and items to the MUD.

Examples Example 21-4 through Example 21-8 show classes and interfaces that define a simple user-extensible MUD system. A program like this MUD example clearly demonstrates how the RMI programming paradigm transcends the client/server model. As we'll see, MudServer and MudPlace are server objects that create the MUD environment within which users interact. But at the same time, each user within the MUD is represented by a MudPerson remote object that acts as a server when interacting with other users. Rather than having a single server and a set of clients, then, this system is really a distributed network of remote objects, all communicating with each other. Which objects are servers and which are clients really depends on your point of view.

In order to understand the MUD system, an overview of its architecture is useful. The MudServer class is a simple remote object (and standalone server program) that defines the entrance to a MUD and keeps track of the names of all the places within a MUD. Despite its name, the MudServer object doesn't provide the services most users think of as "the MUD." That is the job of the MudPlace class.

Each MudPlace object represents a single place within the MUD. Each place has a name and a description, and lists the items in the place, the people (users) currently in the place, the exits from the place, and the other places to which those exits lead. An exit may lead to an adjoining MudPlace on the same server, or it may lead to a MudPlace object in a different MUD on a different server altogether. Thus, the MUD environment that a user interacts with is really a network of MudPlace objects. It is the descriptions of places and items, and the complexity of the linkages between places, that give the MUD the richness that makes it interesting to a user.

The users, or people, in a MUD are represented by MudPerson objects. MudPerson is a remote object that defines two methods. One method returns a description of the person (i.e., what other people see when they look at this person), and the other method delivers a message to the person (or to the user that the MudPerson represents). These methods allow users to look at each other and to talk to each other. When two users run into each other in a given MudPlace and begin to talk to each other, the MudPlace and the server on which the MUD is running are no longer relevant; the two MudPerson objects can communicate directly with each other through the power of RMI.

The examples that follow are long and somewhat complex, but are worth studying carefully. Given the complexity of the MUD system being developed, however, the classes and interfaces are actually surprisingly simple. As you'll see, remote method invocation techniques are very powerful in systems like this one.