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!
The mud community, on an average, is seeing the birth of 10 would-be muds per day. Many of these muds last for five or maybe six days then they disappear. Why? The answer is quite simple really. The admins in charge of these muds did not have enough technical knowledge to run the mud successfully. Also, they could not find any one willing to help them code areas, and they burned themselves out trying to tackle it alone.
Running a mud is a very big job, and should be handled by a team of at least 10 people. This team should include a design team, to design new areas, objects, and quests; an area builder team, to code the areas, objects, and quests that the design team creates; and a mudlib team, to code and design new features and modifications to the mud library.
Seeing as there is a shortage of coders and builders, and a surplus of muds, many would-be admins will not get anyone to help code their muds. They may post on every newsgroup possible, send out millions of email messages, and advertise on twice as many sites, but still no one will volunteer to help. There might be a few lucky newbie admins to put together a small team and create a successful mud, but it shouldn't be counted on.
In order to acquire a team of successful coders, the admin must first learn to code himself. Then, he can at least create a newbie area and make a few modifications to the mud library to show that he has something original. Then, his chances of having people volunteer to code for his mud increase slightly. But there is more to it than that. The admin has to have an established player base, a fully populated environment, and an extremely unique idea.
However, a fully populated environment and an established player base are hard to come by if your mud isn't very well known. So, as you can see, this all forms one vicious cycle. In order to break out of this cycle, some steps need to be taken. First, you need to have a server on which to run a mud. Second, you need to install a mud library that is easy to rip apart and put back together. My recommendation for this is a TMI mud library. Out of all the libs I looked at, TMI seems the easiest to customize. Third, you need unique areas, commands, skills, and such. After all this is done, your chances of succeeding increase by about one third.
Customizing a mud library is not as easy as it sounds. Although some are easier than others, there is still lots of hard work involved. You need to know basic C, or whatever language your mudlib is coded in, and you need to understance basic programming concepts. Also, you need to have a clear and established plan of what features you want to add, and those you want to remove. Planning is critical to your success, if you fail to plan then you plan to fail.
Now, many mud veterans will tell you to forget running your own mud and to code for someone else's mud. That is sound advice, and pretty darn good advice too. But the best way to learn something is to do it for yoursef, and running a mud is a lot different than coding a mud. Allthough it is unlikely, it is possible for the admin of a mud to not know anything about coding and still run a successful mud.
Once you are able to do all the things I discussed here, then you shouldn't need very many people to help make your mud a success. You should know enough to stand on your own two feet, and shouldn't have to clutter the newsgroups with posts begging for help with all the simple things. Then, you will no longer be regarded as a mere "newbie", but as someone who is willing to put forth the extra effort and create something unique, something that can grow to take a life of its own, so to speak.
March 2001 Imaginary Realities, the magazine of your mind.
© Copyright Information