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."
MUDs are a dying genre. They are swiftly being replaced MMPORGS.
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.
I have been pwned because my
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.
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.
Because MUDs are great! Sure, it's not the same as Everquest, but who said it had to be? MUDs have many advantages over graphical systems, and vice versa. They simply are not competing. What *is* happening is that the new generation of youngins' just doesn't have the mental capacity to work a MUD.
Damned kids these days.
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.
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.
One reason I think mud development is lagging, is namely that
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)
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?
They are the only games that you can play discreetly at work.
Buy Steampunk Clothing Online!
See subject, but yeah the license could be a little clearer.Still,clear enough that code theft can't be excused by ignorance.
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 LambdaMOO I think has some wierd Xeorox thing, but I think it's sort-of-free....
The World Wide Web is dying. Soon, we shall have only the Internet.
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
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.
The current system that is generally used to develop a new mud (download codebase, add new features/content, open to public) works much better than opensourcing every mud out there would. MUD's can't work without players. Stock muds are doomed to fail, the playerbase is too saturated.
In order for a mud to succeed, it needs to have something that the other 500 muds based on the same codebase don't have. If a MUD were to give away it's innovations, then 10 clones would spring up overnight. Eventually the playerbase would dwindle as the players moved from one clone to the next, and all 10 would fail. The opensource model is great, but it doesn't apply to everything.
I personally don't like MUD, rpgs or anything that takes too long. However, is it really hard to see why MUD games aren't doing that well. Sure, to some people they are really addictive, but there is no longer a reason to go text based. Most PDAs can do things far beyond your MUD game. A good star wars MUD that I played for a while is www.dforces.com. If you look around, there are quite a few MUD games out there.
- 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.
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.
I personally aggree for the msot part. I Code for a mud that's been up now since 98 (No cheap plug, you can find it easily enough if you want it) and most muds out there are startups by people who spend a couple weeks figuring out how to setup a mud then do a bit of dabbling in building/coding it up then it pretty much just sits. Problem isn't so much that they do this than it is that they usually take other mudders with them and for the most part the people involved get bored of mudding and go on to other things. As parent said they get a cheapened experience.
;)
But at the same time our mud is derrived from SMAUG So it's not all bad either
... although there may be fewer in the future.
:o) )
but also adventures have been reputed to be dead some years ago, but now a flood of new titles reaches the market.
the advantages of MUDs (usually free, playable with even the oldest machine and a 14.4 k modem, playable discreetly from work) will always attract some people..
i am a coder in a MUD myself, that has been open for over 6 years now, we have a solid base of players and there always logging on new ones (and some even stay for a loooooong time).
I think, its the same as with books: although there is radio, cinema and tv, books are still a big part of our daily life...
www.evermore.de (
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
telnet://stormgate.dyndns.org:2345
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.
MUCK is a codebase that forked off of one of the old MUD trees several years back, starting with TinyMUD->TinyMUCK->today's varieties of MUCK code.
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 web-server capabilities and such are always being implemented. We've tried sending pictures (.gifs/.jpgs), but that never really caught on with the players and required unique clients to support it.
But in the end, every game in a text-only environment is going to come down exchanging text between some kind of MU* server and some kind of user-end client. I'm not really sure how that experience would be changed at the core.
-Akari