The chapters of this manual are meant to be read in order. Starting with the introduction, going sequentially through the chapter numbers as ordered in the contents file. Each chapter begins with a paragraph or two explaining what you should have come to understand by that point in your studies. After those introductory paragraphs, the chapter then begins to discuss its subject matter in nauseating detail. At the end of the chapter is a briefly worded summary of what you should understand from that chapter if I have been successful. Following that may or may not be some sidenotes relevant to the subject at hand, but not necessary to its understanding.
If at any time you get to a chapter intro, and you have read the preceeding chapters thoroughly and you do not understand what it says you should understand by that point, please mail me! Clearly, I have failed at that point and I need to know where it is I have gone wrong so I can revise it properly. Similarly, if you do not understand what the chapter summary says you should, please mail me. If your mumud is on the MudOS intermud system, mail descartes@nightmare. Otherwise mail firstname.lastname@example.org.
Some basic terms this manual uses:
This is the C program which is the game. It accepts incoming sockets (links to other computers), interprets LPC code defined by the mudlib, keeps mud objects in memory, makes periodic attempts to clean unused mud objects from memory, makes periodic calls to objects, and so on.
LPC code which defines the world in which you are in. The driver of itself is not a game. It is just a program which allows the creation of a multi-user environment. In some sense, the driver is like an LPC compiler, and the mudlib is like a compiler's library (a very loose analogy). The mudlib defines basic objects which will likely be used over and over again by people creating in the mud world. Examples of such objects are
and so on.
area or castle
Specific creator coded objects which often use a feature of LPC called inheritance to make use of the properties of basic mudlib objects and turn them into specific objects to be used by players in the game
a room, a weapon, a monster, a player, a bag, etc. More importantly, every individual file with a .c extension is an object. Objects are used in different ways. Objects like
/std/living.c are inherited by
objects like monster.c and user.c. Others are cloned, which means a
duplicate of that code is loaded into memory. And still others are
simply loaded into memory to be referenced by other objects.
native and compat
these two terms refer to two popular flavours of drivers. Native mode mudlibs make use of on the design of LPMud driver 3.0 and later. You may have a 3.0 driver however, but have a 2.4.5 style mudlib. This is what is meant by compat mode. Mudlibs which are native mode are any for MudOS, CD, and LPMud mudlibs that are listed as native. Compat mudlibs are any LPMud mudlib before 3.0 and those which are 3.* compat mudlibs. I believe Amylaar's is compat. [ Not true, Amylaar supports native and compat mudlibs, Wunderland is native - Boing ]