DUNGEON(6)                                             DUNGEON(6)

NAME
       dungeon - Adventures in the Dungeons of Doom

SYNOPSIS
       dungeon

DESCRIPTION
       Dungeon  is  a game of adventure, danger, and low cunning.
       In it you will explore some of the most amazing  territory
       ever  seen  by  mortal man.  Hardened adventurers have run
       screaming from the terrors contained within.

       In Dungeon, the intrepid explorer delves into the  forgot-
       ten  secrets of a lost labyrinth deep in the bowels of the
       earth, searching for vast treasures long hidden from  pry-
       ing  eyes, treasures guarded by fearsome monsters and dia-
       bolical traps!

       Dungeon was created at the Programming Technology Division
       of  the  MIT Laboratory for Computer Science by Tim Ander-
       son, Marc Blank, Bruce Daniels, and Dave Lebling.  It  was
       inspired  by the Adventure game of Crowther and Woods, and
       the Dungeons and Dragons game of Gygax and  Arneson.   The
       original  version  was written in MDL (alias MUDDLE).  The
       current version was translated from MDL into FORTRAN IV by
       a  somewhat  paranoid  DEC  engineer who prefers to remain
       anonymous.

       On-line information may be obtained with the commands HELP
       and INFO.

DETAILS
       Following is the summary produced by the info command:

              Welcome to Dungeon!

              You  are  near a large dungeon, which is reputed to
              contain vast quantities of  treasure.    Naturally,
              you wish to acquire some of it.  In order to do so,
              you must of course remove it from the dungeon.   To
              receive  full  credit  for  it, you must deposit it
              safely in the trophy case in the living room of the
              house.

              In addition to valuables, the dungeon contains var-
              ious objects which may or may not be useful in your
              attempt  to  get  rich.   You  may  need sources of
              light, since dungeons are often dark, and  weapons,
              since dungeons often have unfriendly things wander-
              ing about.  Reading material  is  scattered  around
              the  dungeon  as well;  some of it is rumored to be
              useful.

              To determine how successful you have been, a  score
              is  kept.  When you find a valuable object and pick
              it up, you receive  a  certain  number  of  points,
              which  depends  on  the  difficulty  of finding the
              object.  You receive extra points for  transporting
              the  treasure safely to the living room and placing
              it in the trophy case.  In addition, some  particu-
              larly  interesting  rooms  have  a value associated
              with visiting them.  The only penalty is  for  get-
              ting  yourself killed, which you may do only twice.

              Of special note is a thief (always carrying a large
              bag)  who likes to wander around in the dungeon (he
              has never been seen by the light of day).  He likes
              to  take  things.   Since  he  steals  for pleasure
              rather than profit and  is  somewhat  sadistic,  he
              only takes things which you have seen.  Although he
              prefers valuables, sometimes in his  haste  he  may
              take  something  which  is worthless.  From time to
              time, he examines his  take  and  discards  objects
              which he doesn't like.  He may occasionally stop in
              a room you are visiting, but  more  often  he  just
              wanders  through  and rips you off (he is a skilled
              pickpocket).

COMMANDS
       brief          suppresses printing of long  room  descrip-
                      tions for rooms which have been visited.

       superbrief     suppresses  printing  of long room descrip-
                      tions for all rooms.

       verbose        restores long descriptions.

       info           prints information which  might  give  some
                      idea of what the game is about.

       quit           prints your score and asks whether you wish
                      to continue playing.

       save           saves the state of the game for later  con-
                      tinuation.

       restore        restores a saved game.

       inventory      lists the objects in your possession.

       look           prints  a description of your surroundings.

       score          prints your current score and ranking.

       time           tells you how long you have been playing.

       diagnose       reports on your injuries, if any.

       The inventory command may be abbreviated i; the look  com-
       mand  may be abbreviated l; the quit command may be abbre-
       viated q.

       A command that begins with '!' as the first  character  is
       taken to be a shell command and is passed unchanged to the
       shell via system(3).

