Why Is Free MUD Development Lagging?

Thanks to Skotos for its editorial discussing why free, open-source MUD development is failing to advance swiftly. The author notes "The best [text-based MUD] efforts have been almost entirely closed-source... Free MUDs, by contrast, just haven't advanced very fast." He points to several possible factors, suggesting that "MUD information is indexed poorly, and many projects don't maintain a web site with even a basic description of what they're doing", and continues: "Another reason is licensing. The Diku license is poorly understood and shoddily enforced... LPMUDs aren't much better", before concluding: "There is no existing license that does for MUD servers what the GPL does for applications. That grudging spread of features has never happened for MUD servers the way it has for GPL-licensed applications and libraries."

Comments

Mud/Moo/Muse

[BrookHarty]

I was really into the Battletech muse years ago, it had decent ANSI gfx, and was rather fun over a modem. I tried to find one in service for old times sake, all the links where dead.

But now, with all CPU/GPU power, there are good graphical type MOO's. Half the fun of MOO's where creating objects and chatting at the same time. There are a dozen opensource VR worlds on sourceforge, and some monthly subscription VR worlds that are rather fun.

Currently I'm playing Secondlife. It's quite a improvement. Of course, I still know people who play nethack and tradewars. So the classics do stay around.

Code theft is one major reason

[Anonymous Coward]

There have been more than a few instances of MUDs taking open source codebases such as DIKU, making cosmetic alterations, removing credits and then selling in-game items for money. The most egregious example is Medievia, but there have been several others. Search the newsgroup rec.games.mud.diku if you want more information - there's a Hall of Shame, as I recall.

The reason of course, is that the writers of these codebases tend to be college kids who do it as a hobby, and don't have the money to pursue legal action. The aforementioned Medievia is actually a huge racket, and according to some estimates they've made >$250K over the years by selling items to addicted players. See his link for more information, as well as this one.

Time and money

[MMaestro]

Face it, today's games (mods and total conversions don't count) are no longer made in people's garages by developing teams consisting of one person. People don't have the time or money to maintain something as a video game, even one as small as a MUD. There are also other issues at hand, time spent working on the game vs time spent sleeping. Money spent on upgrading the server vs money spent on going to Europe for vacation. Social life vs virtual life. Paying job vs non-paying job. Employment vs unemployment.

Not all MUDS are dying

[Lord_Dweomer]

I still play Dragonrealms, and I've been a player since it was free on AOL. They charge the same as much graphical MMORPGs, and the gameplay is astounding. They CONSTANTLY implement new, well-balanced game systems. The world is large, plenty of people, and for some reason, there is a dearth of fucktards to screw up the game.

Re:Not all MUDS are dying

[GebsBeard]

I'll throw in the obligatory plug for GemStone III - now GemStone IV I believe. I am not a Simutronics employee nor have I ever been one. While people have complained about Simutronics' customer policies from time to time there is no denying the mystique of the game. That thing is a bottomless morass of a world, step wrong and you'll sink in and be lost forever. I got hooked on GS III when they started on GEnie (circa 1990) and only bailed when the addiction kicked in and credit card meltdown occurred (for me this was about $350 in charges one month).

The text MUD genre as a open-source hobby may be dying but as a commercial venture they are still completely viable. GemStone is still going strong after 14 years; your average graphical MMORPG is obsolete in 3 to 4 years, being generous.

GPL worries

[Tyreth]

MUD servers, unfortunately, break the usefulness of the GPL on a technicality. You can simply run a MUD server at home and let other people connect to it. That means you're not giving away a binary of your MUD server. The GPL only requires you to give source to the same people you give a binary to. You never have to give away a binary, so you never give away source. The GPL's intended purpose is foiled.

I've had thoughts about this at one time or another. What happens if/when services for most people are done remotely. Thin clients, applications over internet, and so on? This may be the future of computing for most people, and the GPL doesn't cover it.

Re:A few reasons

[Alizarin Erythrosin]

I rarely meet players over the age of 30. This leads to inexperienced coding and less bleeding edge technology. That could be part of the problem.

