<h3>Chapter 1 - Introduction</h3>
<hr size="1">
<a name="1.1"><p><strong>1.1 What else is there?</strong></p></a>
<p>
If you are ready for this textbook, then you have probably answered this
question for yourself. You should know well the material in <i>LPC Basics</i>
and <i>Intermediate LPC</i> and have practical experience with building areas
on real LPMuds and seeing them put into real LPMud games. This textbook is designed
to take you from winging solutions to more global mudlib problems to being able
to design and implement your own MUD.
</p>
<p>
Like the other two textbooks which came before it, <i>Advanced LPC</i> is not
designed for picking apart which sections you want to read now. It is a
step-by-step textbook designed to take you from being an experienced area
coder to being a knowledgeable MUD builder. The topic is basically mudlib
analysis, design, and implementation. Implementation is the only part of
that which relates specifically to LPC.
</p>
<p>
To the question, "What else is there?", this book tries to address the
issue of starting your own MUD and/or administrating a MUD either of your
own or with someone else. Even if you have no intention of doing such a thing,
however, you should find much of what is said in this textbook to be valuable.
</p>
<hr size="1">
<a name="1.2"><p><strong>1.2 Starting your own MUD</strong></p></a>
<p>
Few MUDs last more than a few weeks or a month. Of those MUDs
on any given mudlist, only a few are active and have been around as long as
a year. Only less than a dozen have been around since year one of LPMuds.
People often find out that just one month is not nearly enough time for
building a MUD.
</p>
<p>
The short answer to the question "How do I start my own MUD?" is ftp a
driver and mudlib, install them, and there you are. This answer does a serious
disservice to those few MUDs who have managed to create a lasting and
enjoyable game for people to play. If it were that easy, we would see many
more long-term MUDs, and others would not shut down before they have
even attracted their first player.
</p>
<p>
What do you do with the MUD after you have installed it? No matter how
complete the mudlib, none comes with a complete set of areas which makes a
MUD unique, and none comes with players ready to play. Only LPMud 2.4.5
can be played by players straight out of the box, and that owes much to
its simplicity. Just because you can play it out of the box does not mean
anyone would want to.
</p>
<p>
There are 5 steps to building a successful MUD:
</p>
<DL>
<DT><A HREF="#1.3">Define your team</A>
<DD>Too often, an individual starts a MUD just because they want to run their
own MUD. No matter which mudlib you use, building a MUD is a cooperative job
which takes a lot of work.
<DT><A HREF="#1.4">Analyze the situation</A>
<DD>You need to determine what talents you have in your team, and what the
goals you all have in building the MUD. The questions start as simple as "Do
you want to build a fantasy or sci-fi MUD?" to as complicated as "Who decides
when to banish a site?".
<DT><A HREF="#1.5">Design the MUD</A>
<DD>Three steps in, and you have not yet touched any code. Once you have a
team and something to build, you need to design the how the pieces of the
puzzle will fit together.
<DT><A HREF="#1.6">Implementing the design</A>
<DD>Now it is time to code, but only for the main development team. By this
time you have a base mudlib chosen and a clear goal of what you need to code.
<DT><A HREF="#recruiting">Recruit creators to build areas</A>
<DD>You don't need to finish step 4 before getting people involved, but the
actual objects coders will use in building areas need to be fairly stable.
</DL>
<hr size="1">
<a name="1.3"><p><strong>1.3 Team Building</strong></p></a>
<p>
No matter how good you think you are, you cannot possibly accomplish the
tremendous task of opening a MUD on your own. It simply requires too many
diverse types of talent, types often in opposition to each other, and the
whole big picture is simply too overwhelming. Certain aspects of MUD
building require great architectural skills, which often are in direct
contrast to the detail skills other parts of MUD building require. Building
a MUD thus needs to be a team effort; and since everyone is generally doing
this for the sake of a good time, they must each feel a sense of ownership
in the MUD.
</p>
<p>
A common attitude among people out to start a MUD is the "I want to run MY
own MUD" attitude. Any new MUD, however, needs to start as a group of people
with a well defined power structure working together to create a well-defined
virtual reality. If you are out to build YOUR MUD, then you will fail. No
one else wants to code your vision of what a MUD should be. And that
feeling in others will be compounded if you cannot command the respect
in experience and MUD knowledge which would fit the position you are
trying to draw for yourself.
</p>
<p>
Sometimes MUDs start up as a reaction to political problems with other MUDs.
These MUDs tend to have exactly the opposite problem in that they
attempt to create a completely egalitarian society run by committee.
</p>
<p>
Each individual needs to have a sense of ownership in the MUD, something that
they can point to and say "I did that". Other need to know where the buck
stops when a problem is encountered. Committee leadership fosters none of the
above. You therefore need clear accountability in an individual for given
types of decisions, and those individuals need the security of knowing the
other administrators will stand by their decisions publically.
</p>
<p>
Who should be in your team? Your team should be almost entirely people you
trust. You must be able to deal with disagreeing with them and having their
decision be law. If you are constantly second-guessing any person, then
they will not be happy with you, and you will be almost as bad off as if
you were trying to do the whole thing alone. Look around on the MUDs you
currently create on. Find others who have topped out at the experience they
can gain from building on their current MUDs. Avoid strange people who are
creators on 10 different MUDs. Every single person on the team should
have some experience in having built an area on some other MUD (remember,
we are not talking about area builders here, we are talking about your
core administrative team).
</p>
<p>
And you yourself should have built an area on another MUD. Having played
a MUD or done complex programming for Windows does not qualify you to
build a MUD. Certainly you better had played a MUD before you ever
became a creator on one, but it takes someone who has both had the
experience coding in LPC <i>and</i> the experience of having seen what
happens when that code is put into a real game.
</p>
<p>
What if you have not been a creator on a MUD before? You are best off
finding a MUD which will allow you to be a creator and get that experience.
Many people argue that they do not wnat to play all those levels just to get
to code an area, but the fact is that most MUDs these days will allow
people to code without making any certain level. If you have no MUD
coding experience, then any attempt to start a MUD will fail.
</p>
<hr size="1">
<a name="1.4"><p><strong>1.4 Analysis</strong></p></a>
<p>
Do not jump in and code right away. Too many people, including myself, have
made the mistake of running off and coding before event figuring out what it
is they want to code. Analysis involves first deciding what exactly you want
to build. Do you want to build a sci-fi MUD? Or are you instead
building a fantasy MUD? Once you have determined the context of your
problem, you then need to move on to deciding what the pieces of that
problem are.
</p>
<p>
Forget that you know anything about LPC. Forget anything you know about
coding MUDs in general. Instead, go back to being a player. If your
team is physically in the same area, the best thing to do is find a big white
board and some markers. In the absence of physical co-location, gather
together and make sure you write down somewhere what you discuss. You will
need to define all the things which exist in your MUD.
</p>
<p>
The proper term for "things" here is "object". Of course, since you know
LPC, you know that LPC has a data type called object. In this discussion,
however, you need to forget about the LPC object and think just about things.
What sort of things are there? Well, in your fantasy MUD, you have swords,
firebreathers, shop keepers, Leo the Archwizard, bridges, rooms, doors,
players, monsters, creators, etc. The list really can go on and on. And one
thing to remember is that if it is a thing and you think of it at this point,
then write it down. There are no wrong answers at this point. You will
eliminate trivial objects later. At this point, however, what might seem
prima facie to be a trivial object may in fact turn out to be key. Keep
in mind also that object here does not necessarily equal object in LPC.
</p>
<p>
In addition to looking around and defining what objects make up your world,
you need to define the roles your team will have. As I discussed in the
previous section, you must have well-defined realms of responsibility. There
is no one correct power structure for a MUD. The one that works is simply
one where each team member knows their responsibility and can feel comfortable
than any decision they make in that realm will not be turned over by another
team member. An example of how <i>Nightmare</i> implements this:
</p>
<DL>
<DT>Approval Department
<DD>The head arch of approval is in charge of all decisions regarding who becomes
a creator on <I>Nightmare</I> and whose code is placed into the game. The
responsibilities of this department thus involve interviewing and approving
creator candidates and reviewing, bug-testing, and approving newly created
areas.
<DT>Driver Department
<DD>The head arch of this department makes certain that <I>Nightmare</I> always
has a current, bug free version of the LPC driver. In addition, this department
works with mudlib on ways in which to improve game efficiency.
<DT>Law Department
<DD>The head arch of this department makes certain that the rules of <I>Nightmare</I>
are obeyed by players and creators. The main duty is to watch out for cheaters
and harassers.
<DT>Mudlib department
<DD>The head arch of this department oversees the development of new mudlib
code. In coordination with approval, this departments sees that all new code
is thoroughly tested and a clear migration path is defined for existing creator
code.
</DL>
<p>
Credit for this structure goes back as far at least to <i>IgorMUD</i> on which
I was first an arch. I do not know where they got this structure from.
</p>
<hr size="1">
<a name="1.5"><p><strong>1.5 Design</strong></p></a>
<p>
Design is perhaps where your MUD will most succeed or fail. Of course,
you cannot get to design if you have not determined what your game will
be or what objects will be involved in that game. In design, you determine
how all of those objects you defined in analysis interact together. What
does a monster do? What does a firebreather do? Do players and monsters
have anything in common? Can we abstract those commonalities into a more
general object?
</p>
<p>
When looking at any one object, you need to identify its characteristics
and behaviours. Characteristics for a monster might be that it is a goblin,
it is level 10, it is drunk, etc. Things that make it stand out from other
monsters. Behaviours, on the other hand, are things that objects of the same
type do. A player can kill things, and a player can die. A player can take
damage, or a player can issue a command. In object-oriented terminology,
the characteristics are attributes, and the behaviours are methods. In
LPC terminology, your characteristics become global variables, and your
behaviours become functions.
</p>
<p>
So far, this has all been rather esoteric. Let's look at a fantasy MUD. You
have identified that you have monsters of various races, players, creators,
rooms, bars, barkeeps, swords, knives, and drinks. You have defined the
ways in which each of these behave with respect to other objects through
simple English (or whatever your native tongue is):
</p>
<ul>
<li>Players kill monsters.</li>
<li>Monsters kill players.</li>
<li>Players drink drinks.</li>
<li>Barkeeps sell drinks.</li>
<li>Bars contain barkeeps.</li>
<li>Bars are rooms.</li>
<li>Players wield swords.</li>
<li>Players wield knives.</li>
</ul>
<p>
The first special kind of relationship that should always jump out at you are
"is a" relationships. Above, we have "Bars are rooms". You can be pretty
certain here that your bar object will somehow be inheriting your room object
when it comes time to do LPC.
</p>
<p>
The next thing you might notice is that players have exactly the same
relationship to swords that they have to knives. This should raise a flag
that says there might be some "is a" relationship lurking under the covers.
In this case, the real relationship is "players wield weapons", with the
proper "is a" relationship being "a knife is a weapon" and "a sword is a
weapon".
</p>
<p>
The next relationship type you want to note is the "contains" relationship.
In the above example, it is not all that interesting, except it is a specific
case of the more general "rooms contain monsters". In this case, you have a
specific type of room containing a specific type of monster. What makes this
room different than other rooms is that the kind of monster it contains is a
monster. You want to beware, however, of mistaking "is a" relationships for
"contains" (which are also called "has a") relationships. In practice, in LPC,
"contains" relationships are sometimes implemented as "is a" relationships.
For example, in the <I>Nightmare Object Library</I>, living things are implemented
as being body objects which contain limb objects (note that here is an example
of where design object is not equal to LPC object as limb objects are really
mappings), though perhaps the more proper object-oriented design is that living
objects.
</p>
