Slashdot Mirror

...about MUDs.

First off, the basic premise of this post is wrong. MUDs were always a niche type of thing. There were a few 10 years ago when the Internet was small. There are a lot now that the Internet is big. It's hard to say which has grown faster.

Of course, there are many more long-running MUDs today than there were 10 years ago. When a favorite goes dark, it doesn't mean they are fading away (although it may SEEM like it at the time). When Cats closed, it didn't mean Broadway theater was dead.

More relevant question: Why haven't MUDs broken out of their niche?

Answer #1: They did. EverQuest was an LPC MUD with a graphical front end pasted on it. Some MUDders see EQ as a diabolical competitor leeching away the potential users of "true" MUDs; others see it as the logical next step.

Answer #2: The amount of creativity to keep a MUD lively doesn't scale well. The number of people people creating new content for MUDs eventually defines the size of the niche which will be supported by their creativity. The FaerieMUD Consortium has an interesting solution to this: using the creativity of players themselves to generate new content for their MUD. This is an extension of the long tradition of wizards, immortals and promotion to coders in the MUD community. We have been working on this for a long time, but it is not quite there yet.

Another interesting question: Are there common problems faced by all MUD-coders for which pooled solutions are possible in Open Source?

Two obvious places for this are: A general-purpose backend server for hosting MUDs (the ability to scale might be nice, too); and a graphical front end.

The MUES Project on Source Forge has recently posted Alpha code for the first of these. Several projects have code up on SourgeForge for the second. It's my personal opinion that MUDs will never break out of the niche until these types of problems are well-solved by Open Source software. It's also going to be important to do it right. I can say from personal experience that getting all the things people are looking for in the next-generation MUD is no simple task. The discussion in this paper on CME (Coolest MUD Ever) is very informative.

...and say, "Developers should write their test suites BEFORE they write their code."

We have a fairly large open source project with contributors coming in and going out all the time (well, not a lot going out; but any number is a problem there). Our experience shows that if you can't write a test suite you're not ready for anything more than a crude prototype. The problem with test-after-coding regimes is the testing gets short-circuited. You've already got working code. You "know" it works. You're just proving it works. So you test the obvious stuff that proves this.

Since we have instituted this policy, coding efficiency has actually improved. Coders who have tried to devise a complete set of tests have formalized their understanding of the requirements in a sense which the most complete requirements doc will never do. We include the test suite in CVS. Nobody commits until their update passes the entire test suite. This results in an enormous (but complete) test of everything done so far. But you can't imagine the thrill of seeing your patch pass that many tests the first time.

All of which is completely separate from what a QA process is for.

...this?

...except you can substitute Ruby for C#.

Our Documentation Index page gives a basic list of the areas we have documented. The General Philosophy describes our philosophical outlook, while Core Concepts describe the main ideas which are needed to understand coding FaerieMUD. Our engine is based on the same Design Patterns you're describing. It is open source and is basically finished and tested.

The game engine is known as "The MUES Engine" (pronounced "muse") for Multi-User Environment Server because it allows many users to simultaneously interact with one or more environments each being served by one or more servers. When MUES is being used for serving MMORPGs or MUDs, the environments are usually called "worlds" but MUES does not make any assumptions about their nature. They can be chat rooms or workgroups for collaboration or whatever.

