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 borg@hebron.connected.com.
Some basic terms this manual uses:
driver
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.
mudlib
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 /std/room
(or /room/room
), /std/user.c
(or /obj/player.c
),
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
object
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 ]
Good Luck!