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 ‘‘ 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.


6 comments so far

  1. Matt on

    I think it’s a good idea to try and preserve a lot of the MUD resources that are around, but I don’t think it’s a lack of resources that is really holding people back.

    How many decent new MUDs came out in the last year or two? And of those how many have any players? Take Geoff Hollis’ ConQUEST for example. A custom game with some genuinely interesting ideas and mechanics, yet it never really took off and looks to be dead now, which is a real shame.

    Archons of Avenshar is another great example. It’s certainly innovative and new, but I’ve rarely seen anyone else playing it.

    I just checked the top 20 games on mudstats and I think all of them are 10+ years old and almost half are commercial.

    Most new MUD development these days seems to be copycat games from disgruntled former players or hobbyist tech tinkering where the primary purpose is to play with technology rather than make an actual game.

    I’m not knocking your idea at all, but I guess I just wonder how useful it will really be.

    If there is a lack of progress in the MUD community it’s because players want the same old familiar games and not because of a lack of resources.

  2. georgek on

    All good points, but allow me to play the foil for a moment. That ConQUEST didn’t take off could be as much a result of Geoff going MIA as anything else — as I recall it was really just getting going when the plug got pulled (I check on it regularly to see if it’s back).

    Avenshar is a good example, but notwithstanding its many positive points, overall it didn’t offer anything beyond a a conventional mud experience in its gameplay, which may be a lesson that a good aesthetic experience isn’t enough on its own, or at least, for everybody (I should point out it was enough for me, as I played Avenshar when it came out more than I had played any mud for the last couple of years, but that’s besides the point I think).

    A better example there might be Bedlam, with its mobile client. The gameplay might be similar to a typical DIKU, but the mobile experience is different enough to push it forward.

    Now the overall question of how many good muds were released in the last couple of years is important, but I think it’s related to the problems I was describing in this post. I don’t think looking at the top 20 muds is that relevant to these problems either.

    The best example is Maiden Desmodus of course, as on the face of it I think it should be successful — I’ve been waiting for your take on that, but I understand that it’s probably not something you’ll be visiting soon.

    So back to the question of new MUD development. Copycat games aren’t something that is ever going away, but I think it’s tangential to the main matter here. Tech tinkering probably accounts for most of the projects I described seeing on Github — indeed, a MUD is an ideal project to tinker on, and this isn’t something going away either.

    But how many promising projects have been started and didn’t succeed because the friction was too great for them to gain any momentum? That’s very difficult to answer of course, and even in a perfect environment a minority of projects will ever succeed. But the current infrastructure for mud development is far, far from perfect, and I think we can all agree on that.

  3. Matt on

    I agree with you that improving access to resources may help more projects come to fruition, and of course that’s a good thing for those projects, I just question the overall impact that will have on the “state of MUD”.

    Seeing more innovative projects completed isn’t necessarily going to improve the health of the MUD community because plenty of original and interesting projects have fallen by the wayside because of lack of interest from players.

    Or put a different way, it’s not these innovative and interesting MUDs that are attracting new players.

    Maybe we need to focus more on areas like marketing or presentation if we want to advance the art, rather than spend time developing new dynamic generation systems or NLP parsers or whatever the current cool stuff is.

    As to whether MD was/is successful, I suppose it depends on how you define success. In terms of player numbers then no I don’t think so, but from a financial perspective, yes absolutely.

  4. KaVir on

    Creating a comprehensive reference document for protocol support is a great idea, but why not just use Mudpedia for it? You could write up an initial draft, then others could expand on it.

  5. georgek on

    @KaVir, that’s the general plan, though one issue I’m debating internally is that since I think this doc should have a certain bias (in other words, don’t just make it an encyclopedia of all protocols past and present, but provide best recommendations — I guess the two aren’t mutually exclusive), would Mudpedia be the best place for it.

  6. KaVir on

    I see your point, but I think you could still keep it pretty factual while making it useful. Mudpedia isn’t Wikipedia, there’s no reason why you can’t use personal opinion as long as it’s well explained and justified. For example I don’t think anyone would have a problem with pointing out that MCCP1 is obsolete, that 102 is redundant, that most implemenations of MXP only support a specific subset, etc.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: