The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!

So, you want to code a mud?

by John Patrick

Computer programming, or "coding" as it's called amongst mud people, is both a simple and complex procedure. It's simple in the fact that whatever you tell the computer to do, it does. How much more easy could it be?

But here is where the complex part comes in: How do you tell it what to do? That is the essence of computer programming: finding the correct way to describe to a computer what you want it to do.

The Sea!

A lovely picture of the sea.

But you do not just say:

When a character gets an object, put it in his/her inventory.

A computer won't like that. You see, it first off doesn't even understand the word When, let alone the rest of that line.

So how do you get a computer to do that? There's two ways to do it:

Write it in its native language (called machine language)
Write it in a human-readable language, and use a compiler or interpreter to create the machine language

Machine languages looks like:

5A027C03ED7C8C59070A32CF804AF64

Which means: Take the value pointed to by register 2, add to it the value in register 3, right shift that by 2, add 134, take that and add it to what's in register 7, using that and register 5, grab the value at that location and store it into memory address 64 offset into segment 04AF.

It's no small hint that of all the muds out there today, I doubt if one is written in machine language.

So, what you do is write the commands for the mud in a programming language, like C, C++, JAVA, FORTH, COBOL (Um, ok, not really), Pascal, Modula-2, Oberon, FORTRAN... your choice. Once you have written the program, detailing (in that language) how the computer should behave and you have compiled it, you tell the program to run and presto! you have a mud.

Great! you say. Now, what's this 'C' stuff I keep hearing about? Isn't 'B' or 'A' better? 'C' (as well as the other languages I listed above) is a human-readable set of instructions that, once compiled, become a program for the computer to run. A good example of 'C' code is:

char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}

Which, when compiled and run, prints the program above, exactly.

Ok, maybe that was a bad example. Here's what some ROM 2.4 code looks like:

    if ( can_see( victim, ch ) )
    {
        if (ch == victim)
            act( "$n looks at $mself.",ch,NULL,NULL,TO_ROOM);
        else
        {
            act( "$n looks at you.", ch, NULL, victim, TO_VICT    );
            act( "$n looks at $N.",  ch, NULL, victim, TO_NOTVICT );
        }
    }

This code says that:

if a player character (which we'll call ch) can see another player character (which we'll call victim) then
If ch is victim
then send "ch looks at him/herself." to the room ch is in.
If ch isn't victim (I.e. someone looks at someone else)
then send "ch looks at you." to victim and send "ch looks at victim." to the people in the room victim is in

Pretty simple, isn't it?

Great! you say. Can you teach me 'C'? Well, I hear this question quite a bit. And my reply is always the same: Get yourself a good C book, read it, look at the examples, find some well-written C code to study, write some small programs, write some larger programs, and then maybe, just maybe, you will be able to "code" on a mud.

The book I recommend is A Book on C by Al Kelley and Ira Pohl. It's a fantastic book (especially the new 4th edition) with plenty of examples of good coding style. When you are done with that book, do not dig directly into mud code. I speak from knowledgeable experience when I say that mud code has to be some of the worst C programming style and code I have ever seen. Sometimes it is good, mostly it is not. Remember that with mud code, it is likely that lots of people have edited the code, and their style and programming practices were far from being the same. Variable names, indentation levels, code reuse, function calls: mud code has plenty of bad examples of them. Start small, start easy, then work on mud code.

And maybe, just maybe, you'll code up a good mud.

And when you do, you'll know.

John Patrick is a Software/Hardware Engineer in the Chicago area. According to his wife, he spends WAY too much time on the computer. You can find him as "Reorx" on the DragonLance based mud Ansalon (ansalon.mudservices.com 8679).