CP/M

home *** CD-ROM | disk | FTP | other *** search

/ CP/M / CPM_CDROM.iso / simtel / sigm / vols000 / vol045 / dungeo.doc < prev next >

Wrap

Text File | 1984-04-29 | 21.6 KB | 599 lines

To: Dungeon Players From: "The Translator" Subj: Game Information Date: 8-OCT-80 This is the first (and last) source release of the PDP-11 version of Dungeon. Please note that Dungeon has been superceded by the game ZORK(tm). The following is an extract from the new product announcement for ZORK in the September, 1980 issue of the RT-11 SIG newsletter: "'ZORK: The Great Underground Empire - Part I' ...was developed by the original authors based on their ZORK (Dungeon) game for the PDP-10. It features a greatly improved parser; command input and transcript output files; SAVEs to any device and file name; and adaptation to different terminal types, including a status line on VT100s. Note: this is not the FORTRAN version that has been available through DECUS. This version has been completely rewritten to run efficiently on small machines - up to 10 times as fast as the DECUS version. ...ZORK runs under RT-ll, HT-ll, or RSTS/E and requires as little as 20K words of memory and a single floppy disk drive. The game package, consisting of an RX01-format diskette and an instruction booklet, is available from Infocom, Inc., P.O. Box 120, Kendall Station, Cambridge, Ma. 02142." ZORK(tm) is a trademark of Infocom, Inc. It is available for several popular personal computers as well as for the PDP-ll. 1. Components Dungeon is a maze-solving game for solitaire play. It runs on any PDP-11 (with 28KW of memory or more) or VAX-11. Dungeon consists of the following files: all operating systems --------------------- DMAIN.FTN -program root DGAME.FTN -main routine DSUB.FTN -resident subroutines DINIT.FTN -initialization routine NP.FOR -parser, part 0 NP1.FOR -parser, part 1 NP2.FOR -parser, part 2 NP3.FOR -parser, part 3 GDT.FTN -game debugging tool VERBS.FTN -principal verbs OBJCTS.FTN -principal objects SVERBS.FTN -simple verbs DVERB1.FTN -auxiliary verbs, part 1 DVERB2.FTN -auxiliary verbs, part 2 all operating systems (continued) --------------------------------- ACTORS.FTN -character processors DEMONS.FTN -demon processors CLOCKR.FTN -clock event processors ROOMS.FOR -room processors NROOMS.FOR -new room processors SOBJS.FOR -simple objects NOBJS.FOR -new objects BALLOP.FOR -balloon processor LIGHTP.FOR -light processors VILLNS.FOR -villain processors DSO1.FOR -overlaid subroutines, part 1 DSO2.FOR -overlaid subroutines, part 2 DSO3.FOR -overlaid subroutines, part 3 DSO4.FOR -overlaid subroutines, part 4 DSO5.FOR -overlaid subroutines, part 5 DSO6.FOR -overlaid subroutines, part 6 DSO7.FOR -overlaid subroutines, part 7 DINDX.DAT -initialization data base DTEXT.DAT -main data base [binary file] DUNGEO.DOC -this file RT11 only --------- RTTIM.FOR -time subroutine RRND.MAC -random number generator RTCMP.COM -compile command file RTBLD.COM -link command file RSTS/E only ----------- RTTIM.FOR -time subroutine RRND.MAC -random number generator RSTSCB.CTL -compile/build batch file RSX11M, RSX11M+ only -------------------- RSXTIM.MAC -time subroutine RRND.MAC -random number generator RSXCMP.CMD -compile command file RSXBLD.CMD -task build command file D.ODL -overlay descriptor file VMS only -------- VMSTIM.FOR -time subroutine VMSRND.MAC -random number generator VMSCMP.COM -compile command file VMSBLD.COM -link command file 2. Installation Instructions, RT11 Before starting, please note that: - Dungeon requires RT11 V3 or later. - Dungeon requires Fortran-IV V2 or later, threaded code option. - Dungeon requires 26KW of user memory (runs under SJ monitor only). - All files (source and object) must reside on the same disk (at least 2500 disk blocks are needed). - Dungeon does not require EIS or floating point. Except for DTEXT.DAT, all files in the distribution kit are ASCII. DTEXT.DAT is a binary file consisting of 76-byte fixed length records. If the distribution kit consists of RT11-compatible media, then PIP can be used to transfer the files. If the distribution kit consists of DOS-compatible media, then FILEX must be used to transfer the files. The /I switch (image binary) must be used to transfer DTEXT.DAT; the /A (ASCII) switch should be used to transfer the other files. To compile Dungeon, issue the following command: .@RTCMP(cr) Several of the compilations will produce warning messages, but none should produce a fatal error. To link the compiled sources, issue the following command: .@RTBLD(cr) The command file assumes that the Fortran-IV object time library has been merged into the system library. If this is not the case, edit RTBLD.COM and add switch /LINKLIBRARY:FORLIB.OBJ to the first command line. It is now possible to run Dungeon: .R DUNGEO(cr) When invoked, Dungeon takes no more than 5-10 seconds to start up. Notes on the executable program: - The only files needed to execute Dungeon are DUNGEO.SAV, DINDX.DAT, and DTEXT.DAT. All other files can be deleted. - Files DINDX.DAT and DTEXT.DAT must reside on logical device SY: (this can be changed with a source edit, see section 8). 3. Installation Instructions, RSTS/E Before starting, please note that: - Dungeon requires RSTS/E V6C or later. - Dungeon requires Fortran-IV V2 or later, threaded code option (operation under Fortran-IV-Plus V2.5 or later will probably work but is not supported). - Dungeon requires 28KW of user memory. - All files (source and object) must reside in the same user area (at least 2500 disk blocks are needed). - Dungeon does not require EIS or floating point. Except for DTEXT.DAT, all files in the distribution kit are ASCII. DTEXT.DAT is a binary file consisting of 76-byte fixed length records. If the distribution kit consists of RT11- or DOS-compatible disks, then FIT can be used to transfer the files. For example (RT11 disk): RUN $FIT(cr) FIT>*.*/RSTS=DK:*.*/RT11(cr) FIT>^Z If the distribution kit consists of DOS-compatible magtape, then PIP can be used to transfer the files, providing that the magtape is assigned as a DOS-label device. For example: ASSIGN MM0:.DOS(cr) RUN $PIP(cr) **.*/AS=MM:*.FTN,*.FOR,*.MAC,*.DOC,*.CTL(cr) **.*/AS=MM:*.CMD,*.COM,*.ODL,DINDX.DAT(cr) **.*/BL=MM:DTEXT.DAT(cr) *^C DEASS MM0:(cr) To compile and link Dungeon, submit control file RSTSCB.CTL to the batch processor: SUBMIT RSTSCB.CTL(cr) Several of the compilations will produce warning messages, but none should produce a fatal error. It is now possible to run Dungeon: RUN DUNGEO(cr) When invoked, Dungeon takes no more than 5-10 seconds to start up. Notes on the executable program: - The only files needed to execute Dungeon are DUNGEO.SAV, DINDX.DAT, and DTEXT.DAT. All other files can be deleted. - Files DINDX.DAT and DTEXT.DAT must reside in the user's area on logical device SY: (this can be changed with a source edit, see section 8). 4. Installation Instructions, RSX11M and RSX11M+ Before starting, please note that: - Dungeon requires RSX11M V3 (RSX11M+ V1) or later. - Dungeon requires Fortran-IV-Plus V2.5 or later (operation under Fortran-IV V2 or later will probably work but is not supported). - Dungeon requires a 32KW user partition (mapped systems only). - All files (source and object) must reside in the same user area (at least 2500 disk blocks are needed). - TKB should invoke BIGTKB.TSK with a large memory increment. - The Fortran-IV-Plus object time library must be merged into the system library (SYSLIB.OLB). Further, the library must be set up to invoke the short error text module ($SHORT) as the default. Task building with a separate object time library produces numerous errors; task building with a resident library or the normal error text module produces an oversize task image. - Dungeon requires EIS but not floating point. Except for DTEXT.DAT, all files in the distribution kit are ASCII. DTEXT.DAT is a binary file consisting of 76-byte fixed length records. If the distribution kit consists of Files-11 compatible media, then PIP can be used to transfer the files. For example: >PIP SY:*.*=MM:*.*(cr) -requires ANSI magtape support If the distribution kit consists of DOS- or RT11-compatible media, then FLX must be used to transfer the files. The /IM:76. switch (image binary fixed length) must be used to transfer DTEXT.DAT; the /FA switch (formatted ASCII) should be used to transfer the other files. For example (DOS magtape): >FLX(cr) FLX>SY:/RS/FA=MM:*.FTN,*.FOR,*.MAC,*.DOC/DO(cr) FLX>SY:/RS/FA=MM:*.CMD,*.COM,*.ODL,DINDX.DAT/DO(cr) FLX>SY:/RS/IM:76.=MM:DTEXT.DAT/DO(cr) FLX>^Z To compile Dungeon, issue the following command: >@RSXCMP(cr) There should be no error messages. To task build the compiled sources, issue the following command: >TKB @RSXBLD(cr) It is now possible to run Dungeon: >RUN DUNGEON(cr) When invoked, Dungeon takes no more than 5-10 seconds to start up. If your system maintains a separate Fortran-IV-Plus object time library (F4POTS.OLB), then you must create a local copy of the system library with the Fortran-IV-Plus object time library merged in and the short error text as the default. The following commands are an example of how such a local copy could be built: >PIP SY:*.*=LB:[1,1]SYSLIB.OLB,F4POTS.OLB(cr) -copy libraries >LBR(cr) -invoke LBR LBR>SHORT.OBJ=F4POTS.OLB/EX:$SHORT(cr) -extract $SHORT LBR>F4POTS.OLB/DE:$SHORT(cr) -delete $SHORT LBR>F4POTS.OBJ=F4POTS.OLB/EX(cr) -extract other modules LBR>SYSLIB.OLB=F4POTS.OBJ(cr) -insert other modules LBR>SYSLIB.OLB/DG:$ERTXT(cr) -delete dup entry LBR>SYSLIB.OLB=SHORT.OBJ/RP(cr) -insert $SHORT LBR>^Z >PIP F4POTS.*;*,SHORT.OBJ;*/DE(cr) Then edit D.ODL to reference the local library instead of the default system library: >TEC D.ODL(cr) *FS[1,1]$SY:$EX$$ Dungeon can now be task built as described above. Notes on the executable program: - The only files needed to execute Dungeon are DUNGEON.TSK, DINDX.DAT, and DTEXT.DAT. All other files can be deleted. - Files DINDX.DAT and DTEXT.DAT must reside in the user's area on logical device SY: (this can be changed with a source edit, see section 8). - Exiting from Dungeon via an MCR ABOrt command instead of the QUIT command will leave file DTEXT.DAT open and locked. The file must be manually unlocked before the game is next invoked: >PIP DTEXT.DAT/UN(cr) 5. Installation Instructions, VMS Before starting, please note that: - Dungeon requires VMS V1 or later. - Dungeon requires VAX Fortran-IV V1 or later. - All files (source and object) must reside in the user's area (at least 2500 disk blocks are needed). Except for DTEXT.DAT, all files in the distribution kit are ASCII. DTEXT.DAT is a binary file consisting of 76-byte fixed length records. If the distribution kit consists of Files-11 compatible media, then COPY can be used to transfer the files. For example: $ COPY MM:*.* *.*(cr) If the distribution kit consists of DOS- or RT11-compatible media, then FLX must be used to transfer the files. The /IM:76. switch (image binary fixed length) must be used to transfer DTEXT.DAT; the /FA switch (formatted ASCII) should be used to transfer the other files. For example (DOS magtape): $ MCR FLX(cr) FLX>SY:/RS/FA=MM:*.FTN,*.FOR,*.MAC,*.DOC/DO(cr) FLX>SY:/RS/FA=MM:*.CMD,*.COM,*.ODL,DINDX.DAT/DO(cr) FLX>SY:/RS/IM:76.=MM:DTEXT.DAT/DO(cr) FLX>^Z To compile Dungeon, issue the following command: $ @VMSCMP(cr) There should be no error messages. To link the compiled sources, issue the following command: $ @VMSBLD(cr) It is now possible to run Dungeon: $ RUN DUNGEON(cr) When invoked, Dungeon takes no more than 5-10 seconds to start up. Notes on the executable program: - The only files needed to execute Dungeon are DUNGEON.EXE, DINDX.DAT, and DTEXT.DAT. All other files can be deleted. - Files DINDX.DAT and DTEXT.DAT must reside in the user's area (this can be changed with a source edit, see section 8). 6. Warnings and Restrictions For those familiar with the MDL version of the game on the ARPAnet, the following is a list of the major incompatabilties: -The first six letters of a word are considered significant, instead of the first five. -The syntax for TELL, ANSWER, and INCANT is different. -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. 7. Abstract of Informational Printouts SUMMARY ------- Welcome to Dungeon! 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 forgotten secrets of a lost labyrinth deep in the bowels of the earth, searching for vast treasures long hidden from prying eyes, treasures guarded by fearsome monsters and diabolical traps! No DECsystem should be without one! Dungeon was created at the Programming Technology Division of the MIT Laboratory for Computer Science by Tim Anderson, 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. INFO ---- 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 various 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 wandering 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 particularly interesting rooms have a value associated with visiting them. The only penalty is for getting 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 occas- ionally stop in a room you are visiting, but more often he just wanders through and rips you off (he is a skilled pickpocket). HELP ---- Useful commands: The 'BRIEF' command suppresses printing of long room descriptions for rooms which have been visited. The 'SUPERBRIEF' command suppresses printing of long room descriptions for all rooms. The 'VERBOSE' command restores long descriptions. The 'INFO' command prints information which might give some idea of what the game is about. The 'QUIT' command prints your score and asks whether you wish to continue playing. The 'SAVE' command saves the state of the game for later continuation. The 'RESTORE' command restores a saved game. The 'INVENTORY' command lists the objects in your possession. The 'LOOK' command prints a description of your surroundings. The 'SCORE' command prints your current score and ranking. The 'TIME' command tells you how long you have been playing. The 'DIAGNOSE' command reports on your injuries, if any. Command abbreviations: The 'INVENTORY' command may be abbreviated 'I'. The 'LOOK' command may be abbreviated 'L'. The 'QUIT' command may be abbreviated 'Q'. Containment: Some objects can contain other objects. Many such containers 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. Containers have a capacity, and objects have sizes; the number 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 containers, 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 unprovoked. 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 distinguished 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 trunca- tion may produce ambiguities in the intepretation of longer words. You are dealing with a fairly stupid parser, which understands 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 referenced with the same 'name' (e.g., DOORs, BUTTONs). Prepositions: It may be necessary in some cases to include prepositions, but the parser attempts to handle 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. 8. Source Notes A few notes for source hackers. - The initialization module (DINIT.FTN) includes an access protection function PROTCT. If PROTCT returns a value of .TRUE., the game is permitted to start; if PROTCT returns .FALSE., the game is terminated with a suitably nasty message. At present, PROTCT is a dummy routine and always returns .TRUE.; by tailoring PROTCT, access to the game can be restricted to certain hours or users. - The data base OPEN and READ statements are in the initialization module (DINIT.FTN). The data base file names are simply "DINDX.DAT" and "DTEXT.DAT". These may be freely changed to include logical device names, UIC's, etc. Thus, it is possible to place the data base files on different devices, in a fixed UIC, etc. - Converting the game to another processor is not a straightforward procedure. The game makes heavy use of extended and/or idiosynchratic features of PDP-11 Fortran. Particular nasties include the following: > The game vocabulary is stored in Radix-50 notation. > The game uses the extended I/O commands OPEN and CLOSE. > The game uses LOGICAL*1 variables for character strings. > The game uses logical operators on integers for bitwise binary operations. > The game treats certain arrays and variables as unsigned 16-bit integers (integer overflow may occur). In general, the game was implemented to fit in memory, not to be transported. You're on your own, friend!