[ First Topic | Previous Topic | Next Topic | Last Topic | Index | Library ]


The Dream of Adventure
A MUD, which stands for multi-user dialog (or dimension, or dungeon), is a multi-user environment used to simulate artificial realities within the context of computer data networks. With few exceptions, most MUDs are gaming environments, containing elements of role-play, combat, and socializing. Most MUDs provide access to participants using the TELNET protocol and a command-line interface. The result is a text-based simulation system that relies primarily on the imaginations and dreams of the participants to achieve a living simulation environment. Most MUDs allow extensions to the simulated universe using some derivative of the C programming language, and operate primarily in UNIX operating system environments. Often called wizards, MUD designers must understand the science of computer programming to generate the complex code needed to create interesting effects. MUDs represent an ingenious approach to simulation software, combining object-oriented extensions to the C language with the hierarchical file system of UNIX to form living, evolving simulations.

The following chart lists the various kinds of MUDs available today:

LPMUD Lars Pensj | Multi-User Dungeon. Without doubt, the most popular MUD software is the LPMUD, named after its creator, Lars Pensj, who created LPC, an object-oriented extension to the C programming language. LPMUDs are known for their built-in gaming systems, including a robust combat environment.

It should be noted that the authors of MUDzilla have spent a fair number of hours adventuring in the oldest LPMUD, Genesis, which, among other things, contains a detailed simulation of J.R.R. Tolkein's Lord of the Rings universe.

DikuMUD Datalogisk Institut Koebenhavns Universitet (Department of Computer Science, University of Copenhagen) Multi-User Dungeon. DikuMUD was developed as sort of a compromise to the social vs. combat MUD question. Adventuring and combat are the mainstays of DikuMUDs, and players are usually encouraged to collaborate to solve problems. A "clan" system adds a certain political aspect to DikuMUDs. They tend to be CPU-efficient, and user-friendly.

A popular DikuMUD can be found at the Realm of Magic.

MOO MUD Object Oriented. A MOO is largely a social simulation environment where participants gather to chat. Almost all MOOs allow players to create simulation objects using the command system of the MOO itself. This is different from LPMUDs and DikuMUDs, which restrict the creation process to so-called "wizards." Certain commands, such as "shout," send information to all players in all rooms, making MOOs ideal places to meet other INTERNET users, and just "hang out." In this sense, a MOO is a cross between a MUD and a chat room.

By far, the largest and most popular MOO is LambdaMOO, which supports over 200 simultaneous users.

MUCK From the verb, to muck. MUCK programmers "muck around with the system." MUCKs are derived from the TinyMUD software written by Stephen White. MUCKs tend to stress social interaction and world-building over combat. MUCKs have their own programming language called Multi-User FORTH (MUF). It is not surprising that MUCK programmers are often called "MUF-divers."

A large, sexually-charged MUCK can be found at FurryMUCK, where players take on the roles of anthropomorphic animals.

MUSH Multi-User Shared Hallucination. Originally written by Lawrence Foard, a MUSH allows triggered events, and an object type known as a puppet, a remote-controlled automaton. Like MUCKs, they support object creation for most players, and are social in nature.

A popular MUSH system is TinyMUSH

MUDzilla While MUDzilla represents a departure from traditional MUDs, it resembles all of the types of MUDs listed above. Instead of the nature of the simulation environment being a factor of the MUD software, a MUDzilla simulation will derive its behavior completely from the objects stored in a MUDzilla database. And unlike most MUDs, no programming experience is required to create objects within a MUDzilla simulation.

The flagship MUDzilla can be found at The Monastery of Ages.

By the late 1990s, MUD software had grown to include countless derivatives of the MUD types listed above. All have been crucial in developing the skills needed to create and maintain large simulations. Many large MUDs founded in the 1990s tended to be run by students using university-owned computing resources, making the transition from a text-only environment to the text and graphics of the web difficult. MUDzilla was designed evolve MUDs to their next logical incarnation, which consists of tight integration with the world wide web, and requiring no progamming in the traditional sense of software development to effectively operate a simulation. MUDzilla strays from traditional MUDs in terms of its design, as the following demonstrates:

