One more note.. I spent four or so hours today going over all the open source Python codebases that I could find. If you really want, you can read my entirely subjective notes. But there was very little code that seemed useful for reuse.

If there were systems that I thought would be nice as a shareable library, they were coupled to bulky third party dependencies like Twisted. IMC2 clients for instance. Otherwise, the code was too integrated into custom frameworks to be of worth. In several cases, I noted instances of code reuse that seemed to be ill-suited and brought the constraints of the reused library in question back into the code base usage of it.

In one Python related thread that I read, it stated that all Python code bases were at an alpha level. I think this is being generous. I was also surprised by how few were still maintained.

IMHO, Python is the best platform to develop a MUD. It would be a no-brainer for a team of coders following a design document.

The problem is just writing a MUD in 2010. MUDs are effectively forgotten. Anyone developing a new one today has to contend with a monumental amount of work, a general lack of audience interest, and wrestling with the ill fit of buggy Telnet clients in the age of 3D and Flash based MMOs. Worse yet, coding one is typically an act of self-expression – the classic, "If I had my own game, it would awesome because…" People with that motivation don't want to join someone else's team, they want to do it all themselves. Now merge all those points under a multi-year development cycle and it's easy to lose interest or become discouraged.

Heck, I reach points where I think, "I really don't like the approach I took with X" and walk away for months until I think of a more elegant solution – even if X is something completely non-essential.

Many people are building a model ship rather than an actual game. That's not better or worse; it's just a difference to be aware of. It becomes a problem if their real motivation is to make a model ship, but they act like they're trying to make an actual game.

So true. I remember my first crack at a MUD server was using a VB6 form application with an array of
WinSock controls. I didn't even use class modules. I wrote the entire thing with about 6 months of VBA
training. I was allocating tons of arrays that shared an ID as index. It's been several years of daily learning
and development since then. It seems every time I think I know some pretty nifty features, I realize that
even some of my recent code could use some refactoring.

The irony here, is that I was much happier in the dark ages using VB6 than I am now. Although my capabilities
allow me to make my MUD do virtually anything I could desire, there was something to say about feeling like I
was "inventing the wheel", not reinventing. Ignorance was self-limiting, yet blissful.

I really hope I can get over my perfectionism just long enough to finish something for once :biggrin:

Ill agree high level languages are a good choice for a mud. Too bad that wasn't your statement.

if python > ruby
   write_mud()
else
   write_ruby_mud()
end

I would go further and say it was an investment. When someone wants you to code for their MUD, you would be investing yourself and your time and effort, in its development. Should something reveal itself to be objectionable about the project, and you do not have the control to change it, then your investment loses value unless you can change that perspective (Stockholm syndrome?).


I tend to work on mine when I either think it has been a while since I last did and force myself, or I have a specific notion that's grabbed my interest, so that I have reason to. Often the latter occurs as a result of the former.

But is the same not true for playing a mud as well? You invest your time and effort into developing your character, and if the mud undergoes changes you don't like, your investment loses value (to you at least).

There are at least ways to get around the development concerns - such as only accepting projects that are fairly modular and not signing over your rights to your work. If you don't like the direction the mud is heading, or if it closes down, you can simply take your work to another mud. Should you harbour the desire to one day create a mud of your own, your time spent working on other muds won't be wasted - as well as picking up experience, you'll also be building up a library of features that you can reuse in your future mud.

I don't know how you'd do that for a player though. You could offer them their pfile, but it has no real value outside of the mud. Perhaps a system for player-generated content could allow the player to download their work? Players who create their own client scripts and plugins could of course take those to another mud, too.