Chapter 5

What Else is Possible

What we have done here is just the tip of the iceberg. While making changes to the engine of a Multi-User Dungeon is not always straightforward, the fact that you can modify the source code as well as the world files opens the door to limitless possibilities.

The basic CircleMUD release does not have a "race" system, just a class system. By contrast, many MUDs, particularly a number of LP-MUDs, do include a race system, with the race chosen having as little an effect as a slight influence in player statistics, and as major an effect as how NPC's react to a character. The instructions for adding a very basic race system can be found on the CircleMUD ftp site ( These modification from these instructions lays a partial foundation, but it is up to the person who implements them to flesh out the various benefits and consequences of each race.

Another possibility is that special procedures could be written to allow NPC's to react directly to the actions of a character in the room. At present, the special procedures that exist only take into account status factors, such as whether or not characters are fighting, whether a character is good or evil, whether a player is the last character the NPC was fighting, etc. Support could be added so that an NPC could react directly to, say, being kissed, being given a certain item, or to other actions in the room, such as a player taking an item or opening a door. This would most likely require queuing the action messages that occur in the room for all NPC's present, or at least for those with these special procedures, and writing a special procedure to read and interpret the queued messages until it either reaches the end of the list or finds one that the character is supposed to respond to.

There is also partial support built in for multiple home cities, but the procedures to take advantage of this are not present. For an example of this, take a look at JediMUD, a Diku-class MUD running on at port 4000. (Just as an aside, the computer running the MUD is named after the game, which originated in the psychology department of Johns Hopkins University, and not the other way around. Also, according to JediMUD's home page at, CircleMUD engineer Jeremy Elson was an administrator on JediMUD for a time.)

With some creative coding in C++ and, for example, Visual Basic, a picture- based version of the game could be created, in which the MUD server sends image files in addition to or instead of text descriptions, and a VB-based displays them, in a manner similar to Bard's Tale. The standard source code for the ZModem file transfer protocol for terminals could be used, sending the images as part of the same data stream as everything else, or the client could establish a separate connection to, for example, an FTP server or similar engine, and be told which files to download either by the MUD or a parallel process controlled by the MUD.

There is a semi-popular activity called MUD Sex, in which players use either special commands or an "emote" command to send the descriptions and messages appropriate to intimate physical interaction. The CircleMUD code base does not include any special commands for this, so generally players who want to do this will either use the emote command, which simulates a social, or find another MUD. However, a MUD coder who wants to support this activity can add the appropriate commands, and even restrict them to use in certain rooms. Special characters and procedures could be added to manage a kind of "motel zone", where one player can "check into" a room and can invite a partner to join him or her, away from the prying eyes of others, either through some kind of "invite" command or by giving the other character a key.

On-line creation utilities are also possible, to allow God-level characters to build additional areas, objects and characters while the game is running. There is currently one under development as part of CircleMUD 3, which is expected to be ready in version 3.10, whenever that is available. If you do not wish to wait, you can create your own, or download one of those available now, and figure out how to patch it into the source code.

You can be very creative with your classes. Some MUDs have as many as seven or eight classes, and some of these classes are restricted to characters who have reached the God levels and then "re-morted", opting to exchange the administrative powers for the right to be a regular player character again. You can even create a class of character which is only capable of magic under certain conditions, such as the presence of sunlight (outdoors in the daytime), or whose alignment must remain good or else lose the use of magic, such as the Paladin or Jedi as they exist in JediMUD.

The game also supports special procedures for objects and rooms, as well as for NPC's. Buttons which can be pushed to open and close doors, rather than using keys, can be made and placed, as well as creating doors which open and close on timers. Vehicle rooms, such as the subway cars in JediMUD or the Mirror Rooms in the Infocom text adventure Zork, can be added to connect areas so that players can travel quickly, rather than having to wade through the countryside to pick up a quest where they left off in a previous session. Daggers which do more than just stab a target, but also poison their victim, or periodically heal their owners, may be worthwhile. Also, a door could be created that looks like a mouth, and which can stick out its tongue every so often, or when someone tries to open or unlock it improperly.

In addition, there are a number of gameplay settings which are configurable by modifying the file "config.c". For example, the game, as distributed, has the "rent" feature turned off, allowing players to keep their equipment from session to session without charge. However, changing the free_rent setting around line 91 from YES to NO will change this, so that characters lose their equipment if they quit without going to a rental area such as the Grunting Boar Inn in Midgaard, and having enough coins to pay the storage fees. The game's opening greeting is also stored in this file as the string array constant GREETINGS at around line 203. Other options, such as the port the game runs on, whether or not player killing is allowed outside of special areas, and so on, are all configurable from this file.

You can even adjust the way the game handles the terminal. By modifying the strings throughout the game that contain the messages sent to players, you can add color to these messages. See "color.doc", which is included with the game, for more details on this. Also, by making changes in "comm.c", you can adjust or rewrite the handling of the backspace, delete and arrow keys characters, or make any number of fine tuning adjustments to the way the game is experienced by the players.

While most modifications are in the form of game enhancements, this is not the only way in which the game can be modified. A good C programmer with a lot of time available could in fact take advantage of the core engine to serve a seemingly unrelated purpose. The suggestion has been made that a MUD engine could be used as the front end to a corporate information system, a kind of text-based Virtual Central Office, if you will, for a company with a distributed employee base such as a national sales force. Support could even be added for conferences and meetings, and the game's mail system could be used for inter- office memos. If the users have enough Internet bandwidth, support could even be added for voice communication using customized client software. To take this idea a step to the side, the engine could also be used for an on-line teaching system, a Virtual Campus, complete with a library, department offices, a campus mail system, and a chess team. An on-line shopping center is also a candidate for this type of adapted MUD engine.

In a way, many of the issues surrounding how MUDs operate are similar to a number of issues involved in higher-end Operating Systems. Among these are such things as parallel tasking of multiple users, interaction between users and system elements, protocols for communications between the server and the user interface system (monitor, keyboard, mouse, etc.) and a number of other factors. While many server types can simply defer much of this to the parent operating system, users in MUDs must interact not only with the system and with each other, but also with the same set of system characters, and the effects of one user's actions can influence the game variables in a way that affect other players. As a result, the MUD engine is designed to handle many of the tasks, such as parallel tasking of multiple users and system activities, which are required of an operating system. In a way, a MUD actually serves an operating system for the players who use it. Understanding how the MUD accomplishes this can provide an insight into understanding the workings of multi-user operating environments. To take this to an extreme, a MUD engine could even be adapted to serve as an operating system or apparent operating system, such as a Bulletin Board System or the virtual office or campus mentioned before.

As I stated before, the possibilities really are endless. With a handful of ideas and some decent C coding skills, it is within your power to bring these possibilities to life.