Notable among the wonders of the Internet are the games--not the single-player computer games that you download to your PC, but the multiuser ones you play online with real, live people from all over the world. Some are highly competitive, some are more social in nature, and some are a little of both.
These games are commonly referred to as "MUDs," short for "Multiple User Dungeons" since many of the prototypical games were (and are) based on Dungeons and Dragons (D&D) type themes. Within the general category of MUDs there are a number of common and popular variants, many of which bear no relation whatsoever to their D&D precursors. Nevertheless, I'll continue to use the term "MUD" generically.
Although played on computers, with very few exceptions these games are not the flashy, graphics-oriented, animation-intensive games you might expect. Instead, they are ASCII-text-based games which don't even require any particular screen-formatting capabilities. The text simply just scrolls by.
At first you might wonder how these games could possibly be fun. What is a computer game without bitmapped graphics? Without explosions and custom controllers? Surprisingly, these games can be extremely engaging, with the entertainment value derived more from multiple-player interaction than from what the computer itself is doing. In these cases, the computer merely serves as the vehicle, or medium.
In this article, I'll survey some popular types of MUDs and provide background history on their development. I'll tell you how to connect to MUDs and how to get started. Finally, I'll discuss how MUDs work and give you a few pointers to MUD code bases and online resources should you decide to run or write your own MUD.
A MUD is a multiplayer game program that usually runs on a UNIX-based computer and talks directly to the Internet. Since it is connected directly to the Internet, anyone from anywhere in the world with Internet access can connect to this game and spend as long as they want playing for free. This immediately distinguishes MUDs from BBS-based games, where users must play within their local area or else be prepared to fork over the big bucks to the phone-line providers.
Traditionally, these games are also completely noncommercial and are run and administrated entirely by volunteers. They may be running on hardware and Internet accounts belonging to commercial concerns or educational institutions, but no fee is extracted, and no service guarantees are provided. They are generally provided strictly as a labor of love by your fellow "netizens."
Interaction. As a user on a MUD, you may play individually, partner up, or even join groups. By cooperating with one or more other players, you may be able to accomplish more within the construct of the game than you could operating on your own.
While playing, you can "talk" with other users (via typing, of course). People who are continents apart can gather in the same virtual MUD room and chat away. Particularly on MUDs based overseas, users from half a dozen or more countries may be on at the same time!
Ranking Systems. MUDs often rank players according to experience level. The names of the ranks are often indicative of that MUD's culture. When you first start playing a MUD, expect to be assigned an initial rank like "Apprentice," "Novice," or even "Clueless Newbie." As you progress, you'll achieve more-impressive (or at least less-demeaning) titles.
The highest-ranking characters are, of course, those who run or administer the MUD. Often called "Gods," they can modify game code, change the database, and otherwise shape the reality of the MUD. Below them there's usually a "Wizard" or "ArchWizard." To earn this rank, you must have effectively "won" the game and possibly received a special promotion from the Gods. At this level, your character is considered "immortal" and is allowed nearly god-like powers on the MUD. Gods are often happy to unload some of the busy work of running the MUDs onto these highly experienced regular players.
Playing a MUD. Actual game play on a combat MUD usually involves killing monsters called "mobiles" (or "mobs" for short), exploring, collecting valuable or useful items, and solving quests or puzzles. Killing other players is usually strictly forbidden, and is dealt with very harshly. But some MUDs do permit player killing (PK) with certain restrictions, or during certain free-for-all time periods. Definitely check the rules of the MUD you're on before you decide to whack some other player up the side of the head with the ElvenSword (or even the king of all swords, the ElvisSword).
A more socially oriented MUD might involve nothing more than just hanging out, talking, and occasionally playing funny tricks on each other. Or you might be able to build your own rooms or regions, and furnish these areas with gadgets or little puzzles of your own.
While the specifics of play vary from MUD to MUD, they all encourage user interaction and communication. It is this that makes them so much more compelling than their older, single-user UNIX relatives. Let's take a quick look at the foundations of the multiuser-game experience and at where it's going.
Computer games have supported multiple players interacting in various fashions since at least the mid-1970s (see Figure 1 for details of the MUD family tree). A multiplayer game called "Oubliette" featuring dungeons, levels, and a chat area was in heavy use on the Plato system at the University of Illinois in 1978. This was quickly followed by an improved version called "Avatar" that enjoyed enormous popularity during the early '80s and is still going on today.
Around 1979, a game called simply "MUD" appeared in the UK. It, too, was based on a D&D theme. It is probably this game that spawned the most direct and indirect MUD progeny in the form of the "AberMUDs" and their descendants.
AberMUDs--named for the University of Aberystwyth, where they were written--were the first MUDs to become popular on a grand scale. They were highly portable to different platforms, hence their rapid spread throughout Europe. Trans-Atlantic links weren't as reliable and fast back then as they are now, so these didn't catch on right away in the US. Around 1988, AberMUDs started appearing at American universities. Shortly thereafter the first TinyMUDs appeared. These MUDs are more socially oriented and noncombative; the "Tiny" part of the name reflects the fact that the base code is much smaller than that of the AberMUDs.
At this point, MUDs came to be divided into two broad categories: the so-called "Hack'n'Slash" combat MUDs, and the less competitive social flavors. And things began to happen fast. MUD variants began sprouting up all over.
Today, on the combat side, the LPMUDs are currently the most numerous, but the DikuMUDs, an LP-variant, are coming on strong. Both of these types draw from AberMUDs but add multiple classes (or "races") of players and typically feature more sophisticated combat systems. On the social side, there is probably more variety of both games and themes, and it's less clear which form is the most popular. Probably, it would be the MUSHes--"Multi-User Shared Hallucinations."
Much MUD development has been evolutionary rather than revolutionary, simply because it takes so long to write a full-featured MUD. Most people wanting to open a new MUD prefer to start with an existing source base and modify it to suit their tastes.
It also takes a while for a major new variant to catch on. Becoming proficient at a particular type of MUD often requires many hours of practice and exploration. Players then tend to continue to play games of the same family to leverage some of their hard-earned experience.
To connect to a MUD, you must have Internet access. Then you need to know the MUD's Internet address and its port number. The Internet address may either be in symbolic or raw numeric form; the port number is usually a four-digit number such as "2222" or "4000." Then you simply invoke telnet, specifying the address and port number. For example, to access PrairieMUD, a traditional AberMUD, you type telnet 220.127.116.11 6715 or telnet firefly.prairienet.org 6715.
Most MUDs then give you a sign-on screen where you select a character name and choose a password. The name you choose will, of course, affect everyone else's perception of you on the MUD, so choose carefully. Many MUDs have a rather pronounced culture. Selecting a name like "Neutron," while acceptable on a space-theme MUD, might not look so good on a medieval D&D MUD.
Most MUDs allow you to just sign right on and play, but some enforce a registration process. This enables their administrators to restrict access to certain folks who have demonstrated a tendency towards bad manners or antisocial behavior. To join in these MUDs, you will need to first send e-mail requesting a particular character name and arranging for a password.
When you initially connect to a MUD, you will be a "newbie." Most MUDs provide learning areas or online information to help you learn something about the game. You will want to spend some time reading and learning before you start to pester the more-experienced players. While many are willing to help beginners get started, they are much happier to provide aid if you've done your basic homework and familiarized yourself with the rudiments of their game. One way to make the learning phase more fun and interesting is to connect with a friend. You can learn together, and share tips and tricks as you become more familiar with the game.
Table 1 provides a sampler of MUDs you can try connecting to. There are hundreds more. You can get their addresses in the rec.games.mud.announce newsgroup and by watching for the MUD lists occasionally posted there.
As you begin to learn the MUD etiquette appropriate to the particular style of MUD you are playing, you will definitely want to communicate with the other players on the MUD. Other players can provide advice, give you equipment, even help rescue you from sticky situations. And the good-natured joking around that goes on adds to the fun.
As you interact with people, remember that they are, in fact, people. Don't be pushy or rude. If someone seems less receptive to your questions, maybe they are in the middle of doing something themselves and don't want to be bothered. And while the Wizards and other players on a game may sometimes perform spontaneous acts of generosity towards you, don't depend on it, and don't go whining every time you're in a little bit of a sticky situation. Those with more experience arrived at it the hard way, and they'll expect you to make your bones the same way. In other words, be patient.
It has been demonstrated that these MUD games can lead to near-addictive behavior in some personality types. People have lost their jobs or flunked out of school because they didn't know when to quit out of a MUD. I doubt that MUDs deserve to be blamed directly for someone's failure to deal with non-computer-generated reality, but if a person is a little lacking in self discipline or direction, they can be an easy distraction.
So just a quick admonition: Keep an eye on how much time you spend online playing these games. That quest will always be there tomorrow. That next level will still be around. Most importantly, if you find you're walking up to real doors and saying "open" out loud, it's time to ease up!
The program that delivers MUD reality to all who connect is called the "server." At the heart of a MUD server is the machinery that supports the connections and communications. This part of a MUD is surprisingly straightforward, with most MUDs using the same basic approach. It is possible to have a simple multiuser chat program up and running on the Internet with less than 100 lines of code--elegantly simple!
The quick tour looks like this. First, establish a socket with the socket(2) system call. Then associate a port number with the socket using the bind(2) system call. This is where the MUD gets the last four-digit portion of its address. Then use the listen(2) system call to listen for connection attempts to the socket.
Now you are ready to enter a loop, using the select(2) system call to monitor activity at the socket. When you detect a new connection, you use the accept(2) system call to establish a new file descriptor and add it to the list you are monitoring for activity with the select(2) call. That's all there is to it. Now you can use read(2) and write(2) on the file descriptors returned by accept(2), and away you go. For more details and example code you might want to refer to the text, UNIX Network Programming, by W. Richard Stevens (Prentice-Hall, 1990). And of course, you could study some of the existing MUD code to see how other subtleties of communication are handled.
The limitation of the above approach is that eventually you will run into the system limit on open file descriptors as more users come online. To get around this, write a front-end multiplexor program that listens for connects and then funnels traffic for multiple sessions through a single channel to the main MUD program. MUD servers have handled loads of well over 200 players this way, although response times get a bit sluggish.
MUD server implementations diverge rapidly from this point. Some MUDs have very simple string matching and lookup-table-driven command processors; others use a more grammar-driven parser. Some MUDs load the database into memory for play, others keep it on disk. A disk-based approach has the disadvantage that a server crash can leave the main database scrambled, whereas when a memory-based server goes awry, at least the starting database is left intact.
You can attach to most MUDs and have plenty of fun using just the standard telnet program. However, special programs called "clients" exist to make your stay on a MUD more enjoyable and entertaining. They provide features to help make better sense of the quickly scrolling screens on a busy MUD. They prevent a line of input you are typing from being mangled on the screen by output from other players. They can even completely screen out certain types of unwanted noise from other players. They may provide quick, little, cute actions and personalized phrases, and even help you navigate.
Some MUDs are beginning to incorporate simple polygon graphics using a system called "BSX graphics." A dedicated BSX client is required to take advantage of the added graphics effects provided by these MUDs.
If you are going to spend much time on a MUD, you might ask around and see what clients other folks on the MUD are using. TinyFugue and LPmudr are a couple of examples--the MUD ftp sites have many more.
As you play MUDs, you almost inevitably begin to have your own ideas about how you think things should be run. This is particularly true in the competitive games; after you've achieved the highest mortal ranking, you still want more. To enter the ranks of the Gods and run your own game, you need at least basic knowledge of the C language. To make major changes to an existing MUD's functionality or write your own MUD from scratch, you need significant coding experience.
First, you locate a source base for the type of MUD you are interested in. Even if you plan to write your own, it's advisable to study some existing code so you'll know more in advance about what types of problems you might encounter. Table 2 provides a list of online sources for MUD code and other resources.
To compile the MUD code, you may need to do a little tool gathering. Many MUD code bases expect and/or support the GNU C compiler.
I brought down several varied types of MUDs and tried building them on a SPARCstation running SunOS. All were fairly easy to build, but most required at least some tweaking. In some cases, more-significant code changes were necessary to convince the compiler that things were okay. Some MUD code bases contain several hundred Kbytes of source, which the C neophyte might find a bit daunting.
Once I got the various MUDs to compile and sorted through setting up directories, all of them came up and ran just fine (as evidenced by the fact that productivity on our office network dropped to nil). All in all, it was pretty easy to set up a MUD from an existing code base. This brings us to the next problem. The most frequent cry in the MUD newsgroups seems to be "site needed." Would-be Gods have MUD code running but don't have a direct Internet connection.
Many are students who have accounts on an Internet machine but are restricted to rather small disk quotas or explicitly forbidden to run MUDs on the school's machines. MUDs tend to be big, fairly hefty processes, requiring large amounts of memory and/or disk space. Some sidestep the limited-disk-space issue by establishing a CSLIP or PPP link to a home machine running Linux. A 14.4-Kbaud link and a reasonably equipped PC will support at least a handful of users.
A better solution, of course, is to find a sympathetic site with a direct Internet link and offer to provide the hardware and administration. MUDs tend to become more fun as more users participate; you don't want to have your response times degrading just when more people start to get interested.
But whatever you do, don't put up a MUD without consulting your system administrator. You get annoyed when some clueless newbie does something stupid on a MUD you're playing; don't you go and act like a "clueless newbie" on somebody else's UNIX system!
MUDs are beautiful in their simplicity of format and universality. They epitomize the concept of entertainment by the people and for the people. Since they are not run by big business and no money changes hands, they are free to be whatever they want to be. There are no commercials.
From these simple, text-based MUDs which currently predominate, we will certainly see the emergence of games featuring more graphics and live speech capabilities. But don't wait for the future--get online now. You'll have some fun, and if nothing else, you'll be amazed at how quickly your typing speed increases!
Many thanks to Jennifer "Moira" Smith for putting together the great MUD FAQ (Frequently Asked Questions) for Usenet (required reading for all MUDders). Also, thanks to all of you who've talked to me on the various MUDs.
Figure 1 MUD family tree.
Name Symbolic address Numeric address Port PrairieMUD firefly.prairienet.org 18.104.22.168 6715 Basic traditional AberMUD based on Dirt 3. 3-Kingdoms marble.bu.edu 22.214.171.124 5000 Very active LPMUD. Nuclearwar NuclearWar.Astrakan.HGS.SE 126.96.36.199 23 (opt) Cyberpunk LPMUD. FurryMUCK sncils.snc.edu 188.8.131.52 8888 Anthropomorphic theme--everyone is a furry critter; registration required. PernMUSH cesium.clock.org 184.108.40.206 4201 Themed role-playing MUSH based on the Anne McCaffrey book, Dragonriders of Pern. Foothills marble.bu.edu 220.127.116.11 2010 Very busy talker. DeepSeas a.cs.okstate.edu 18.104.22.168 6250 Underwater theme; registration required; be prepared for a playful and feisty bunch. Carrion Fields neoteny.eccosys.com 22.214.171.124 9999 Blood and guts LP; player kill; player steal; cabals you can join for power and protection.
tmi.ccs.neu.edu (126.96.36.199) 5555 LP-building support available through an LPMUD called "TMI-2." ftp.luth.se (188.8.131.52) in /pub/misc/aber/code Aber Dirt 3.1 server source, the most popular Aber flavor. ftp.lysator.liu.se (184.108.40.206) in /pub/lpmud LPMUD server and client source. ftp.math.okstate.edu (220.127.116.11) in /pub/muds MUD FAQ in /pub/muds/misc/mud-faq, also Diku FAQ, clients, servers for Merc, MacMerc, TinyMUD, TeenyMud, CircleMUD, TinyMUCK, TinyMUSH, UberMUD, and more. ftp.tcp.com (18.104.22.168) in /pub/mud Clients, servers for CoolMUD, Diku, TinyMAGE, UnterMUD, and more. <B>Newsgroups:</B> alt.mud Redundant MUD newsgroup, superceded by groups below; still has some activity, however. rec.games.mud.admin Ideas and information forum for those who run MUDs. rec.games.mud.announce Announcements for new MUDs, changes of address, source-code releases, and so on. rec.games.mud.diku Discussion related to the Diku family of MUDs. rec.games.mud.lp Discussion related to the LP family of MUDs. rec.games.mud.misc MUD topics not covered in more-specific groups. rec.games.mud.tiny Forum for discussing MUSH, MUSE, MOO, and so on.
Copyright © 1994, Dr. Dobb's Journal