Element Traditional MUD MUDzilla
Object Model The key strength of traditional, UNIX-based MUDs is their use of an object-oriented paradigm. In this model, an object is a single text file, and the lines of code within the file represent the properties and methods associated with the object. By using a programmig technique called including, an object can be inherited from an ancestor object by including the ancestor file when the object is compiled. A class in this model would be represented by all lines of code in all object files in a direct line to the most abstarct object in the model, called the root object.

The strength of an object model is the key to the success traditional MUDs have enjoyed for literally decades, a tribute to MUD programmers everywhere!

The object model upon which MUDzilla is based comes from Inprise Delphi, a rapid application development environment for Windows NT/2000. The objects are stored in database tables, one table per class. Classes can be extended by the addition of properties at any point in the model at any time. Line-by-line coding is replaced by robust Windows forms-based applications, where data integrity can be assured at design-time.
Database UNIX file system. Each object is a text file that lists the code, line by line, that makes up the contents of the object. These files must be compiled (translated from source code to machine code) individually and repeatedly when the object is loaded into memory. Access to files requires knowledge of the directory structure under which the files are maintained, along with knowledge of UNIX file system security. SQL relational database. Each object is stored in a row of a database table. When an object is loaded into memory, any read operations are performed on the memory version of the object, whereas all write operations are made directly to the underlying database table. Since the code associated with objects is maintained within an application's executable (*.exe), the objects themselves contain no code, and thus, no repeated compilation is necessary. Access to objects is through the Structured Query Langiage (SQL) specification, which allows complex relations between tables based on well-formed rules.
Language Most MUDs are written in the C programming language, or some derivative. MUCKs use a extended version of FORTH called Multi-User FORTH (MUF). Though highly flexible, these languages are restricted to the elite few who have actually mastered their arcane intricacies. In MUDs, the objects, and the code that manipulates them, are indistinguishable. MUDzilla separates objects and code from one another. Objects are stored in database tables, and the code that manipulates them is packaged into a single executable. A special object, called an event, replaces the complex coding of traditional MUDs. If a simulation designers can fill out a few forms within a windows-based MUDzilla application, they can create complex simulation elements.
Management As a MUD simulation grows, the number of object files increases. The nature of a file directory system inhibits complex data manipulation operations, restricting the ability to apply simulation-wide policies. Security must also follow the file and directory rights within the UNIX file system. What must result is an increasingly inconsistent collection of objects, any one of which can fail the load process due to a "bug" in the code that represents the object. Management of the simulation requires knowledge of complex UNIX commands. MUDzilla centralizes management of the simulation through the use of relational database technology. Security follows a system specific to the needs of the simulation, and is based on the user-defined type of an object. Management of the simulation is accomplished through a number of easy-to-use applications written for Microsoft Windows NT/2000.
Interface Access to MUDs almost invariably requires a TELNET client. TELNET is a simple, text-based INTERNET protocol with simple, well-understood rules. Players enter commands such as LOOK and TAKE to access objects within the simulation. The rest is up to the imagination of both the player and the simulation designer. MUDzilla, too, offers a text-based interface, as it requires the least amount of computing resources to use, important in this age of widely-variable hardware and software. However, it should be noted that there is no difference between sending a user text and sending a user full-motion video and sound in the MUDzilla model: both forms of output must come from a field within a database. Using the world wide web, MUDzilla builds on the foundation of text, and adds images, sound, animations, and virtual reality features, all selectable by the simulation participant based on available computing resources.

See Also See Also:

[ First Topic | Previous Topic | Next Topic | Last Topic | Index | Library ]

The MUDzilla Simulation System
Please e-mail us your comments and inquiries.
© 1994-2002 Myne Corporation

Myne Corporation