The MUES code is pretty well documented, so you may even be able to use it as pseudocode. (For that matter, it may be possible to use it in Ruby since it doesn't make assumptions about how the objects which are served to it are created.)

Good luck, and let us know if any of your ideas look like they'd help us.

All of which should not be taken as disagreeing about any of the other advice to look at WorldForge or MUDdev lists or whatever.

...except you can substitute Ruby for C#.

Our Documentation Index page gives a basic list of the areas we have documented. The General Philosophy describes our philosophical outlook, while Core Concepts describe the main ideas which are needed to understand coding FaerieMUD. Our engine is based on the same Design Patterns you're describing. It is open source and is basically finished and tested.

The game engine is known as "The MUES Engine" (pronounced "muse") for Multi-User Environment Server because it allows many users to simultaneously interact with one or more environments each being served by one or more servers. When MUES is being used for serving MMORPGs or MUDs, the environments are usually called "worlds" but MUES does not make any assumptions about their nature. They can be chat rooms or workgroups for collaboration or whatever.

The MUES code is pretty well documented, so you may even be able to use it as pseudocode. (For that matter, it may be possible to use it in Ruby since it doesn't make assumptions about how the objects which are served to it are created.)

Good luck, and let us know if any of your ideas look like they'd help us.

All of which should not be taken as disagreeing about any of the other advice to look at WorldForge or MUDdev lists or whatever.

...except you can substitute Ruby for C#.

Our Documentation Index page gives a basic list of the areas we have documented. The General Philosophy describes our philosophical outlook, while Core Concepts describe the main ideas which are needed to understand coding FaerieMUD. Our engine is based on the same Design Patterns you're describing. It is open source and is basically finished and tested.

The game engine is known as "The MUES Engine" (pronounced "muse") for Multi-User Environment Server because it allows many users to simultaneously interact with one or more environments each being served by one or more servers. When MUES is being used for serving MMORPGs or MUDs, the environments are usually called "worlds" but MUES does not make any assumptions about their nature. They can be chat rooms or workgroups for collaboration or whatever.

The MUES code is pretty well documented, so you may even be able to use it as pseudocode. (For that matter, it may be possible to use it in Ruby since it doesn't make assumptions about how the objects which are served to it are created.)

Good luck, and let us know if any of your ideas look like they'd help us.

All of which should not be taken as disagreeing about any of the other advice to look at WorldForge or MUDdev lists or whatever.

...except you can substitute Ruby for C#.

Our Documentation Index page gives a basic list of the areas we have documented. The General Philosophy describes our philosophical outlook, while Core Concepts describe the main ideas which are needed to understand coding FaerieMUD. Our engine is based on the same Design Patterns you're describing. It is open source and is basically finished and tested.

The game engine is known as "The MUES Engine" (pronounced "muse") for Multi-User Environment Server because it allows many users to simultaneously interact with one or more environments each being served by one or more servers. When MUES is being used for serving MMORPGs or MUDs, the environments are usually called "worlds" but MUES does not make any assumptions about their nature. They can be chat rooms or workgroups for collaboration or whatever.

The MUES code is pretty well documented, so you may even be able to use it as pseudocode. (For that matter, it may be possible to use it in Ruby since it doesn't make assumptions about how the objects which are served to it are created.)

Good luck, and let us know if any of your ideas look like they'd help us.

All of which should not be taken as disagreeing about any of the other advice to look at WorldForge or MUDdev lists or whatever.

...except you can substitute Ruby for C#.

Our Documentation Index page gives a basic list of the areas we have documented. The General Philosophy describes our philosophical outlook, while Core Concepts describe the main ideas which are needed to understand coding FaerieMUD. Our engine is based on the same Design Patterns you're describing. It is open source and is basically finished and tested.

The game engine is known as "The MUES Engine" (pronounced "muse") for Multi-User Environment Server because it allows many users to simultaneously interact with one or more environments each being served by one or more servers. When MUES is being used for serving MMORPGs or MUDs, the environments are usually called "worlds" but MUES does not make any assumptions about their nature. They can be chat rooms or workgroups for collaboration or whatever.

The MUES code is pretty well documented, so you may even be able to use it as pseudocode. (For that matter, it may be possible to use it in Ruby since it doesn't make assumptions about how the objects which are served to it are created.)

Good luck, and let us know if any of your ideas look like they'd help us.

All of which should not be taken as disagreeing about any of the other advice to look at WorldForge or MUDdev lists or whatever.

...of exceptionally bright kids (no, I'm not bragging on my genes, they were others' biological children), I have a few insights to offer.

First of all, there is some risk of burnout. Don't concentrate too much on beating academic milestones. This is apparently where this kid excels, but grades and proficiencies may be an inappropriate set of milestones. They can give a combination of a false sense of success and invincibility and a learning style fairly inappropriate to the real world. (I've never had an employer who paid me to take tests. But the daily work I looked down upon as a student was a much better preparation for real life than any test I ever studied for.)

One of the most difficult things for the talented to learn is how to try hard. It's one of the most important lessons around, but the gifted (in sports, intellect, whatever) often have difficulty learning it.

Just think of Ralph Sampson and Slick Watts (sorry about the sports analogies). Sampson was born with a body and coordination which gave him extraordinary opportunities. Slick Watts had the wrong body for basketball, under six foot and then he got some rare disease at 13 and lost all his hair.

But Watts learned something Sampson never did: how to try harder than everyone else he ever met. It's not that the talented cannot learn it (Bill Russell and Michael Jordan spring immediately to mind). It's just a little harder for them.

How should this translate into "tutoring a prodigy"? Many ways: throwing that football around might help, if he's interested; but the key is taking his interests to the nth degree.

Suppose he's asking questions about assembler. Show him how Alan Turing conceived of a programmable computer from mathematical concepts put forward by Goedel. Show him how machine-language derived from the precepts of Principia Mathematica and David Hilbert's famous problems for the 20th century. (If he likes fiction, The Crytonomicon is a good introduction to how Turing conceived of computers long before the technology to build them existed.) Tell him why compiler theory is emphasized in CS programs, despite the fact that so few of us end up designing compilers. Show him how Turing invented computability theory before there were computers or even transistors or microchips. Show him a simple problem he can understand which is NP-complete.

Suppose he's interested in JAVA. Get him started with some good tutorials. Then tell him what object-oriented programming is. Show him the UML. Explain why somebody would want to invent a whole new way of thinking about programming (procedures versus objects). Ask him what thinks might come after OO. Then point out that some languages have a static view of object-oriented-ness, while others are built to change if the theory changes. Ask him if he wants to accept somebody else's paradigm (Bill Joy is a good choice if you want to copy) or if he wants to define the new paradigm. Then tell him to type "aspect-oriented programming" (including the quotes) into Google. Show him Ruby. Ask him to make up a new paradigm just for fun. Then help him try to implement it in Perl (which has a dynamic OO model which forces you to redefine what you mean by "object-oriented" every time you write a program).

Suppose he's interested in physics. Have him read Aristotle's "Physics" and Newton's Principia,. Then give him Feynmann and Einstein. When he thinks that's too easy, show him Aristotle's "Metaphysics." Tell him who the Vienna Circle was and how they sought to complete science. Then give him Ludwig Wittgenstein's Tractatus. When he decides that's the cat's meow, show him how Wittgenstein renounced all that in Philosophical Investigations.

Suppose he's interested in AI. There's plenty of material on the current state of the art which tries to make it easy to understand for the beginner. Show him the Santa Fe Institute's web site (www.SantaFe.edu). Get the NOVA video on chaos theory. Then tell him not all chaos theorists are fully accepted by most scientists. Get him Complexity: The Emerging Science on the Edge of Chaos and Dynamic Memory. Teach him neural nets, then point out how it failed to live up to its promise. Ask him if he thinks that's an inherent limit of the theory or that it's caused by an inadequately developed idea. Then show him genetic programming. Then take him back to Descartes and show him the mind-body problem.

Suppose he's interested in games. Teach him to program them. There are plenty of open-source game-design projects (my web site is www.FaerieMUD.org) where he can find any level of challenge in any kind of game he likes.

Suppose he's interested in the election or social problems or whatever....

It doesn't matter. Whatever the interest, show him that he can take it to some limit which will probably exceed his grasp. Let him fail, even if you have to show him problems which have baffled mankind for millennia.

There are two keys: start with his interests and take it to his limits. Then bring him back and show him that by trying very hard he can make real progress in places where he will make a difference.

Good luck, to you and to him.

...is because such a high percentage of Linux users are gamers, not because there is particularly good reason for Linux games to be written.

I know this will probably trash my Karma, but I would suggest that the one thing Windows is good at is games. I'll bet many /.ers are much like me: We have an Athlon at home which runs Win98SE which is essentially a dedicated game box, while at work we use a real operating system.

I'm old enough to remember when IBM held back the technical development of the PC because they didn't want to be seen as a "game" machine and ruin their relationship with business. Unfortunately, this psychology would never occur to most Linux users, even though it might be a much better argument to use with suits: "Oh, sure, I use Windows for games because that's clearly what it was designed for. But for real computing on a network, I need an operating system which was designed for that environment, like Linux."

Unfortunately, most Linux users are gamers. So this kind of thinking never occurs to them. But to the suits the idea they are using a toy really might affect their decision-making. Of course, to geeks like us a computer is a toy, even if the game we are playing is WebSite Tycoon ][, the game of getting up a high-volume site before the suits promise the customers something we can't deliver. ("Blast that marketing dude before he talks to the CEO!")

I say this even though I spend my spare time working on an open-source game called FaerieMUD, which (like most MUDs) is fully Linux-compatible.

On a couple of slightly off-topic notes: Am I the only one who has stopped reading Gamespot since they did that terrible makeover? And when are we going to have a smackdown between Robyn Limos and Robert Lemos over the trademark on their names?