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 World Does Not Need Another (Diku) mud

by Jeff Bennett

OK, let's face it, the proliferation of various code bases (a.k.a stock muds) has profoundly damaged the mudding community. Since the launch of the original gamma Diku, the number of available code bases has constantly grown. In fact, whole entomologies have been created to trace various muds back to Gamma 0.0. At the same time, the number of members actively mudding has also been declining. Likewise, the amount of innovation seen in various muds has also diminished. These events are not unrelated.

The Good Old Days


Two Yorkshiremen.

Once upon a time, there were only a handful of muds. Sure, Gamma 0.0 was available to everyone, but it had a bunch of (intentional?) problems. At that same time, the Internet was in its infancy. Resources were scarce. Disk space was at a premium. CPUs often had to be shared with other users. And good machines were hard to come by. Setting up a mud meant solving the fairly daunting problem of not only locating a no-cost, lag-free server willing to host a mud, but also solving the myriad programming and administrative challenges of the early code bases.

The result was that there were fairly few muds in existence, and players tended to work their way up the ropes and became part of the administrative staffs of the existing muds. Development teams would form where one member had a host but no programming skills, and others were able to handle the administration or programming.

The low number of muds and the need for a large pool of skills kept numbers on individual muds high. Thus, when a problem cropped up, be it a need for a new server, or a way to tackle a dicey balance problem, there was almost no end to the number of people throwing out ideas on how to solve it. Fortunately, large staffs were also available to implement those ideas.

Modern Mudding

But as the years passed, Moore's law has caught up with the needs of modern muds. At the same time, more and more muds have followed in the footsteps of the original Diku team, and released their own code bases to the public. The result is that everyone and their brother can download a fairly well developed code base, and run it on their personal desktop. The number of muds has ballooned and there is no longer any compelling reason to maintain unity within a given mud. Upset with some mud's new policy? Don't bother complaining or suggesting alternatives to improve the policy, simply download your own ROM or Circle and do things your own way. Of course, some players will follow you to your own new mud.

While the increase in the number of muds might make the maintainers of mud lists happy, it has also diluted the overall mudding community. Fewer players play each mud, meaning there are fewer ideas offered when problems occur. Unfortunately, the availability of the stock muds makes going your own way all too easy. No longer is there any compelling reason to correct a wayward mud through debate or reasoned discourse.

The Downward Spiral

Tragically, a disheartening spiral is also created. With fewer numbers online, a new player on a mud is less likely to discover the virtual community that characterized the early muds. Likewise, the cookie-cutter look-&-feel of the stock muds is quickly realized by true newbies, and more often than not, they give up on the idea of becoming a mudder and find other online pursuits. The few, truly unique muds are hidden amongst a vast sea of stock muds that are simply draining away players and discouraging new people from becoming mudders.

OK, I'll admit that offering a code base isn't altogether evil. Certainly, the arguments of the open-source community apply in terms of discovering problems, and I am sure that more than one person has learned to code by administering a mud. However, it now seems like the only skill it takes to run a mud is the ability to successfully FTP and untar. Likewise, the only commitment in terms of time that an imp needs to make is the 5-10 minutes it takes to download. Gone are the days when UNIX skills came in handy and implementors were expected to put in a few hours of coding a night in order to keep their muds on the cutting edge.

Now, I'm not advocating that distribution of mud code should be abolished. Obviously, no one wants to keep reinventing the wheel. But it sure would be nice if the stock mud distributors placed more restrictions on the people that downloaded their stock.

What possible benefit to the mudding community is there to allow the existence of an infinite number of essentially identical muds?
Can't the licensing agreements be written so that a few weeks or months of modification are required before muds may open to the public?
Aren't all muds better served if each is unique?

The World Does Not Need Another mud.

Jeff is a 28 year old software engineer in Rochester, NY. As the character Batopr, he has been a member of the development team for Grimhaven (formerly SneezyMUD) [telnet://sneezy.stanford.edu:7900] since 1992.