
   Advanced LPC
   
                                 Chapter 1
                                      
                                Introduction
                                      
                     [ Table of Contents | Chapter 2 ]
                                      
                            [ Index | Glossary ]
     _________________________________________________________________
   
  1.1 What else is there?
  
   If you are ready for this textbook, then you have probably answered
   this question for yourself. You should know well the material in LPC
   Basics and Intermediate LPC 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.
   
   Like the other two textbooks which came before it, Advanced LPC 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.
   
   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.
     _________________________________________________________________
   
  1.2 Starting your own MUD
  
   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.
   
   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.
   
   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.
   
   There are 5 steps to building a successful MUD:
   
   [INLINE] Define your team
          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.
          
   [INLINE] Analyze the situation
          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?".
          
   [INLINE] Design the MUD
          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.
          
   [INLINE] Implementing the design
          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.
          
   [INLINE] Recruit creators to build areas
          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.
     _________________________________________________________________
   
  1.3 Team Building
  
   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.
   
   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.
   
   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.
   
   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.
   
   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).
   
   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 and the experience of having seen what
   happens when that code is put into a real game.
   
   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.
     _________________________________________________________________
   
  1.4 Analysis
  
   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.
   
   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.
   
   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.
   
   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 Nightmare implements this:
   
   [INLINE] Approval Department
          The head arch of approval is in charge of all decisions
          regarding who becomes a creator on Nightmare 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.
          
   [INLINE] Driver Department
          The head arch of this department makes certain that Nightmare
          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.
          
   [INLINE] Law Department
          The head arch of this department makes certain that the rules
          of Nightmare are obeyed by players and creators. The main duty
          is to watch out for cheaters and harassers.
          
   [INLINE] Mudlib department
          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.
          
   Credit for this structure goes back as far at least to IgorMUD on
   which I was first an arch. I do not know where they got this structure
   from.
     _________________________________________________________________
   
  1.5 Design
  
   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?
   
   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.
   
   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):
   
   [INLINE] Players kill monsters.
          
   [INLINE] Monsters kill players.
          
   [INLINE] Players drink drinks.
          
   [INLINE] Barkeeps sell drinks.
          
   [INLINE] Bars contain barkeeps.
          
   [INLINE] Bars are rooms.
          
   [INLINE] Players wield swords.
          
   [INLINE] Players wield knives.
          
   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.
   
   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".
   
   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 Nightmare Object Library, 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
   have limb objects. If you recognize the exceptions and understand
   them, you will be alright. If however, you miss these, you may cause
   problems for yourself in the future.
   
   At this point, you should now fully understand all of the pieces to
   your puzzle and exactly how those pieces fit together. Now it is time
   to put those pieces together.
     _________________________________________________________________
   
  1.6 Implementation
  
   This really is the easier part of things. Using your design and your
   knowledge of LPC, you will begin writing the code which makes your
   design come to life. Chances are that you do not want to do this from
   scratch, however. The more basic pieces of your design are probably
   already implemented by a publically available object library (mudlib).
   You probably should look around at the available mudlibs, which you
   can find in the LPMud FAQ, and see which mudlib design best matches
   your MUD design. Factors you will want to take into account are how
   flexible you are with your design, how much rework you are willing to
   do, what drivers and mudlibs you are already familiar with, etc.
   
   The rest of this textbook will revolve around implementation issues.
   The textbook assumes that you have LPC knowledge and have actually
   both created an LPMud area and seen it put into play on a real MUD.
     _________________________________________________________________
   
  1.7 Finding Creators
  
   The popularity of MUDs, in the end, rides on two things: the
   creativity of its creators and the character of its players. You
   control the latter through the way in which your team interacts with
   players, as well as the rules which have been set forth and how they
   are applied. The former his done through attracting creative people to
   build neat areas. Do not look for experience. If you get someone with
   experience, that is great. In general, though, people who have
   experience either are in love with their current MUDs and will not
   leave, or they are on their way to starting their own MUDs and won't
   have time for you. Things to avoid are known trouble makers and people
   who have a zillion other MUDs on which they are creator.
     _________________________________________________________________
   
   
    Copyright 1995 George Reese (borg@imaginary.com)
