In this blog post I want to talk a bit more about our ongoing ‘modernization’ process. I know modernization sounds like a crazy thing in reference to text-based gaming, but hear me out. I GOTS THINGS TO SAYS.

Games that are built around communities live or die on their social tools and MUDs are no different in that respect. We’ve been relatively well served with the tools that we have, but they’ve all been pretty limited. We’ve had LPC implementations of a bulletin board system and a blogging engine, and these have allowed us to provide support tools for social engagement. Unfortunately, being (very) bespoke tools that were written for a particular mudlib, it means that the development and maintenance burden for these tools fall on us in Epitaph. If something goes wrong with the LPC blog, we need to fix it. If we want to add a new feature to the board, we need to roll up our sleeves and write the code.

That’s all fine, but we’re not in the business of being full-time forum or blog developers. We’re building a MUD here, and so our efforts are usually directed everywhere. It’s not that our implementations of either of those things are half-hearted, it’s just that they’re ‘good enough’ implementations. They work, they meet our needs, and that’s it.

That seems fine until you see what the ‘proper’ forum or blog platforms can do. You can’t even search our bulletin boards or blogs. Messages scroll off the board (and are gone forever, although archived to a text file accessible by creators), blogs can’t handle inline images, neither implement a number of common access protocols (we have RSS for the blog, but no atom). We could add all of that of course, but we haven’t yet and there’s no reason to assume that we’d be any more inclined to do so in the future. We’ve got other things that are more important.

The architecture that Eek@Epitaph is putting together includes a password authentication system – it’s possible for us now to authenticate users and passwords against the MUD itself. This means that any external application that allows for the login procedure to be overridden can be changed so that it takes in the username and password and asks Epitaph ‘Hey, is this person cool? And if they’re cool, how cool are they?’

It seems like such a simple thing, but it’s the key that we’ve been able to leverage to upgrade from our internal boards and blogs to fully featured platforms. We’re now using phpbb for our forums and wordpress for our blog. These are very flexible tools, allowing for full skinning[1] to be brought in line with our web theme, and you can access them using your normal username and password. They’re hosted on a different server too, allowing for communication channels to remain open except in the most catastrophic of catastrophes[2]. If the MUD is down, the forum and blogs will be fine. If the forum or blogs are down, you’ll still have the MUD.

We’ve always had external wikis for developers and players, but those have worked on their own usernames and passwords. Until recently, you couldn’t even register for the player wiki because the amount of spam coming in was extraordinary and nobody was very interested in taking on the curation duties to combat it. I investigated various spam solutions, but none of them seemed to do much in and of themselves – they were really just filters protecting against the majority, you still needed people guarding the precious pages. Now though the only way you can spam on the wiki is to create a player account on Epitaph, and I suspect that the complexity of that procedure is too high, and the size of the potential audience too low, for any of the automated spam bots to bother with. It means a spam-free wiki that anyone with an Epitaph account can already access.

It’s all very exciting.

The process of moving across to our external tools isn’t done yet. The tools have interfaces which are particular to them, and converting them across to the Epitaph way of presenting the website is an ongoing chore. However, what we have lost in the upgrading is considerable – we’ve lost in-mud access. Previously, bulletin boards were dotted around the game for players to use, and all creators could clone a ‘master board’ they could carry around with them to get access to any of the boards that had been set up. That unfortunately is no longer going to be possible – it’s one of the things we’re going to have to sacrifice[3] for the vastly increased functionality.

The blog integration is more serious, because the in game blog command is the primary route through which people gain access to the list of recent developments on the game. Luckily in this case we’ve more reason to celebrate because integration is an easier job – we just need to be able to pull in an RSS feed from outside the MUD, parse it, and then display it. We’ll even be able to post to the blog from within the MUD because wordpress has a neat ‘send a mail to your blog and it’ll publish it’ system, and we can already send emails. I’m sure you can imagine too how much use we could get out of an internal RSS parser – I may never need to alt-tab away from the MUD ever again.

One of the benefits that having in-game tools provided was that we could trigger informs when things happened – a new post or a new blog for example. We’ve lost that, but an RSS parser will give us it back . We can query the feed, and prompt up an inform when it differs from the last one we received. The great news is that we can provide RSS feeds for mediawiki, wordpress *and* phpbb with relatively simple mods.

So, why go to all this trouble? Are the new features we get worth the downsides?


There is more than just the immediate payload of new features to justify the work of migration[4] – it’s one of those ‘it’ll pay off in the long run’ situations. Not only do we get lots of new features, some of them fantastic[5], we don’t need to maintain any of them! There are people out there maintaining these platforms already and they will keep on maintaining them. We just upgrade whenever we need to and boom – we get all that work for nuthin’.

Our LPC boards didn’t get indexed by google because they required a MUD account to read them, and even if they didn’t indexing was pointless because messages scrolled off (sometimes within days). With phpbb, we can set up boards as being viewable by anyone (which is now true of all the player boards) and they can be indexed by search engines. You’ll know yourself how much awareness can come from an active forum – how many times have you typed in a query to end up at some random forum you’d never heard of before? That could be us now – we could be that random forum you’d never heard of before. Hi, I’m Drakkos – it’s nice to meet you. Sit yourself down. You look tired.

Better tools with greater features, maintained more effectively for free – that’s the kind of deal I could find myself falling in love with[6].

There are some other systems in Epitaph that I would like to shunt over to external tools – I’d like to offload our internal mail system, provided mail could still be sent and received in game. Our mail architecture is a perfect example of the kind of system that is ill-served by our bespoke implementation – it works well enough to be an internal mailing system, but I don’t know about you but I prefer to manage my email in Thunderbird. I could write an SMTP server for the MUD, or I could work to integrate an external service and as a result get SMTP and all the other things I’d like on the back of that.

It’s not that my time is not well spent developing and maintaining support tools. It’s that there are already people doing that kind of thing, and as far as I am aware there is nobody outside of Epitaph writing the LPC-specific zombie apocalypse game code that is core to the wonder that is us. It’s a no-brainer decision really.

[1] Albeit at the cost of a lot of hair and most of your sanity.
[2] A zombie apocalypse, a nuclear war, or a majority Tory government.
[3] At least in the short to medium term
[4] To migrate you need an authentication architecture, somewhere reliable to host a blog, forum and wiki, someone with the time and willingness to reskin some absolutely horrendous css/php combos, an RSS parser and a few other things here and there.
[6] Have you ever fallen in love (ever fallen in love) ever fallen in love (ever fallen in love) ever fallen in love ever fallen in love with some deal you shouldn’t have fallen in love with?