|[ LiB ]|
Aside from all the communications work, there are generally three parts to a MUD game engine. Some people say two and some say four, but I've found that the three-part system makes the most sense.
The physical level of a MUD is the level of the game that controls the physical aspects, such as the existence and movement of items, characters , rooms, and so on. Basically, anything that can be represented as a physical object is defined at the physical layer of the MUD. Objects defined at this level are typically referred to as entities .
The logical level of a MUD controls what happens to the physical level. Characters need to make decisions, items perform tasks when acted upon, and so forth. This is the part of the MUD that controls what a character does when attacked , or when given an item, for example.
The data level of a MUD is closely related to the physical level. This is the level of the MUD that defines all the physical entities in the game (as opposed to the physical level, which merely controls them). For example, whenever you load up a map into the physical layer, the map is loaded from the data layer.
Different MUDs implement these layers in different ways. In the very first MUDs, way back in the bad old days when every computer language was a compiled language , all these layers were stored in the MUD code itself. Everything (and I mean everything ) was inside of the compiled code, and you couldn't change anything until you went into the code, modified it, recompiled, restarted the MUD, and then re-ran it.
Obviously having such interruptions is bothersome to the players of your MUD. There's not much sense in having a simulation of a world that needs to be shut down all the time. After all, the real world doesn't shut down (at least you had better hope not... makes you wonder what happens when you sleep...).
The first layer that was promoted to the idea of being flexible was the data layer. Why the heck should you put your game data inside the actual code? Isn't it a better idea to separate out that data and put it into a file, and then when the MUD runs, you can load that data from the file, or reload the data when it changes? The idea of coding data right into your game is so ancient that I honestly can't remember if I've ever seen a MUD-like game that does that.
Then came the idea that you could have a flexible logic system. Most MUDs today don't have a flexible logic system, but they're gaining popularity quickly. The basic idea is to separate out what controls objects into a scripting language, such as Python, LUA, or even something like LISP.
Of course, you could take this idea even further and create the physical level of the MUD in a flexible interpreted language, which would allow you to make a flexible world with new types of entities that could be added any time you wanted. This is the least common kind of MUD. Almost always, the need for a flexible physical layer just doesn't exist. Once you've got all the basic entities sorted out, you almost never need new kinds.
There are a few MUDs out there that implement this level in a flexible manner, however. Most people consider them to be MOOs or MUSHs, but as I said earlier, that really doesn't matter much.
In this book, I'm going to take you through the construction of two MUDsthe first is called the SimpleMUD . This is a very simple MUD (the name doesn't lie!), but it's a good start for understanding how you can combine a simple data system with a networking reaction system. In the SimpleMUD, I use C++ exclusively to code the physical and logical aspects of the game, and simple ASCII data files to store the data level of the game.
The source for this MUD can be found on the CD in the directory /SimpleMUD, and sections of it are presented in the Demos for Chapters 8, 9 and 10. If you're interested in jumping in right away and know what a Telnet client is and how to use it, take a look at the version running on my Linux shell at telnet://dune.net:5100. It's likely to be deserted however, since there's not much you can do in that MUD. Everyone will probably be more interested in the second MUD.
The BetterMUD is much more complicated and builds on the concepts learned in the SimpleMUD. It implements a flexible logic layer using the Python scripting language. If you don't know any Python, don't worry. Not only is the language very easy to pick up, but I have a whole chapter dedicated to teaching it to you (Chapter 17).
The BetterMUD version on the CD is actually very sparse, and doesn't do much "out of the box." This is because the BetterMUD is a very flexible MUD engine that supports reloadable logic. You can essentially change how the entire game functions while it is running, and because of this I don't want to force you into any single type of game. In the SimpleMUD I force you to use a specific economy, a specific battle system, and so on, but those aspects of the BetterMUD are completely flexible. For example, if you don't like the classic time-based style, you may decide to implement some sort of turn -based combat system; and that's just one example of what can be accomplished.
I'll have my own personal version of BetterMUD running on my Linux shell as well: telnet: //dune.net:5110. Feel free to drop in.
All the scripts I add on to my own version will be freely available to download from my website, http://ronpenton.net/MUDBook/. If, for some unforeseen reason, I don't have my MUDs running at Dune.net anymore when you read this, be sure to check my website for information on where I've moved them.
|[ LiB ]|