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."
Plus, the more established MUDs don't want to share code because they want to hang on to whatever advantage they have over every other MUD.
It's too easy to start up a new MUD (unzip, compile, run), so each MUD wants to hold on tight to whatever advantage they have. 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).
-y
You could ask the same about any game genre: why are the free, open-source first-person shooters lagging? The large amount of work that goes into any game means that they're not as easy to develop. Due to the time they consume, it's difficult to pay the rent if you create them as anything other than commercial, closed-source products (and sell the result).
But don't forget that MUDS are also a dying genre. They are less popular than ever. Because of this, there are going to be fewer projects - open or closed working in the genre. MUDS need writers as the primary content authors. And good writers are not very likely to want to give their work away for free.
Finally, if you really want an open-source MUD: make one yourself.
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.
Why Is Free MUD Development Lagging?
Could it be because there's not a lot you can do once you've succeeded in mixing Wet Application Terminal Entry Responses with Dusty Iterative Response Technology?
Sort of like how those old text-based "books" disappeared shortly after the invention of the motion picture?
True story.
Mostly, I wish there were fewer MUDs. 99% of what is out there is the result of someone with little or no skill grabbing a copy of an open-source MUD, adding a few hundred poorly-written rooms to the world, changing the code just enough to make it crash hourly, and then advertising on Mudconnector or similar. Will these people have anything at all to contribute back to an open source project? No. They do, however, succeed in cheapening the experience that the average user has when connecting to something running that code.
-- Aaron
Aaron
- Game balance. It's very easy to code up a wham-blam-thank-you-ma'am sword that kills the toughest dragons in an instant. It's also very easy to kill the fun of the game by doing just that. There are a lot of subtle interactions that can come in and surprise you. Case in point: a certain quest (courtesy of a now-defunct MUD, which I ported to Shattered) uses a bottle to get the questor into a particular room, where a critical item is obtained. Unfortunately, that bottle could be used elsewhere in the game to obtain a bit of breathing space for healing and suchlike against tougher monsters. This was solved by letting you get in the bottle wherever you liked, but out of the bottle only in areas related to the quest the bottle was created for. (Yes, it's an ugly, cheap hack.)
- The game code, or "mudlib". Parts of this are generic (or could be): the code for logging in; the basic room object; the basic monster object; the basic weapon object; a base poison; wearable items; shops; etc. Other parts are specific to the game: town design, quests, guilds, and so on. Splitting these two parts, unless you're scrupulous about it from the start, is very tedious and annoying. Even if you're scrupulous at the start, it's very easy for code to wander off in random directions if you don't keep a tight check on it.
- Copyright and originality. It's very easy to copy ideas (and there are several cases on the 'Net of ideas popping up in other MUDs a few days or weeks after appearing in Shattered). It's a lot harder to come up with something original and fun.
Those are ones that spring up off the top of my head. Game balance, in particular, is a tricky one. Once a game-unbalancing item is out there, it can be tricky to recall, and it can be even harder to undo the damage it causes. Most of the time, we end up settling for just putting paid to the more blatent abuses of the system, and punishing (in-game, eg: by random deaths) abusing players.The other thing is, running a MUD is inherently political. There will always be morons out to spoil everybody else's fun; there will always be people who disagree (for whatever reason) with your view of things. Working on back-end code (logins, building blocks -- like the base room, base monster, etc) is very tedious without the chance to do something a bit more visible. Unless you really love it, you're liable to get burnt out relatively quickly.
And finally: the time factor. I have a lot less time to code than I used to, and my useful output on Shattered has dropped over the past year or two. This is partly a function of growing older, and is one of the reasons why, as other posters have said, you tend to get teenagers and suchlike in MUD development.
Speaking of the admin side of things, it's getting harder to attract new players. Partly that's due to the MMORPG syndrome -- people like to see pretty graphics, and MUDs take a bit more effort to understand, since you're just reading text -- and it's also partly because people just don't understand that the 'Net is more than just email and the WWW. But then, Shattered isn't in this game to have a massive player base online all the time (although it'd be nice!)
But, when all is said and done, the kick I get in seeing players exploring, for the first time, a new quest that I've just put in makes up for a lot of that. There's also a reasonable amount of social interaction, both for the players, and for the admins.
Anyway -- I'm rambling, and I need to get back to work. As I said -- just random thoughts.
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.
MUDs are a dying genre. They are swiftly being replaced MMPORGS.
Perhaps in market share, but the player base seems to be roughly constant (though I really wouldn't notice anything short of an order-of-magnitude shift in some direction).
The whole text-based game industry is being replaced, or has been replaced, by games with visuals because there is no good reason to restrict gameplay to text-only when you can spruce it up with immersive graphical environments.
Perhaps in theory, but there are a number of good reasons I can think of. The big one, the fact that the client interface is simple, is a huge deal. It means:
* MUD clients have a simple protocol -- the same text that you're looking at on-screen. It's *very* easy for players to customize clients to fit a given MUD's protocol (via triggers or regexes on prompts). There is no standard GUI MUD client. Such a thing is not impossible (and ever since VRML fell on it's face I've been wondering who's going to try next). I guess it'd be something like Neal Stephenson's Metaverse. Worldforge is one effort, but it seems far too ambitious to ever usefully come to fruition -- it's been six years in the making, and it's still not ready.
* Lightweight clients. Most games, even in this day and age, *still* suck down all the CPU time on a computer, and make no effort to avoid doing so. Some of this is because OSes provide crummy latency on sleep functions, some of it is because there's little reason to do so. If I'm compiling XFree86 in the background, I can play a MUD in the background without worrying about the CPU usage. Not true of Neverwinter Nights or Jagged Alliance 2 or really any other game on my computer that I can think of. Most games don't do this.
* Very powerful, mature clients. There are excellent MUD clients out there. They have triggers, aliases, macros, etc. It's much harder and less obvious how to do this with a GUI environment. This is the same problem that GUI and TUI apps face -- the reason all the "real" programs that a UNIX guru uses are text-based is because the text-based programs have a very powerful, simple way to tie the two together. After more than two decades of GUIs, we *still* do not have good, universal GUI scripting and user-controllable IPC mechanisms on the degree of the simple pipe that the TUI provides.
* Unobtrusiveness. It's easy to snap a MUD window into the background for a moment while chatting on ICQ or web browsing or something similar. Most 3d MMORPGs have, in the name of "immersiveness", made it standard to take over the entire display.
* Easier creation. If you took a look at all the MUDs, rooms, worlds, and mobs out there, you'd be amazed at the sheer amount of content. It's easy for anyone that can write and has a bit of imagination to sit down and make a MUD world. It's much harder to be a good skinner and modeler. I can write a description of a green-haired female elf wearing a green silk gown and with a burnished bronze waistband that glows red. I can certainly not skin and model one, not without expending many, many times as much time and effort. Hence, there is just *more content* out there for MUDs.
* Better handling of text. There is a lot of text in MUDs, and a fair amount in MMORPGs. I can read text in my scrollback-buffer-ized MUD client much more easily than I can with little bits of text floating in the air over character's heads.
* Spatial distance is a function of gameplay-related meaningfulness. In an MMORPG, I may walk for a minute to cover some random, boring green hill. In a MUD (or an TUI IF game), I may walk ten feet each step if I'm in a detailed city full of things to do, and cover ten miles if I'm in the countryside. The boring and the mundane are naturally filtered out.
* Natural logging. It's easy to keep a complete log (not just of messages) in a MUD. It's much harder to do so with a MMORPG.
* MUDs do a better job of completely taking advantage of their medium
May we never see th