We’ve been working away on this mudlib for a while now, and in my view it’s getting pretty pimp. Yeah, I said pimp, you’d be amazed how Street I am. It’s safe to say that the Epitaph mudlib is a very definite fork of the Discworld lib now, with very different ways of handling certain kinds of functionality, and a whole raft of the extra features we need to support a survival horror MUD set in the near future. We still share a substantial amount of code, but we’ve got a year and a half of very focused attention spent on our own lib, and each line of code has moved us farther and farther away from being a ‘Discworld mudlib’. We’re not shipshape yet of course, and every day brings new modifications to the code, but at the back of my mind has always been the thought ‘it would be worth releasing this as a lib at some point’.

Part of the reason I have had the vague desire to do that is because we have the Epitaph Survival Guide (http://www.monkeys-at-keyboards.com), and I think it’s a pretty good introduction to what’s needed to develop a MUD, from rooms to larger game design concepts. Considering how it weighs in at around 550 pages, it seems something akin to overkill if its sole audience is the developerbase of a single MUD. There are other reasons too, including the credibility that comes from being the MUD that sources a good lib, and the free advertising that it provides. It’s also nice to give something to a community, even if the MUD developer community is full of a disproportionate number of dreadful, awful people[1].

It is, however, a very saturated market out there. There are dozens of code-bases over dozens of languages. At the moment, a potential new MUD admin is not lacking in choices as to what they can build a game with – in fact, it’s probably the other way – there are too many code-bases out there. Every so often, I see a new announcement on the various boards saying something along the lines of ‘I’m building a new code base from scratch, and…’. It always makes me wonder why – aside from the fun that comes from building a brand new engine (and it *is* a lot of fun, I did just that myself myself some years ago), it seems that it’s catering to a need that simply doesn’t exist. If people aren’t creating MUDs, it isn’t because of a lack of support.

Many of the code-bases require specialised knowledge, although there are also a few libs out there that are good for newbie developers. We started with the Discworld mudlib, which very much isn’t for novices, so there’s perhaps a market for a Discworld-esque lib that is cleaned up and made tractable for beginners. However, there we encounter the second reason not to release a mudlib – starting a MUD is not really something *for* beginners.

People underestimate how much work goes into a MUD, even if they start from a solid code base. You can have a MUD up and running in minutes, but that’s not the same thing as having your own game. It’s like running a server for an existing MMO – there is nothing about it that is yours. You can change a few descriptions around and ‘skin’ a public codebase in a week or so, but even then all you’ve done is a paint job. It’s still not your game. It’s your game when you have things that are unique, that you built with your own two little hands. It’s your game when you can offer a substantially different experience from every other MUD running your codebase. That takes a lot of time, a lot of enthusiasm, and a lot of willingness to slog away when it simply stops being fun. As such, I usually advise newcomers that they don’t want to start their own MUD at all until they have spent a couple of years ‘earning their bones’ on an existing game – that’s the easiest and safest way to really comprehend the scale of the job,. Additionally, it’s always more fun (and thus, more likely to be something you stick at) to develop alongside other enthusiastic, dedicated people.

With that in mind, I think mudlibs that are specially designed for newcomers are, while delivered for the best of all possible intentions, actually somewhat harmful. It all looks so easy to begin with – a few typed commands and there is your very own MUD. That kind of thing though is always going to be the simplest part of setting up a game – the problem is you can’t simplify the *hard* work away. In the end, what you create is a relatively vibrant community where people are setting up instances of your MUD all the time (which is gratifying), but a very high rate of churn and a lot of questions from those who don’t quite understand that it can’t all be as easy as the first few steps. You also get a lot of questions from those who feel that if you aren’t willing to answer their questions directly, you aren’t willing to answer their questions at all. It’s surprising the number of people who take being directed to available documentation as a personal slight.

So, a new mudlib isn’t actually required, and while there is probably a niche for a beginner friendly Discworldy mudlib, I have my doubts that it isn’t actually counterproductive to make one available. Really, is there any point at all in producing an Epitaph lib beyond what’s needed for our own purposes? Before I left Discworld, I went through the task of creating a new distribution from the mudlib as it stood – it’s that (still unreleased) mudlib that was the basis for Epitaph. It’s a lot of work to create a distribution from a production MUD, because production MUDs accumulate cruft. They’re full of half-finished systems, experimental code, and inelegantly engineeredsystems that confuse and conflate ‘mudlib’ and ‘game’ code. The task of cleaning that up between releases is substantial – even if you tidy up the ‘proper’ mudlib as you are doing it, you’ll still acquire cruft in between releases. Essentially, having a public mudlib means committing to a lot of work for very uncertain, if not entirely imaginary, gains.

I still haven’t made my mind up about releasing an Epitaph lib. At any rate, it’s a decision that can wait – I would however be interested in the thoughts others may have about where a public lib falls on the cost-benefit scale.

[1] No offence to any of the dreadful, awful people who may be reading this.