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 (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. 

Chapter 5	What Else is Possible
	Page 5-4
