Slashdot Mirror


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

7 of 88 comments (clear)

  1. Mud/Moo/Muse by BrookHarty · · Score: 4, Interesting

    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.

  2. Code theft is one major reason by Anonymous Coward · · Score: 5, Interesting
    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.

  3. Time and money by MMaestro · · Score: 3, Interesting

    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.

  4. Not all MUDS are dying by Lord_Dweomer · · Score: 4, Interesting
    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.

    --
    Buy Steampunk Clothing Online!
  5. GPL worries by Tyreth · · Score: 4, Interesting
    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.

  6. Some thoughts by Anonymous Coward · · Score: 5, Interesting

    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.

    1. Re:Some thoughts by 0x0d0a · · Score: 3, Interesting

      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.