A mud is just a simple transformation from this multiplayer game.
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!
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. |
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:
Code removal
Bug fixes
Improvements
New additions
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
Play bugs
Annoyances
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 wetware does.
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.
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.
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