The MUD Developer’s Reference

On Github the other day I randomly did a search for ‘mud’ and was knocked over by the number of mud projects I found. Of course, most of these were half-finished (more like half-started). But in light of that and some other notable discussions lately the gears got to grinding.

While there’s a vast amount of mud information out there, it’s widely scattered, buried in archives, or surfaces once every umpteen years like that Scottish castle I can’t remember the name of when someone asks a relevant question on a forum somewhere.

None of this is particularly bad or even unusual. Information has a habit of filtering down like groundwater into the substrate of a community. But to beat a bad analogy a bit more, I feel like the wells are starting to run a bit dry.

Between the whole fiasco with ‘mudstandards.org‘ and the general sorry state of protocols with respect to server and client development, if a young coder decides to make a mud or a mud client — a worthy, attractive project, and based on the number of repos on Github I’m not the only one with that opinion — they are going to have a frustrating experience and are not going to get much support from the state of the existing resources.

The mud community doesn’t gain then the resources or energy of those developers in return, and this reinforces a negative feedback loop: projects that could be promising don’t overcome the friction of their early development, and the mud community rolls on without as much progress or evolution as it could have.

Not to say some people aren’t making an effort. Mudpedia is promising (see its comparison of clients) and individual developers seem to soldier on, despite sentiments such as these:

And this is just my personal feeling now, but I’m a little unsure there’s that much value in having shared standards in this field in the first place. In the end of the day this is about making games, and if you can provide a good client that people use to play your (good?) game, that’s all you need. Past are the days of only using telnet from a relatively dumb terminal to connect and therefore there being value in standardized connection. How many of the successful games (not just MUDs) out there support more than one client?

While there’s an important truth here (don’t lose sight that we’re making games) I think it misses an important point. Muds came of age within a strong tradition of free games and shared resources. To now lump muds in with the general field of games essentially ignores that history. While commercial text muds are extremely important in my opinion to the health of the mud community, and not just commercial muds but ambitious games with custom clients, the history of free games and shared resources shouldn’t be consigned to the past or simply salvaged and scavenged like you would a shipwreck.

But back to the point and the title of this post. At the moment there exists no comprehensive, current reference for the aspiring mud developer, but this information does exist and I think could be assembled with some work. With promotion I think new mud devs could find this reference fairly easily, and within a short amount of time (on the mud time scale anyway) we would have a document that, simply because nothing else like it exists, would be the ‘go-to’ reference for new mud developers and a touchstone for the rest of the mud community.

My plan now is to contact a few people and start to pull together resources to see how this takes shape.