I'm one of the head coders for the mud I play on (advanced over the years). I'm 22, and started coding for them when I was 19. I'll admit if you compare code quality now and then, I've vastly improved over the years (not to say I was any slouch or anything back then, but my technique has improved since). We strive to have good features, and I've worked on some of the biggest enhancements that have made over the 8 or so years this mud has been running in its current iteration.

But I agree with your other points. Opening the source has been discussed, but the person who runs the place is pretty paranoid about the source (it was stolen before by a former coder, and she brought legal action). I had to wait a year or so and code on bits and pieces of files only related to my code before I actually got the entire thing.

Sometimes players complain about stuff, and how we sometimes get behind on code or new features. I tell them that I do it for free, for the love of the code. Sometimes live gets in the way.

Re:Duh.

[ajagci]

When you make claims like this its helpful to provide examples.

Examples? Nethack, Omega, XConq, FreeCiv, xblast, xtrek, xtb, and many others. Browse around the gaming-related USENET groups from the 1980's and 1990's. In fact, many of those wonderful commercial games you so much admire are copies (with more graphics but worse game play) of open source games.

Of course, in absolute numbers, there aren't as many of those OSS games around--while something like nethack gets maintained for 20 years, you might get a dozen releases from a commercial gaming company, all with roughly the same gameplay but new graphics.

Its also interesting that you compare all of one groups games versus only once genre

Some people find the oddest things interesting.

Arguement, failing. Straws...are all...that...are left...to grasp...

Uh, huh. We'll see in another decade or so. I predict we'll have a rich selection of high-quality OSS games in the currently hot commerical genres. It will start off as running "total conversions" and upgraded freely released commercial game content on new OSS engines and then gradually move to entirely new content.

Re:Could it be because MUDs suck?

[Matthew Bafford]

I agree, that's why I wrote:

It's a shame that more MUD owners don't realize it's the people and the environment that make a good MUD, NOT the special features (for the most part).

Back when I developed for a MUD, I shared as much of the code as I could. There was no real easy way to do so and have the results go back into the main code base, though. Most of the contributions consisted of "snippets" sent to a collection. The end result was a lot of buggy untested code (not mine!) that newbies tried to incorporate all at once into the parent code base. Chaos...

-y

Some thoughts

[Anonymous Coward]

Where should I begin?

I recently resigned from my position in the management of a very large free-as-in-beer mud. I will not go into details or even mention the mud's name/genre or my alias. However, I would like to share some of my thoughts on MUDs. Please forgive the rambling style of this post, and please forgive me for posting as AC.

Mud developer coding style

In a mud there are typically no formal code reviews or automated regression tests. Testing is done by the players, and often even the most disciplined coder can be reduced to the mindset of "if it doesn't crash, it's not broken." This philosophy typically leads to ugly spaghetti code, and that's really not something most people want to show off or publish for public scrutiny. A lot of the coding done for a mud is in the form of one-time hacks. Personally I'm embarrased by some of the hacks I've made. :(

Open source and muds

Mud developers don't release their source code for various reasons including coder pride (see above), fears about the competition stealing features and a desire to keep the players from finding cheats/exploits by reading the source. Open source is primarily useful when the end user needs to be able to modify his/her personal copy of an application. However as other posters have mentioned, MUDs are run on the admin's server. Users only interact with the game via established web protocols, so asking a game to release its source code is actually like asking Google to show us its private OS and file system.

What is a mud?

From two steps sideways, the mud experience is really a lot like a shell account on a unix box. You connect via telnet/ssh and issue single-line commands to interact with the game. Moving from room to room is *a lot* like changing directories, and most of the other commands could actually be implemented with shell scripts. The more interactive features like combat and responsive NPCs would require a bit more glue, so you would probably have to modify the shell for those.

Taking two steps back, we see a user database with at least rudimentary access control, an extensible command parsing mechanism, a scripting language, a database for game content, a combat framework and means of processing user events. Note: Admins will likely want tools to modify the scripts and database content, a means of generating various game stats and some mechanisms for dealing with trouble users.

What parts of a mud should be private/unique?

For obvious reasons, the user database should be private. The content database also clearly belongs to the mud. This includes textual descriptions, vital statistics and special behaviors of all the objects, NPCs, rooms, custom quests and scripts.

So what does that leave for open source?

