Why Is Free MUD Development Lagging? 88
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."
Could it be because MUDs suck? (Score:4, Insightful)
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.
So with MUDs, someone decides to build one as a project and it gains a few players, but after a while everyone leaves and the MUD dies. Repeat every semester as some new college kid decides that he wants to build his own MUD.
So you end up with people inventing the same tech over and over, but never improving on the past projects because no one bothered to document their project the semester before. But also because the project is mostly intended to polish programming skills and try out some game design techniques, the game itself is hardly ever more than a proof of concept and it never captures the attention of gamers as much as Everquest or any other professionally-designed game.
Re:Could it be because MUDs suck? (Score:5, Insightful)
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
Re:Could it be because MUDs suck? (Score:3, Insightful)
But with so much game logic in scripts nowadays, doesn't it make sense to use a common, open source MUD platform, but distinguish yourself by the quality of the content and social network that your MUD offers? Lot of web sites serv
Re:Could it be because MUDs suck? (Score:2, Interesting)
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
Re:Could it be because MUDs suck? (Score:3, Insightful)
It's already been done, DGD, MOO, Cold, are quite nicely programmable generic platforms. It's certainly not technology stopping anyone, even if the languages are somewhat aging and others might prefer to program in, say, Python (I patched Python to make it a multi-user-safe runtime once, it's not horribly difficult). There's quite a few, for lack of a better term, "systemic" problems that keep
No, it couldn't be. (Score:5, Insightful)
Damned kids these days.
Re:No, it couldn't be. (Score:2, Insightful)
Re:Could it be because MUDs suck? (Score:5, Informative)
Sort of like how those old text-based "books" disappeared shortly after the invention of the motion picture?
Re:Could it be because MUDs suck? (Score:1, Insightful)
Movies aren't a technological advancement on books, they're a technological advancement on theater, and they have contributed to a major decline in live theater.
Graphical games are, however, a technological advancement over text based games, and they have already replaced ne
Re:Could it be because MUDs suck? (Score:5, Insightful)
You're wrong. There's one very good, and very solid reason that MMORPGs will never provide quite the same thing as text-based environments (specifically MOOs, MUCKs, MUSHes, etc): user-created-content.
Anyone who has a basic grasp of a language (and most people do -- though IM conversations sometimes indicate otherwise) can create whatever their imagination desires simply by writing some mediocre descriptive prose to get their message across. Short of sudden and marked advances in brain-to-computer interface technology, the artistically-challenged among us will never be able to as fully express our imaginations in a MMORPG, even one of the few that allows user-created-content. And the people who are excellent artists often find that it's a lot simpler and more convenient to simply write some description than do high-quality artwork or 3D models for whatever it is they're imagining.
So don't be so quick to abandon those text based worlds. There will always be some that survive and even flourish. Admittedly, the number of players has been thinning out significantly in the past several years, and we don't believe it'll stop anytime in the near future. But you'd be surprised how many new players we still continue to get, and how many reasons they have for staying.
Re:Could it be because MUDs suck? (Score:3, Insightful)
Besides, even the difference you are pointing to between MUDs and MMORPGs is gone now thanks to Second Life, where you can design pretty much any content you want.
Your error reminds me of a common error in the talk radio business - confusing 'lots of callers' with 'lots of listeners.'
Re:Could it be because MUDs suck? (Score:2, Insightful)
You completely forgot the fact that some things are simply not possible to "implement" in super-duper graphical games. Don't underestimate the role of the player's fantasy!
It's kind of like saying that books are a dying genre, because the industry is moving towards movies...
Re:Could it be because MUDs suck? (Score:2, Informative)
I'm an Imm. I won't shamelessly plug the tiny MUD I work on, but there is a lot that goes into running a MUD. Mostly the people that keep it working do so out of pure love for their particular little slice of the Telnet Protocol. I don't see MUDs dying, but I also don't see them increasing exponentially, either. The developers of MUDs are nowhere near as sophist
Re:Could it be because MUDs suck? (Score:3, Insightful)
How about this one [mooix.net]?
MUDs and MMORPGs: the word and the image (Score:5, Insightful)
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
Re:MUDs and MMORPGs: the word and the image (Score:1)
Care to name a few you like? I'm just curious.
Mud/Moo/Muse (Score:5, Interesting)
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 [secondlife.com]. It's quite a improvement. Of course, I still know people who play nethack and tradewars. So the classics do stay around.
Re:Mud/Moo/Muse (Score:2, Informative)
btech.no-ip.com 3049
btech.dhs.org 3030
http://btech.sourceforge.net/ [sourceforge.net] The main Source Forge site.
Here's a historical archive of Battletech MUSE info:
http://hpgx.net/btmuse/ [hpgx.net]
There's a few more out there running that I can't remember (like the 3056 Sim site), but 3030 is still very much alive, and the people there should be able to expand this list.
Duh. (Score:5, Insightful)
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.
Re:Duh. (Score:1)
You're wrong. That's all there is to it; it is not the case that you are right. You're wrong. That simply isn't true.
You're just wrong. Plenty of skilled people in all fields give their work away.
Re:Duh. (Score:2)
Re:Duh. (Score:1)
At least in my experiance. While I don't MUD, I MUSH/MUX and one can get the same number of players and the same quality of players today as you could 7-8 years ago.
Re:Duh. (Score:1)
When I say, cycles, it's been my experiance that new players come in waves during the year and there are dry spells.
I see new players all the time, usually ages 14-36, I run an Old West MUSH, and we're kind of controlling so our player base isn't big, but most everyone I talk to see the same numbers of people coming on as they have for years.
Theres as many players on the games I play, as were on the games
Re:Duh. (Score:3, Insightful)
Neither is the Linux kernel or many other open source projects. Furthermore, there are plenty of "total conversions" of existing video games that involve completely new models of everything.
No, the reason why you don't see that stuff is cultural and sociological: the kind of people who do that sort of thing ge
Re:Duh. (Score:2, Insightful)
Yes, let me list a few of the more memorable ones:
* Counter Strike - the most popular mod ever, a counter-terrorism mod ("modification") for the game Half-Life. The developers are now working at Valve Software, having released several commercial versions [ebgames.com]. Their follow up "Counter Strike - Condition Zero" is due on shelves next month.
* Desert Combat - the premier mod for Battlefie
Re:Duh. (Score:3, Insightful)
So? Many open source projects have been around for decades, not just 18 months. The ability to do development for the long haul is where open source has a huge advantage. And the different time scales are also why you are only now beginning
Re:Duh. (Score:1)
When you make claims like this its helpful to provide examples. Its also interesting that you compare all of one groups games versus only once genre. Arguement, failing. Straws...are all...that...are left...to grasp...
Re:Duh. (Score:3, Interesting)
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 migh
Re:Duh. (Score:2)
Another example...
TinyMUSH [godlike.com] is currently under active albeit leisurely development. David Passmore has been involved in the project for several years, and Lydia Leong even longer. Other members of the development team are also familiar names to those who've followed such for long.
The server is Open Source (Creative Commons Artistic License) and builds without modification on most *NIX-like systems (and I think with some effort Windows as well).
Re:Duh. (Score:2, Informative)
Re:Duh. (Score:3, Funny)
Re:Duh. (Score:2)
On the otherhand, there's not a whole lot of muds in Aardwolfs range as fa
Re:Duh. (Score:2)
Exactly. Apparently whoever had this little rant hasn't looked beyond the popular choices for MUDs; there are literally millions of open-source MUDs available, some even with GPL!
But hey, nothing gets in the way of being ignorant and asking other people to write code for you so you can run it without giving back to it.
Code theft is one major reason (Score:5, Interesting)
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 [t-online.de] for more information, as well as this one [sytes.net].
Re:Code theft is one major reason (Score:2, Insightful)
Re:Code theft is one major reason (Score:3, Informative)
The Medievia debacle demonstrates how fiercely protective coders are of code, even of code that isn't actually their own. (AxL, unless I am mistaken, has taken up a crusade on behalf of the DIKU team, not as a member of it.)
Upward
Re:Code theft is one major reason (Score:2, Informative)
Just FYI, I don't know anything about Axl (axl rose?) besides the post on rec.games.mud.diku, the Hall of Shame. I have contributed to CircleMUD in the past, which is why I am interested in this issue. The story asks why free MUD development has stalled - one answer, as the quote from one of the link
Time and money (Score:4, Interesting)
Re:Time and money (Score:2, Informative)
There are some quiet big and really complex MUDs I wouldn't call "small videogames". The core of these MUDs is mostly old and [t]rusty, but they have rich content. At least here in Germany a few big MUDs are running well and healthy, with new players signing on every day and a lot of people maintaining and enhancing these virtual worlds.
A few reasons (Score:4, Insightful)
muds in my experience attract young players and are ran by teenagers and college student. 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.
Also, muds are in competition with each other. We had short discussion about opening up the source to the mud I work on (The Northern Crossroads), and it was determined that if we opened up the source. We would lose our uniqueness among other muds. If everyone else used our features.
Another thing, they are just games. They aren't very important on the overall realm of things, why should we be devoting tons of time and energy in keeping something alive, when its not profitable or really useful in the end.
(Heh, not a very organized post)
Re:A few reasons (Score:3, Interesting)
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 o
Could it be... (Score:5, Funny)
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?
Muds still have one advantage (Score:5, Insightful)
Not all MUDS are dying (Score:5, Interesting)
Re:Not all MUDS are dying (Score:2, Interesting)
Re:Not all MUDS are dying (Score:3, Insightful)
It was a lot of fun while it lasted, and had some great systems that no other game has come close to mimicking. Their combat / magic systems were very impressive. But leveling was a chore.
No, really. Once you've reached a certain level, it became no more fun to level. Everything was just X creature with new name, in Y area. Roleplaying is much more fun in small groups with a DM: There's no need to keep up the insanely serious air without
LambdaMOO (Score:2)
Postscript: I have been looking at ColdC and can't find the stinking license anywhere. Maybe it's not open-source after all. Bah. And Lam
Re:LambdaMOO (Score:2, Informative)
Re:LambdaMOO (Score:2)
True, but LambdaMOO's server code is now hosted on SourceForge [sourceforge.net]. I think they require some sort of open source license for all hosted projects.
The LambdaMOO admins occasionally make dumps of the live Lambda database and give away [mud.org] the core bits.
Re:LambdaMOO (Score:1)
True, but LambdaMOO's server code is now hosted on SourceForge. I think they require some sort of open source license for all hosted projects.
Yes. And I believe that this is pretty much considered an open source license because it allows changes and redistribution. The only issue is that he wants you to send him your name and address (which can be a good idea, like for example if some massively horrible bug is found).
The LambdaMOO admins occasionally make dumps of the live Lambda database and give aw
MUDs aren't necessarily suited to be open source (Score:5, Insightful)
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
Re:MUDs aren't necessarily suited to be open sourc (Score:1)
GPL worries (Score:5, Interesting)
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:GPL worries (Score:1)
This is like apache making their binaries available, but not the content of their website. The key to making a decent wide-spread binary for a MUD is to allow most of the in-game systems to be changed via -scripts- - so you can change a DnD style MUD to a, for example, GURPs, style MUD.. without changing the actual binary, just some entries in a text file (probably a few equations in a script, too) somewhere.
The point would be to have a st
Re:GPL worries (Score:2)
Personal Opionon of MUD games (Score:1, Redundant)
Random thoughts from an occasional MUD coder. (Score:5, Informative)
- 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.
Re:Random thoughts from an occasional MUD coder. (Score:1)
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 reaso
With a Grain of Salt (Score:4, Insightful)
Amazingly enough a large percentage of the MUDers I run across are from the age group that is supposedly too graphically oriented to play text-based games. The allure of free, fun, and gaming still seems to hold some drawing power after all. Especially considering that word of mouth and the occasional banner on niche sites is the sum total of advertising for the games.
Some thoughts (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 [sourceforge.net]. 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 (Score:4, Interesting)
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
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... (Score:2, Interesting)
Maybe it depends on the MU* type (Score:1)
MUCK code continues to grow in the forms of FBMuck and ProtoMUCK. While MUCKs are typically used for more free-form RP (no automated monsters to hack), their scripting languages are powerful enough to code up a complete MUD if one actually wanted. I'm aware of a couple such MUCK/MUD projects that've been worked on.
With the above projects, advances like we