Toei Rei, a Mud Robot
Letters to the editor
- Paul McCarty
Rules of Immship
- Brant Harvey
- Jeremy Music
What is Remort?
How it Really Happened
- Richard Bartle
eBay Launches Virtual Property
- Jon Katz
Enter your email to be informed when this site is updated.
by Jeremy Music
Mob programs, and their close brethren object programs, room
programs, and exit programs, can make a mud take on a life of its
own. For the Implementor and builders of a mud, mob programs allow
an enhanced degree of freedom and functionality in the mud. For
the players of a mud with mob programs there is an increased
atmosphere and more things to do. Mob programs can be as simple as
purely a way to improve the role-playing aspect of a mud, by having
the mobs do and say things in response to actions by the players,
and as complex as an entire automatic questing system based in mob
Trying to kill a dragon, I hope the dragon's mob programs are not
The simplest way to increase the role-playing atmosphere on a mud
is to make the inhabitants of the realm interact with the players
rather than standing there meekly waiting to be slaughtered. This
was originally accomplished through special procedures that were
hard-coded in the source of the mud itself. Everyone who has
played on Diku-style muds for any length of time has seen examples
of these special procedures such as the Mayor of Midgaard who
wanders the city and locks the gates at night or the beastly fido
who eats corpses and gathers trash. These special procedures
breathed life into the denizens of the mud, but were very
restricted in their capabilities and extremely inflexible. Mob
programs grew from these hard-coded special procedures into an
easily modifiable scripting system. There are several variations
of mob programs out there, the most widely used being the mobprogs
common to ROM, Envy, Merc and Circle based muds, originally written
by N'Atas-Ha, and DG Scripts, a Circlemud specific scripting system
first found on Death's Gate that expands on mob program
functionality. There are other scripting implementations, such as
those found in Smaug and RoA, though most follow the same basic
Basically the way all mob program implementations work is that
there is a "trigger" that controls when the program will activate,
and then a command list which is performed by the mob when the
program is triggered. Most triggers have a percentage argument
that is the chance of the program being activated, such that a mob
program with an "all_greet_prog" and an argument of "100" will
always be triggered when someone enters the room. If the argument
was "50" then the program would only happen 50% of the time. There
are also triggers that enable a mob to respond to actions/speech of
players, enabling a mob to answer questions, follow instructions,
and in general "live."
All implementations of mob programs also have some form of
variables that are used within the programs to create personalized
responses and actions. In the basic mob program implementation
used by most muds, these variables take the form of a '$' followed
by a letter. These variables allow the mob to, for instance, say
something to a player, calling them by name, and even to refer to
a player as him/her/it or his/her/its. The variables used vary, as
those in DG scripts take the format of %actor.name, for example, to
hold the name of the person triggering the program.
In order to make a working mob program, one has to know what
commands are available to the mob. For the most part mobs can do
any command that players can do. In most implementations there are
some commands, such as Implementor commands, that mobs need to have
access to, but in a restricted way. This is accomplished by using
a subset of the "wiz" commands for mob programs. In most
implementations these commands are the same, just prefaced with
"mob" or "mp" such as "mpgoto" to enable a mob to go to a specific
room, and "mptransfer" to enable a mob to transfer something or
somebody to a specific place. Sometimes regular commands are
converted for use in mob programs and the messages taken out. This
allows a mob to load an object without it displaying any message so
that the author can use an echo to create the messages the player
The last piece of the mob program equation is getting the mob
to only respond when it is supposed to. This is accomplished by
"ifchecks." These check for certain conditions and direct the
program based on those conditions. This can be as simple as
checking to see if the person triggering is a male or female, or as
complex as checking to see what clan the player is in. The most
common use by far is to check and make sure that the mob is
reacting to a player rather than another mob (which can lead to
dangerous loops that crash a mud, something no Implementor ever
wants to happen).
Tying it all together
With knowledge of the variables, triggers, commands, and
ifchecks that mob programs use, a complex set of mob programs can
be created with comparative ease. For the player this means that
the Mayor of Midgaard now addresses each player by name if they ask
him a question, the beastly fido now growls at males and rubs
against the legs of females, and many other possibilities. For the
Implementor this offers an easier solution to such tasks as
creating clan guardians that attack non-clan members, creating mobs
that attack only evil characters, creating mobs that give a quest
tailored to the class/race/level of the player, etc. The uses for
mob programs are endless.
One of the most obvious uses is to allow mud Implementors to
create in-area quests that are completely handled by mob programs,
thus enhancing the role-playing atmosphere of the mud and engaging
the players in a stimulating and enjoyable mud experience. The
following example is specific to my mud (Wyld Knight) but its
purpose and implementation should be easy to understand.
>speech_prog hi hello hiya greetings~
say Why are you talking to me?
if isclass($n) == 1
say Welcome $n. I have been awaiting your arrival.
say I have a task that I cannot complete.
if islevel($n) > 15
say A mage of your talents should be able to help me.
say Please find my Mage's Robes of Power.
say I will reward you greatly for their return.
say Ahh. I see you are not yet ready for my task.
say Perhaps with more experience you may be able to help.
>give_prog robes mage power~
say Thank you my child, but I have nothing for you.
say Thank you $n. I had searched far and wide.
emote waves his hands wildly and mumbles some incantations.
give wand $n
The above program demonstrates the basics of mob programs and
gives a good example of how they can be used to increase the appeal
of a mud by creating impromptu quests for players to find and
complete on their own.
With the proper checks for clan-membership, level, class,
etc., mob programs can do many things to make an Implementor's job
easier such as clan guards, mobs that customize or enhance
equipment, mobs that are "enforcers" that jail/kill players with a
killer flag, etc. With modifications to the underlying code, mob
programs can be expanded to be usable with objects and
rooms as well (depending on the implementation, as DG scripts has
some of this additional functionality). These uses of mob programs
go a long way toward creating a "living, breathing" mud that is
more enjoyable to players and Implementors alike.
May 1999 Imaginary Realities, the magazine of your mind.
© Copyright Information