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 Want to Start a mud

by Robert M. Zigweid

In today's world of various online environment, there seem to be more and more upstart muds. This trend is aided by the fact that muds have become easier to set up. Many older mudders view this as a bad thing to the community as a whole, citing that there is a limited player base. Others think that it shows progress within the community. The development of new muds, whether it means progress or regress, continues without any restraint other than individual dedication and the availability of host sites from which to operate mud environments.

Many players and developers in the mud community think that they will be able to create a successful gaming environment. Their reasoning may be that they don't like how the game that they play or write for is run. In instances like this, the fledgling administrator usually uses the same theme as the game that they came from, and often the same code base. Others, like myself, haven't seen a game do what they envision that one can do, or they want to accomplish something that hasn't been done before.

250cc Yamaha

Stylish type of driver, no library needed with this one.

For whatever the reason, there is a series of steps which invariably need to be followed. To an extent, the order of these steps is flexible, but to write a successful gaming environment, I think each step needs to be followed. Keep in mind, this does not guarantee a successful mud, but at least it might put you on the right track.

First and foremost, a fledgling administrator needs to assess the reason for the undertaking of the huge project of creating a mud. The new administrators needs to realize that the amount of time needed to set up a new game is immense. This is not something that can be done well in a week or a month. For mine, I predict it will be 18 months before I'm even going to consider opening for alpha testing. This may be a long estimate, and it depends upon my level of dedication to the project.

Second, the new administrator should have some idea of what theme their environment will follow. This step is closely linked with the first one, and sometimes, it is impossible to tell the difference between them. However, I believe that this issue is important enough to warrant its own step. Themes can range from those based strictly on a book or series of books, to no strict theme at all. One word of caution, however. If you are using a book-based theme, be sure to get the author's consent before pursuing your new project too far. There is little that is more disheartening than to lose your project after you've started your theme. I would suggest getting the authors permission on paper. It is a good idea to have the source for your theme someplace where you can read, look, modify or enchance it. Make sure once you have decided upon your theme you adhere to it. Very little bugs me more about games, than finding something completely out of theme, like a laser in a medieval settings.

Third, determine which code-base you are going to use for your environment. The code base should be one in which you have experience. If you don't have any experience in the code-base that you are going to be administrating, then it is essential that you have someone on your team who has experience with it. If you have neight experience in the code base yourself, nor someone on your team who does implementing ideas is going to be very difficult and the development of your project will slow to a "snails pace".

Fourth, acquire your code-base. Some mud packages are split into two sections, the mud driver and the mud library. Usualy only the mud driver itself needs to be compiled, but the library may require certain elements from the driver to be present and these should be checked. Compile it with the appropriate options and load your game for the first time. How to compile the driver depends on the code-base you have chosen and is really beyond the scope of this article. Instructions are invariably packaged with the distribution and should be followed thoroughly.

After this point the order of the steps become less important, so you can do these steps in any order you wish.

Fifth, set up your hierarchy. Every mud environment has to have an administrative hierarchy. Set the guidelines for your administrative council. Usually this includes breaking them into code-base development, approval of new areas/items, and enforcement of rules. More areas may be created depending on what you are trying to accomplish with your gaming environment. For examples role playing muds will want to have story tellers. Hack and Slash muds might want a separate division for quests or balance of the game.

Sixth, set up core guidelines for new objects that you want to see in your game. This can include how things are described, repetition (or lack thereof), if every noun in a description must also have a description, and so on. Many muds wait too long to do this and end up going have to go back and fix their old areas to meet new standards. If the standards are well laid out to begin with, this should never be a problem.

Seventh, design your core area. Where does everything center around? In most muds this is a town of some sort. In others it might not be. But every game needs a place where things start. Even if it is not your intention to have everyone start in the same place, you as a designer have to start someplace; so let this be your core area. This is very important because every other area will in some way relate to your core area. But it gives you and your building team a place to work off of, and that is the most important thing.

As you go along in your development, write rules which all of your builders, administrators and players must adhere to. Once that is done, by all means enforce them. A game with rules that are not enforced may as well not have any rules at all.

Eighth, implement ideas any specific ideas that you wish to base your mud on into your code-base. This can include simple things such as classes, skills or more complex things such as movement restrictions. In many of the code-bases a lot of these things are already done for you, but they may not be exactly how you want them, or done a completely wrong way for your setting. This is to be your game, so make it how you want it, not how someone else wanted it.

As previously stated, many of the above ideas can be implemented in many different orders, or simultaneously. There may be more steps which I have failed to acknowledge. This list can at least this provide a place to start from in your quest to design a successful mud.

Robert M. Zigweid is Tigran at many muds, which include Lima Bean, Illusions, Gilded Promises and Red Dragon. He is writing his own exciting mud and is involved in the continuing development of the lima mudlib.