MUD’s Heritage to MMOs, a Short Sample
Readers who pay attention to commentators writing about MMO design or industry questions at large may be familiar with Raph Koster’s statement:
“MMOs have removed more features from MUD gameplay than they have added, when you look at the games in aggregate.”
Raph happens to be one of those many former MUDders who moved and populated the MMO industry, so he knows about these things. To the readers less familiar with MUDs, it probably bears expanding a bit.
First and foremost, let me immediately preface this by stating that in absolute terms, the statement is true, and I will give some examples of this later on. But my purpose here isn’t really to reminisce about the good old days where everything was better and the black colour of our telnet session backgrounds darker than the darkest black you find in MMOs (and gosh! you should see what we did with stone tablets before!). I think the statement makes a quite unfair and slightly twisted comparison, for several reasons.
A little bit of context first though. Coincidences being as they are, this year MUDs are entering their 4th decade. MMOs in the modern sense are in the middle of their second one. If you’re unfamiliar with the concept entirely, you basically would connect to a server through a simple telnet terminal and enter a world described in text (possibly with ASCII art and maps for some of them), interacting with text-based commands.
I came to MUDs relatively late, in the mid-90ies. In those days, there were already several hundred different games available, with a playerbase ranging from 5-10 people to a couple of hundred for the most successful ones. In terms of gameplay, the variety available was immense… provided you knew how to search for it (end of the 90es, the generalization of the web granted us online directories like the Mud Connector simplifying the process a lot). Most of them were completely free to play, and staffed by passionate hobbyists generally called “wizards”, which tended to be separated into builders (the guys and girls writing the texts for zones, areas, quests, monsters, NPCs and whatnot) and coders (the people tweaking the back-end to add features and functionality).
When I started MUDding, the field wasn’t entirely a vibrant ecosystem of infinite innovation, though. In 1989, one game released its code open-source, AberMUD, and from that source sprang three major families of codebases. The most widespread was to become the DIKU-family two years later, initially developed in Denmark by three passionate students to make a code which was easy to maintain and borrowed heavily from Dungeons & Dragons. DIKU sired a vast offspring of derived codebases with various improvements or additional features, but a couple of years down the road, DIKU and its descendants were also blamed in the MUD community for stifling innovation and hampering creativity.
DIKU and most of its publicly released descendants were written in C and became so-called stock MUD codebases. Provided you had some server hosting space and a C compiler handy somewhere, you could download one of those stock codebases, compile it and run it on your server space, and you had a preset world (most of it reusing the exact same newbie zone written by some nameless builder in the early 90ies) ready to play and expand upon. There was also an ever-growing collection of small code templates (“snippets”), which you could simply copy-paste into the codebase to add more functionalities, and many of these were so popular that they became almost a must-have for any new game.
The above also hints at the problem we saw back then. You could have a running environment up in less than 30 minutes and start building away. And by 2000, there were something like three thousand different MUDs listed on the MUD connector, of which 2/3rds were DIKU descendants… and the vast majority of them were only minor variations from each other.
At any given time you could find dozen if not hundred DIKU-descendant Dragonlance MUDs, for instance, which basically differed only in the way the Builders would describe them. Let me hasten to add that I don’t want to minimize that feat, though, because there were a lot of very gifted Builders with a knack to make each individual description unique – imagine if you will that you want to build a round cavern, which will be separated into, say, a 4×4 square (each is called, technically, a “room”, but I digress). That’s 16 individual squares, and a good builder would find 16 different ways to tell you that you were in a dark & damp cave. However, in the grand scheme of things, the same hundred Dragonlance MUDs would all feature the cave in some form or another, and since the codebases were mostly similar, the games were too.
If you look at the totality of MUDs, the variety in terms of gameplay is immensely rich and vast. At the same time, 95% of these were cut off the exact same cloth.
At the same time, MUDs were and remain the realm of near unlimited freedom. When a designer comes up with a new gameplay mechanic for an MMO, some of the very important worries to have early on will revolve on how this will translate into the graphical world, and that’s a huge element from the get-go. In a MUD for instance, a NPC wandering around moves from one room to the next – in technical terms the only thing you have to do is remove it from the description of the room it leaves and add it to the next one. On 3D you have to worry about pathing, line-of-sight, aggro radiuses and much more. And a bit further down the road, you will also have to worry about how the representation of that new feature will be brought to the customer (ie how it can integrate into an ever-increasingly bloated client). A worry completely absent in MUDs, since the client always remained a simple text terminal. Those are already limiting to an extent (especially if just afterwards you have to start worrying about how to prevent the ever-ingenious cheaters from abusing the new feature).
Near unlimited freedom: let me illustrate this through my own experience. I moved from player to staff (wizard had such a nice ring to it, didn’t it?) on a MUD stemming from a slightly different family than DIKU called LP-MUDs. In that particular family, you basically had one C-written component called the driver which would create a virtual environment in which your MUD was run (for today’s techies we’d now call that a Virtual Machine), the MUD itself being entirely coded and run off a codebase (called the mudlib) inside that virtual environment. The mudlib was described in LPC, a custom-tailored script language based on C with a couple of very nice tweaks allowing novices to start working on it relatively easily.
In layman’s terms, the mudlib was based on an inheritance system which gave a builder / coder a set of templates which he then completed with descriptions and other amenities. As an example, you could picture the following situation: there was some code in the mudlib which held the template for generic objects. This template would just give you basically the means to add text description to a new generic object. But then below that, you could have a “child” piece of code which inherited all the features of the generic object and which was called an NPC. The NPC had the code to give it text descriptions, but also some code allowing interaction with it, talking to it and so. In turn, a further descendant template would add the functionality to turn it into a killable monster: combat, death and decay. So if I wanted to create a new monster, I’d a new file, tell it to inherit the features from the “monster” template, and I had something I could add a description to, give stats and eg skills or levels to, some loot if it were lootable, and there I went, I now had a piece of code describing a little rabbit, and the last thing I had to do was to attach it to a room so that whenever a player visited, the driver would spawn either a live version of the rabbit I made, its corpse or its bleached bones.
If someone had created some code template for skinning, I could tell my rabbit to also inherit the features from that particular template, and now you could also skin the dead remains of the rabbit and get a specific item, a rabbit fur, into your inventory.
What if I wanted new gameplay features, though? Well, as long as I was merely adding to the mudlib, only my imagination (and my coding skills) were the limit. On the MUD I was coding for, innkeepers could offer you a bed, some drinks, and take your money in exchange for that. I found that a bit bland, so I wrote a code template which gave innkeepers not only some conversation, but also some activities (making them shuffle around from time to time, serve beers and meals, remove plates and so on). A bit later on, inspired by a description of a bot called Julia, and knowing that there were 2-3 inns where players liked to hang around and socialize, I added some code which basically let innkeepers pick up /say conversations, sample those, and later give these back as gossip “I heard player X say such and such”. Which actually led to some hilarious side-effects akin to what you get nowadays when you say something in the wrong chat channel.
From that, I moved to a new MUD which was in its early development stages and started thinking that the only generic of gameplay available to the average player was that of a fighter (even if it was actually a magic user). Oh, there was to be professions and all that, and you could accumulate wealth by killing stuff, completing quests and selling drops or stuff you crafted, but you couldn’t build a career as a merchant and impact the MUD that way. So I started working on a system where each of the game’s nations had it’s own currency, which could be strengthened or weakened depending on how much players would buy and sell goods around and convert currency. This lead to giving merchants code which would change the inventory of goods they would offer depending on the current economical state of their nation. In turn, an impoverished nation couldn’t very well have roads and buildings in a pristine state, could they? So this led to writing some code which would change the descriptions on village and city areas depending on their nation’s economy.
And from that, I thought, heck, you could expand that to monster areas as well. In my own little corner I started designing the Hive code – basically a template spanning a large area which would generate eg some goblins in a forest who’d start gathering wood and stone, and build some huts. After a while, they’d grow their little hamlet into a village and build some defences, all the while gathering more resources and food and whatnot in an ever-increasing radius while their population expanded. And when players came around to hunt or work wood or pluck daisies for their alchemy, they suddenly found themselves at odds with a strong goblin stronghold which wasn’t there a couple of days ago, and the Hive would also handle the collapsing of the same settlement if the players were victorious and burned it down.
As I’ve said often, I’m not really bright. It took me the best part of another decade to realize that the wheel I had just reinvented is the core upon which part of an RTS’ AI is built.
The key thing here though isn’t to brag about my leet coding skills (I actually sucked at it and took way longer than what was reasonable), what I’d like to point out was that the staff was 5-10 people, and if one of us had an idea, he could just go ahead and write it. We had a semblance of QA process (we actually called it QC, Quality Control) which simply had one of our peers review whatever we’d code trying to act as if he were a player and then check for bugs and so on.
There may very well have been a vision guiding the overall development, but beyond that, at the very least as long as you were not modifying or changing the core mudlib but adding to it, if you had an idea you knew how to code, you went away and did it.
No limits, no constraints, no budget, no project framework, no deadlines, no nothing. If you didn’t like it, you moved to another MUD or started your own. In a purely free environment, it was the exact same for the players. If you didn’t like something, you either managed to join the staff and do it better, you moved on to a different place, or you started your own MUD.
In essence, MUDs were and are like sandcastles (and coming back from a sea-side vacation, I’m now a journeyman sandcastle builder, so I know what I’m talking about). The medium allows for an immense freedom and creativity. But could you live in a sandcastle you built? Can you translate it into proper brick-and-mortar at the drop of a hat?
In this sense, I think Koster’s statement, while literally true, is a bit unfair, because he’s comparing 3’000+ oranges to a couple of dozen apples. Yes, they are all edible fruits, and share some additional common traits, just as a sandcastle and a brick-and-mortar building share common traits, but they are also very different beasts, if only because MUDs have very little which stands in the way of almost unlimited creativity and allow for endless experimentation, whereas today’s graphical MMOGs have a long series of constraints, starting on the technical side, through scalability to financial sustainability. And to paraphrase Richard Bartle, WoW currently acts as a giant black hole in the industry due to its sheer size and financial success. The very second a studio starts thinking of making a MMO, you have an enormous blue elephant in the room which distorts everything around it, from the financial aspect to customer expectations, defining not only a standard in terms of polish but also what kind of features, gameplay and functionality will go into a new game either in continuation / expansion on what WoW has, or in opposition to WoW’s own.
The real problem is that all together, the whole industry is still quite young, and as a whole, having one single major and towering juggernaut emerging when it did without directly comparable competitors does and will continue to crystallize things around it for a couple more years. If in the post-WoW era, several fundamentally different titles come to a place of prominence, a new round of innovation and creativity can take place. If there will be just another WoW-alike? Probably not so much. Still, in two more decades, I think we can look forward to having much of these features (and more) which were present in MUDs to be returned in tomorrow’s MMOs, and also much more. All it needs is one game to manage sizeable commercial success while breaking with a couple of fundamental design “need-to-haves” which WoW has turned into a de-facto standards. After that? The sky will be the limit, again.
Don’t believe me? Look at the movie industry, over a century old. Take the superhero flick genre. After the first Superman movies in the 70ies, no real blockbuster until Tim Burton revived the genre with his two Batmans. His immediate successors pretty much killed the genre in the late 90ies, and I believe the first X-Men and Spiderman in the early 21st century were quite a tough sale to get a producer. And in this new wave of superhero movies, who would have thought much of the chances of picking up the Batman franchises after the state it was in in the 90ies? Yet Batman Begins and the Dark Knight are undeniably huge commercial successes and bring perhaps just as much novelty to the franchise and the superhero genre in general than Tim Burton did before.
What the movie industry teaches us is that a specific blockbuster creates a bubble around it which will start restricting creativity and innovation for a time, until its final descendants become so bland and frankly bad that no more money is available at all. And then comes a new vision, fresh blood, another approach, and the next bubble starts around it, until this one, too, degenerates to a point where the public does no longer follow. During that last stage, creativity starts anew and explores new directions.
How long will the WoW bubble last? Difficult to say. Contrary to the movie industry, MMOGs are still a very young market and it hasn’t even scratched the surface of what it can do. In a year or five, something else will emerge on the scene, broaden the horizon, unlock new venture capital to encourage creativity rather than conformism, and a new cycle will start tapping into much more of the MUD’s incredibly rich heritage of features, functionality and gameplay.
And the good thing is, if you’re actually a simple player enjoying WoW or AoC or LotRO today already, the best is yet to come.