CONTAINMENT
       Some objects can contain other objects.   Many  such  con-
       tainers  can  be  opened  and closed.  The rest are always
       open.   They may or may not be transparent.   For  you  to
       access (e.g., take) an object which is in a container, the
       container must be open.  For you to see  such  an  object,
       the  container  must  be either open or transparent.  Con-
       tainers have a capacity, and objects have sizes; the  num-
       ber  of  objects which will fit therefore depends on their
       sizes.  You may put any object you have access to (it need
       not  be  in  your  hands)  into any other object.  At some
       point, the program will attempt to pick it up if you don't
       already have it, which process may fail if you're carrying
       too much.  Although containers can contain other  contain-
       ers,  the program doesn't access more than one level down.

FIGHTING
       Occupants of the dungeon will, as a rule, fight back  when
       attacked.   In  some cases, they may attack even if unpro-
       voked.   Useful  verbs  here  are  attack  <villain>  with
       <weapon>,  kill,  etc.   Knife-throwing  may or may not be
       useful.  You have a fighting strength  which  varies  with
       time.  Being in a fight, getting killed, and being injured
       all lower this strength.  Strength is regained with  time.
       Thus,  it  is not a good idea to fight someone immediately
       after being killed.  Other details should become  apparent
       after a few melees or deaths.

COMMAND PARSER
       A  command  is  one  line of text terminated by a carriage
       return.  For reasons of simplicity, all words are  distin-
       guished  by  their  first  six  letters.   All  others are
       ignored.  For example, typing disassemble the encyclopedia
       is not only meaningless, it also creates excess effort for
       your fingers.  Note that this truncation may produce ambi-
       guities  in the intepretation of longer words.  [Also note
       that upper and lower case are equivalent.]

       You are dealing with a fairly stupid parser, which  under-
       stands the following types of things:

              Actions:
                   Among the more obvious of these, such as take,
                   put, drop, etc.  Fairly general forms of these
                   may be used, such as pick up, put down, etc.

              Directions:
                   north, south, up, down, etc. and their various
                   abbreviations.  Other more obscure  directions
                   (land,  cross) are appropriate in only certain
                   situations.

              Objects:
                   Most objects have names and can be  referenced
                   by them.

              Adjectives:
                   Some  adjectives  are  understood and required
                   when there are two objects which can be refer-
                   enced  with the same 'name' (e.g., doors, but-
                   tons).

              Prepositions:
                   It may be necessary in some cases  to  include
                   prepositions,  but the parser attempts to han-
                   dle  cases  which  aren't  ambiguous  without.
                   Thus give car to demon will work, as will give
                   demon car.  give car demon probably  won't  do
                   anything  interesting.   When a preposition is
                   used, it should be appropriate; give car  with
                   demon won't parse.

              Sentences:
                   The  parser understands a reasonable number of
                   syntactic  construc-  tions.   In  particular,
                   multiple commands (separated by commas) can be
                   placed on the same line.

              Ambiguity:
                   The parser tries to be clever about what to do
                   in  the  case of actions which require objects
                   that are not explicitly specified.   If  there
                   is  only  one possible object, the parser will
                   assume that it should be used.  Otherwise, the
                   parser  will ask.  Most questions asked by the
                   parser can be answered.

FILES
       dtextc.dat     -  encoded  messages   and   initialization
       information
       dsave.dat      - save file

BUGS
       For those familiar with the MDL version of the game on the
       ARPAnet, the following is a list of the  major  incompata-
       bilties:
              -The  first  six  letters  of a word are considered
              significant, instead of the first five.
              -The syntax for tell, answer, and incant is differ-
              ent.
              -Compound objects are not recognized.
              -Compound  commands  can be delimited with comma as
              well as period.

       Also, the palantir, brochure, and dead  man  problems  are
       not implemented.

AUTHORS
       Many  people  have  had  a  hand in this version.  See the
       "History"  and  "README"  files  for  credits.   Send  bug
       reports to ian@airs.com (or uunet!airs!ian).

                          March 11, 1991                        1