The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!

Mob Programs

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

Trying to kill a dragon, I hope the dragon's mob programs are not too advanced.

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

The Triggers

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

The Variables

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.

The Commands

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 will see.

The Ifchecks

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~ if isnpc($n) say Why are you talking to me? endif 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. else say Ahh. I see you are not yet ready for my task. say Perhaps with more experience you may be able to help. endif endif

>give_prog robes mage power~ if isnpc($n) say Thank you my child, but I have nothing for you. else say Thank you $n. I had searched far and wide. mpjunk power mpoload 38432 emote waves his hands wildly and mumbles some incantations. give wand $n endif

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.

Jeremy Music <Sterling> runs Wyld Knight: The Land of Erehwon, an Envy-derived mud with mob, object, room, and exit programs, operating at wyld.qx.net port 3333.