It excludes all of the content and leaves all of the framework -- the stuff that's generic enough for use in any MUD. If you're just looking for an open-source framework, check out Sourceforge. It looks like there are a few active mud projects there. I plan to post my framework there when it's done (don't hold your breath; I'm stalled at the point of only having a server, a command parser and a custom scripting language).

Some final thoughts

If you're looking for a complete open source game, you're probably confusing mudding with FPS or RTS games. Mud designers put in a lot of work to ensure consistency in the game. While we may be willing to give you a framework, you're on your own when it comes to the content.

Re:Some thoughts

[0x0d0a]

The content database also clearly belongs to the mud. This includes textual descriptions, vital statistics and special behaviors of all the objects, NPCs, rooms, custom quests and scripts.

That's actually one point that I find kind of sad.

Yes, in an ideal world, every MUD would be unique. However, there's also something to be said for having a generic "elf" (or even "Tolkien elf") that people keep improving and working on, and can be used to accelerate building in new MUDs.

I've seen a number of MUDs go belly-up, and inevitably, all that content that the MUD admins guarded carefully to keep anyone from stealing it gets lost, gone forever. Had the content been around, a player could have carried on the torch, and the MUD would not have died. I still miss the wild ChibaMOO that I once wandered around in for a few weeks, and I wish that there was some way that I could do so again -- but all that content is long gone.

Obviously, folks should be able to do what they want to do with content. If they don't want to share it, that's their perogative. However, it is kind of sad how few people choose to share their mobs/items/rooms for, say, a Circle-based MUD.

If you still think that shared content wouldn't benefit anyone, consider what the existence of public libraries has done for the interactive fiction community.

Some other MUD-related thoughts:

* Most MUDs are very, very, very simplistic compared to interactive fiction, and follow roughly diku-like commands. The parser and the degree of description and object interaction in an IF game is far, far greater than that of a MUD. I think that the ability to get a nice set of generic objects (come on, there are nice tweaks that you can make, but a game that includes a Louisville Slugger has an item that's pretty much a Lousiville Slugger).

* MUD codebases started out a long time ago. You called them "hackish". I think I'd call them "not as amenable to modular features as they could be". Furthermore, most code is old-style C. MUDs are, IMHO, a good place to use higher level languages than C -- they do not have high CPU requirements, and do undergo frequent development. I do wish that there was a better alternative than Java, as Java is (again, IMHO) too RAM-hungry for effective MUD use.

* The fighting system in most MUDs is still quite simplistic. This is the area of greatest improvement of most MUDs (since it was the most lacking part of the original diku system, and most derivatives with improvements have not shared their changes). Unfortunately, most coders do not share changes, so there *is* no common set of, say, martial-arts related features.

* Color. ANSI was not an original diku feature, and because of that, color customizability is patchy among many MUDs.

* Non-combative solutions to problems. MUDs have traditionally focused on long, not uncommonly boring hack-and-slash. Good IF games or Dungeons and Dragons games generally have a number of non-combat solutions to problems. Fallout or Neverwinter Nights frequently have non-combat solutions (or at least multiple solutions to problems). Diku didn't do it, so nobody does it.

* MUD security is still poor. Almost all MUDs are still accessed via telnet, including a plain-text password. Why not SSH (particularly given the compression features in it, which would help modem players everywhere)? Sure, it's not as bad as exposing a shell account, but it's not great. Again, none of the standard open source codebases support SSH, so no MUDs do.

I'd be curious as to whether there are any MUDs that expose their entire codebase and roomset via CVS (well, given today's articles, maybe SVN :-) ). I really think that there are a lot of features that folks would make good use of if made available.

Finally, I think that a lack of open-source and open-content MUDs leads to a good deal of fragmentation. There are many half-done MUD frameworks out there, instead of one or two actively developed and featureful MUDs.

I'm more dedicated to my mud than most games...

[Phoenixhunter]

What I enjoy the most about MUD's (or at least the mud I participate in) is the strong connection between the developers and the players. I'm fairly stingey with my money but I know I'd give as much as I could financially do so if my MUD needed additional funding for bandwidth/hardware. With 150+ players on at any given time in a 30,000+ room Mud there is plenty to explore and quite a few guild dynamics to keep things spiced up.