|
Toys in the Atticby Noah Gibbs As we stop ringing in the new year, I'd like to ring in a new column for all you MUD coders out there. This column will explore the state of MUD, MUSH and MOO coding in the free and open source community. We'll also make appropriate digressions to mention groups like Skotos and Achaea who drive the state of the art forward but don't make their code public. Whether you're writing your own codebase, making little edits of somebody else's, or just writing new functions to keep your builders happy, NeoArchaeology is meant for you. To do anything well, you should understand what other people have done before you. There's a name for being familiar with what other people have done before in your art or science: literacy. NeoArchaeology isn't about English Literacy -- it's about MUD Codebase Literacy. I'm going to start the column with a survey of the state of literacy in the MUD coding community. Later, the column will delve into ways to make yourself more MUD-literate, and examine some features of building new text games. Literacy and LiteratureThe programming circles that have the strongest open source projects tend to have a lot of cooperation. Think of the cryptography community, the Linux kernel community, the various groups doing CrystalSpace development. They all have a strong understanding of what competing efforts are underway. Each group has experts that cooperate with each other, usually in small groups, and usually in ways visible to the public. The groups have a good grasp of what's going on in their own community, and in others like it. What groups can you think of in the open source MUD community that have this same grasp on what's going on, and have competent people cooperating to spread understanding of their subject matter? I can think of only one. J.C. Lawrence's MUD-Dev mailing list is reasonably aware of what goes on in the MUD community. They represent a variety of camps within the MUD community, including Diku-based, LPMUD and a wide variety of independent efforts. They have 'elders' like J.C. Lawrence, Raph Koster and Matt Mihaly, who have written interesting MUDs and may even do MUD coding as their profession. They routinely discuss new and interesting MUD development ideas, and they have an archive of these discussions reaching back for years. Do yourself a favor and browse the list archives for a bit, just to get a feel for it. Unfortunately the list is hard to search through and there isn't any better-organized version of its contents. The easiest way to find out whether they've critiqued something like it is to ask the list again. That's inconvenient, wasteful, and provides no good survey of the many, many MUD ideas that have crossed the list. You can see one attempt at organization by the MUD-Dev members by looking at Agora. Agora is a lovely idea. But it shows vividly that only a tiny fraction of MUD-Dev's archive has been organized. And there's no better version available. There are good sites out there with forums and articles. The MUD Connector , Kyndig , MUD Planet and TopMUDSites are just some of the best, and there are many more. Yet they suffer from the same problems as MUD-Dev, usually more severely. Their forums don't always archive old messages, and the sites provide no good way to search for old topics, or browse organized lists of topics (no, viewing the latest stuff by thread doesn't count). The best posts aren't collected and linked on an index page. Instead, you have to look through many, many posts to find them, usually based on when they were posted. The articles, if they exist, are few in number, mixed in quality and come out irregularly. There are a few good, unified resources available. The MUDConnector is probably the best example. It's without peer as a listing of MUDs. Other sites like MUD Planet often get their own lists directly from the MUDConnector. There is no equivalent to this service for listings of MUD codebases, or for almost any form of MUD documentation or MUD code. Searching for such things is a scavenger hunt through many scattered sites, often defunct. There are indexes and listings of codebases, of course. There are various 'snippets' sites and the occasional actual site of documentation. But web pages go out of date and FTP sites go down over the years. Outdated links are the rule, not the exception, among MUD resource web sites. The MUD-Dev list's site fights this problem by mirroring all good resources, but few similar sites do the same. And while you can find a few interesting links on many different sites, there isn't any single, central site with a comprehensive listing. MUDs have existed for about thirty years. Yet in just three years Skotos has managed to accumulate the best archive of MUD and game-design articles in existence. And they used no old material. Skotos' writers are very good, but are they as good as everyone else in the industry put together? Can they best everyone else combined in far less than half the time? What does that tell us about how well we use and archive our old design notes, our old articles? Some of the common codebases are over ten years old, so where are our classic articles, our best works of design literature? Where is an older equivalent to the Skotos articles? Inertia and StasisNew ideas and major new features don't make it into major, well-known codebases very often. When I say that, I mean that new AI systems, new output systems, new systems of physics and weather are all rarely added to an existing codebase. A codebase will add features to catch up with other similar codebases, but rarely will something genuinely new be added. Note that I'm not counting the various individual MUD efforts adding code that never gets released -- only the large shared repositories like CircleMUD or Smaug or LDMUD or TinyMUSH. One reason is that writing a MUD codebase is a large task, and nearly everyone with a good idea begins it nearly from scratch rather than using an existing base. That's true in many fields of programming, but it seems to be especially universal among MUD programmers. In other fields the conventional wisdom is to start from scratch rarely, and normally only when the existing code is unusable. Yet MUD writers are routinely advised to write an entire new MUD, from nothing. Why? I'll discuss that in more detail in future columns. A hint: licensing of codebases, and scarcity of experienced, literate programmers both contribute. Literate CodersYou don't often see young MUD coders learning about what's out there before they sit down to write their own codebase. I first wrote that line several weeks ago. For the past few days, the DGD mailing list has been swamped with email from a fellow who has decided that the existing codebases for DGD are too complicated and intricate to bother understanding, so he'll write his own that works better. He seems to be a quite decent coder, yet he uses that reasoning. Am I the only one who sees that as a fundamental contradiction? New programmers set out to solve problems, to write a grand new codebase, and that's wonderful. But why do they read through only a little documentation, and only two or three existing codebases at most? I believe that the very biggest reason is a lack of existing literate coders. The various MUD camps (MUCK/MUSH/MOO, Diku/Merc/Rom, LP*) don't mingle much, and few people know a reasonable amount about more than one of them. It's hard to become literate in existing MUDs if you have no role models, no overviews and surveys, no people who can answer broad questions like "has anybody ever tried this before on a large scale?". It's hard to become a literate coder in a vacuum, having nobody to compare notes with. The lack of decent programming documentation for any existing MUD doesn't help. Reading source code takes a lot of time and effort, and few new coders understand just how important it is. So few of them bother to do it. At this point, it's obligatory to mention brash young programmers, considering themselves cowboys, who are going to revolutionize the world of MUDs all by themselves, and how they start over not because the existing code is bad, and not because they know nothing about it, but because that's their way. Balderdash. I've gone to school with those brash young programmers, worked jobs next to them, trained them in programming, worked with them on open source projects in 3D graphics and 3D modeling... MUD programmers aren't all that different a breed. They're just in a deceptively easy-looking discipline and have nobody really impressive to compete against. They are neither good software engineers (who is, when they start?) nor awed. They believe they can do everything that the existing codebases can do, given enough time. And sadly, they're mostly right. At least, if they had a decade going spare. Becoming LiterateIn the mean time, it's important to do what you can do to prepare yourself. Whether you're writing an entirely new kind of MUD or just adding a few features to an existing one, it's good to know what people have done already. It's important to know what resources are out there (imperfect though they may be), and use the good parts. It's very important to know who has written a tool you could use for your work. I'm going to try to alternate overview articles like this one with cheerier pieces about what a few MUDs are doing very right, and discussions of various features. So I'll talk about licensing in MUD codebases, but not for the next article. First I'll see you in two weeks when I talk about building MUDs, and estimating the amount of work you'll need for the next Great American MUD. [ #2: It's Based on Actual Math! —> ]
|
