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 (ftp.circlemud.org). 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 jedi.america.net 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
http://www.america.net/~jedi/, 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.