The Making of a Pantheon
Letters to the editor
- Michael A. Hartman (Aristotle@Threshold)
Building the Land
- Jeffrey Laikam
Deciding on Mud Code Improvements
- John Patrick
The Power of the Written Word
Any Publicity is Good Publicity!
- Selina Kelley
Third Person Mudding?
- Ken McQueen
Enter your email to be informed when this site is updated.
Deciding on Mud Code Improvements
by John Patrick
So, you've bought a C book, written a variety of programs from easy to
hard, gotten the mud distribution source of your choice, and
you're ready to get started on your mud. Or perhaps you've been
running a mud for some time but it needs some changes, some updates to
make it what you want it to be, or what your players want it to be. Either
way, you need to prioritize what coding changes should happen
in what order. This is where mud administration separates the
men from the boys (or the women from the girls).
A mud is just a simple transformation from this multiplayer game.
First things first
Your first step should be to write down every single change you'd like,
your staff would like, and your players would like. These three sources
are where most of your changes will come from. Make sure to include "the little
things" because more often than not, failing to write down the little
things can mean that you'll forget, and it's often the little things that
can make a big difference. Also make sure to write down more than just a
fragment of a sentence. The difference between having "add dice" written
down and having "Write a command that will allow a character to play a game
of dice with other characters, perhaps allowing the number and size of dice
to be varied." will be quite evident when six months down the road you finally
get to that part of your "To Do" list.
After you've made the list (and changed, augmented, modified, added,
deleted, and scrambled it), divide the list up into the following groups:
These are your basic types of code changes that will take place on your mud.
Let's look at each one separately.
Code removal should be done before the mud opens for play. There's nothing
that will irk players worse than a skill, spell, ability, or talent that
their character possessed and suddenly lost. This should only be done during
mud play if there is an unbalancing or ill effect of some command that has
a large impact on other players and therefore may constitute a problem for
those players. For example, if after opening your mud and play testing, you find
that the new skill you gave thieves now makes them unstoppable in player
killing (if you
allow that sort of thing), then perhaps you might wish to remove it, or at least
tone it down.
A change in the level at which a character gains a skill, spell, ability, and talent
can be considered in this category as the change will have a great affect on
many players, even those who do not get that ability.
If you must change code that is in the category, it is best to do it before play
starts or at the least, as soon as possible.
The second priority of code changes should be bug fixes. There are various
flavors of bugs:
Crash bugs are self explanatory. These bugs have the largest impact on your
players, especially if some are using the presence of these bugs to cheat on your
mud. As such, crash bugs have a high priority to be fixed.
Play bugs are those bugs that affect game play; for example, if you added some
new code that had as an unintended side affect that some of your mobiles/NPCs get an
additional attack during combat, this is a play bug that should be fixed. (This actually
happened to me, and I made sure to fix it as soon as I knew about it.) Play bugs
have a lower priority than crash bugs, but a higher priority than annoyances.
Annoyances are those changes that have no real effect on game other than being slightly
bothersome. Examples of these are typos in messages sent to the players, incorrect
capitalization, ugly colors, and such things. Although these have a low priority compared
to other changes, I always make it a job to fix two or three of these per larger code change.
I've never failed to get a compliment from the players saying how they're glad I fixed
something that was annoying them. This is a great time to go through your "typo" file and
look at those typos that are code related, and not area/zone related.
Improvement code is when you take something that is already on your mud--be it "stock", "snippet",
or something that you've previously added--and enhance/update it.
A good example of a code improvement is adding a secondary effect to a spell that already exists.
Perhaps the spell isn't getting used to its full potential, or perhaps the normal effects that
it creates are not comparable to spells of the same difficulty. This would be a code improvement
that could help improve game play and the enjoyment of your players (at least those with
characters that have the spell!).
Be careful to realize that
by doing a complete "revamp" of code already existing, it may in fact be a condition of code
removal and new code insertion.
New code often takes the longest time and is the hardest to complete. As such, it often
has a lower priority. However, new code that would be a great addition to your mud, perhaps to
make it fit the genre better, is a fairly high priority. I make an effort to add new
code that will enhance my MUD and make it fit the genre better at least once a month. It is
this stage that you will have the hardest time prioritizing: which should you add first, the
riding mounts or the ranged weapons? I prioritize the new code changes as follows:
"Genre code" that will make my mud fit the genre better
"Fun code" that will let my players enjoy their time better
New skills, spells, abilities, or talents that will enhance play
"Reality code" that attempts to make the mud world make more sense
My "pet projects"
Players will be more interested in new code that fits the genre and role-playing atmosphere
of your mud more than little pet projects that you have been dreaming about at work. Genre
is very important. If you are a cyberpunk mud, adding code that will allow people to have
hard-wired cybernetic implants will be better than adding code that allows them to swim. While
swimming is a reality, even in the worlds of William Gibson, it doesn't play as big a part as
When it comes to reality code, you should be careful. Many (if not all) players play to escape
reality for a while. If you code in too much reality, it will remind players too much about
the reality that they are (were?) trying to escape, and it might make it not be all that fun anymore.
So, make sure you think about the possible side effects. I have placed new skills, spells, abilities,
and talents as third, as while they can enhance play, often older characters may complain about
new "stuff" becoming available that they may not be able to learn. Every time I've added
a new skill or spell, I constantly get the higher level characters complaining. As such, I try
to limit them to genre skills, spells, abilities, or talents.
"Mud code" vs. "Source code"
Some muds have what is called a mobile program, or "mobprog". This is interpreted code that is
stored in the zone/area file. For some large coding projects, such as skill additions, source
code change is required. But be careful not to create a large source code change if the code
is affecting only a single mobile or series of mobiles. It might be simpler (and shorter
time wise) to write it using a mobprog. As there are also "objprogs" and
"roomprogs" on some muds, this might be a viable alternative to a source code change. As these can
often be changed without restarting the mud, it might be considered a better alternative to a
source code change for those mud distributions that require restarting to update the mud code.
Too big of a change
You might find yourself making such a large change (or a large amount of changes) that the
current player characters might not be evenly matched, or even valid for that matter. In
this case, be prepared to perform a player character wipe (often referred to as a pwipe).
This will be needed if you change character classes, races, or available skills enough that
the older characters are no longer "legal" with the new code. Do remember, though, that
many players won't be too happy about having their long, hard hours working
on a character turned into nothingness. A pwipe is a serious event, and be sure to think
it out fully; the consequences are often greater than anticipated.
In conclusion, make sure to correctly prioritize your code upgrades. Spending an hour or so a month
prioritized your list using the steps above will be well worth it, saving you time and making your players
enjoy your game more, and that's what it's really about.
December 1999 Imaginary Realities, the magazine of your mind.
© Copyright Information