Java Reference
In-Depth Information
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 vari-
ous 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.
Example 16-3 through Example 16-7 show classes and interfaces that define a sim-
ple 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 com-
municating 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, a description, 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 link-
ages between places, that give the MUD the richness that make 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.
