MUD tech is fun/cool, but…

Tuesday, January 08 2013

As software development evolves, there are an ever-expanding number of ways to put together very complex, elaborate systems that are fun to geek out on. Multi-processing is becoming increasingly prevalent, distributed systems are a boon to cases with massive scalability or reliability requirements, and there are all kinds of neat data stores available. These are all definitely things that have a place in software.

But what does this mean, in the context of a MUD?

Honestly, very little. Even a very large MUD with hundreds of connected players can be ran on a very pedestrian machine with a modest amount RAM, and very little bandwidth. Multi-threading is not a requirement for performance (and can often work against it). Highly distributed, multi-server setups are hitting nails with jackhammers. After all, we’re talking about a genre that primarily features smaller (<100 connected players) games.

An important thing to keep in mind when developing a MUD is that simple, well-thought-out MUD architectures have a huge advantage over those their more complex kin: They are easier to develop, and they are a lot more likely to ever see the light of day.

MUDs are a labor of love

Although you’ll hear people crying about the demise of the text-based genre, there will always be a niche out there for our kind. However, the vast majority of the games in our space are going to remain non-commercial, and mostly developed by volunteers on their spare time.

By making simplicity a high priority, we make sure that it’s easier to make progress when you do have a few moments to sit down and work on your game. While you could write a super-distributed, super-fault-tolerant MUD server, it’s probably going to make future development more complicated, and you may run out of steam before you get anywhere close to being "done". As someone who would love to see more great MUDs out there, this makes me sad!

Developing and launching a MUD is a labor of love, and it has to be fun and interesting to you. You have a finite amount of time to get your game launched before you probably lose interest and move on to other things. This "time limit" varies from person to person, and some possess the rare ability to regularly, routinely work on a game for years before going public, but those types are very rare now. Your goal should be to open to the public before your "ok, time to move on" timer goes off. Simplicity is one of your biggest allies while pursuing this goal.

But… there are always caveats

A very valid counter-point to this argument for simplicity is that MUDs are a great way to learn new technologies, to experiment, to do things one might not normally do. If one’s goal is to tinker more so than to actually release a game to the world, you can throw this all out the window. Get as complex/geeky/sexy as you’d like, and have a blast. Who cares if you never ship? That’s not the point for you, anyway.

For those that are most concerned with actually "shipping"

Focus on your core functionality. What is your "minimum viable product?" What is the most direct way to get to your opening day? Avoid unnecessary complexity, and remember that you can always refactor and improve performance/scalability as you grow. Nothing is set in stone.

Avoid traps like multi-threading (unless you really have to have it), super scalability, and elaborate distributed setups unless you just really want to play. You’re designing a Gocart, not an IndyCar.

Simplicity. Clarity. Focus. Oh, and ship the damned thing!


Magnificant MUDdy Musings

Friday, February 24 2012

The Evennia MUD Server has been progressing through beta at a good clip, with much effort spent on fine-tuning existing features, and expanding on the already excellent pile of documentation. Much to my delight, the current maintainer, Griatch, has started to blog about Evennia development. If you are at least ...

read more

Sphinx and Design Documents

Monday, November 28 2011

As I’ve matured as an individual and a developer, I find that I like to spend longer and longer amounts of time in the planning phase before writing too much code. I’ll tinker with some of the technical problems I’m very concerned about, make sure my idea ...

read more

CouchDB as a MUD server data store

Monday, October 17 2011

I’ve been using CouchDB as the data store for my in-development MUDDawn of the Titans. So far it’s been very enjoyable to work with, through the CouchDB Python module. I’ll take a moment to share my experiences, for those who might be interested.

To provide some ...

read more

Over the speed bumps

Sunday, October 16 2011

One of the worse parts about writing a codebase from scratch for a specific game is the staggering amount of foundation work that has to happen before you can really start making visible progress. Database layers, object representation and manipulation, account management, exits, and a basic set of global commands ...

read more

Evennia MUD server grows a proxy

Tuesday, September 06 2011

I’ve obviously been on a bit of a proxied MUD server tangent of late (see here and here). I typically haunt #evennia on FreeNode, and brought the point up to the current maintainer, Griatch, a few weeks ago. As is typical for Griatch when he finds something he likes ...

read more

dott - now with more proxy

Tuesday, August 30 2011

As mentioned in my previous post about putting a MUD behind a proxy, I’ve been really intrigued by some of the things such a setup would allow. In fact, my motivation was enough to warrant actually trying to implement my own interpretation. My implementation of this split proxy/MUD ...

read more

A MUD behind a proxy is… potentially great

Tuesday, August 02 2011

My perpetual tinker project is a MUD server that may or may not ever see the light of day. In recent adventures, I pursued using Exocet to make my goal of a mostly interruption-less experience for the players a reality. The attempt worked in most cases, but failed horribly in ...

read more

Exocet makes code reloading easy

Wednesday, July 20 2011

One of the big philosophical "pillars" I’ve been building my tinker Python MUD on is that cold restarts (restart the process, clients are disconnected) should be exceedingly rare. Code re-loading in Python can be challenging, but Allen Short has nailed it with his Exocet module.

The coolest part for ...

read more

Of Markdown, REST, and others

Tuesday, July 19 2011

As I’m working on my side project (You should probably watch it on GitHub to stroke my ego), I’ve been toying with how I’ll eventually handle colors and web content. I’m almost fully set against using MUX/MUSH color codes, as those don’t do the ...

read more