Adventure is a computerised version of the game Dungeons and Dragons, both of which are enormously popular. In Dungeons and Dragons a player is assigned the role of dungeon master, devising the dungeons which the other players explore in an attempt to acquire the treasures hidden there, often after having fought their way past monsters of various kinds.
Each player announces his action to the dungeon master who then tells him of the outcome, usually after spinning various dice to generate a random element.
Adventure, run on PDP-11 systems everywhere, is similar to Dungeons and Dragons except that the dungeons are devised by the original programmer and the computer then assumes the role of dungeon master.
Somewhere nearby is Colossal Cave, where others have found fortunes in treasure and gold, though it is rumoured that some who enter are never seen again. Magic is said to work in the cave. I will be your eyes and hands. Direct me with commands of one or two words. You are standing at the end of a road before a small brick building. Around you is a forest. A small stream flows out of the building and down a gully. ENTER BUILDING You are inside a building. A well house for a large spring. There are some keys on the ground here. There is a shiny brass lamp nearby. There is food here. There is a bottle of water here. GET KEYS OK GET LAMP OK RUB LAMP Rubbing an electric lamp is not particularly rewarding. Anyway, nothing exciting happens. EXIT You're at the end of the road again. Go SOUTH You are in a valley in the forest beside a stream tumbling along a rocky bed GO SOUTH You are in a 20-ft. depression floored with bare dirt. Set into the dirt is a strong steel grate mounted in concrete. The grate is locked UNLOCK GRATE The grate is unlocked.Once having opened the grate, for which he must have the keys, the player then has access to Colossal Cave where there are problems to solve and treasures to gather. However, if he does not have the keys, there is no way that the grate can be opened. In fact, it may take him, a while to find the entrance as it is all too easy to become lost in the forest.
As you can see from the example, playing Adventure is rather like reading a novel, with one important difference. Instead of following the story passively, the reader is involved actively, deciding what is the best action to take in a given situation, often having to think very carefully as the wrong decision may lead to death.
That affinity with a novel is Adventure's main disadvantage. Once all the problems have been solved, which may take several weeks, interest wanes and another Adventure is required.
The original version of Adventure, programmed by Will Crowther at Stanford Research Institute, is coded in Fortran, requires 64Kbytes of memory, disc back-up and is very difficult to modify to generate new games as many of its features are buried deep within the program code. That explains the current shortage of Adventures.
A better solution would be to have a general Adventure program driven by a separate database allowing new games to be generated without having to overcome the programming complexities every time. In fact, that approach was used by Scott Adams who has now produced a number of excellent adventures for some of the more popular systems such as the TRS-8O and Sorcerer.
The program described here carries this concept one step further. Instead of one person producing adventures for a limited range of systems the idea is to describe a program which can be implemented on almost any system and driven by an entirely separate and machine-independent database. That allows owners of the program to write adventures in a simple form and swap games with someone who may have an entirely different processor.
1. The vocabulary of words recognised in the game. 2. The objects that may be manipulated 3. The places that may be visited 4. The actions performed by specific words.All that is required to produce the database and the program is an assembler and examples of various table entries are shown for a Z-8O type assembler.
The vocabulary is held as the first four letters of a word followed by an identifying code. That permits the program to reduce words to simple numbers which are much easier to manipulate. It also allows different words to have the same code and hence the same meaning.
VOCAB: DEFM 'NORT' ;Word "NORTH" DEFB 1 ;Identifying code "1" DEFM 'EAST' DEFB 2 ;EAST has code "2"DEFM is the instruction to define an ASCII string and DEFB is to define a byte. The table has the name "VOCAB" and terminated by a byte of 0FFH (255 or -1). The words for movement - north, south, etc. - must have codes in the range 1 to 12 as the program prints the message - I cannot go in that direction - if it cannot find anything to do with words in that range. Other unmatched words generate the simpler response: I can't.
Objects are anything which may be moved from one place to another and/or transformed from one thing to another. A lamp, for example, may be carried with the player and it may be transformed from a "LIT LAMP" to an 'UNLIT LAMP" and, of course, back again.
Each object has an entry in each of two tables: the object location table which records the current position of the object and the object description table which contains the text used to describe the object.
The current location table is named "OBJLOC" and the descriptive text table "OBJTXT". OBJLO is terminated by a byte of OFFH. OBJTXT needs no termination.
OBJLOC: DEFB 3,0 ;Object 0 at location 3 DEFB 5,0 ;Object 1 at locations 5 ;Similarly for other objects OBJTXT: DEFW M0 ;Address of text for object 0 DEFW M1 ;Address of text for object 1 M0: DEFM 'A little axe' ;Description of object 0 DEFB 80H ;String terminator Ml: DEFM 'A bunch of keys' DEFB 80HNote that the object position information is two bytes to allow it to be at a location - first byte is 0-225 - or in some special place, such as carried by the player - second byte is used. Also, the object description table OBJTXT contains the address of the actual description for each object.
The locations are the places that the player may visit. They may be rooms, caves or anything desired by the Adventure writer. Each location has an entry in two tables: The description of the location and the list of directions the player may go from there. The location descriptions are held in a table named LOCTXT and the possible movements in MOVEMT. Both of those tables consist of pointers to the actual data as described for the object descriptions above.
MOVEMT: DEFW D0 ;Pointer to location 0 moves DEFW D1 ;Pointer to location 1 moves ;etc. for rest of locationsThe following example movement shows an entry that says that word 0 takes us to location 1 and word 3 will take us to location 5. Note that a -1 terminates the list.
D0: DEFB 0,1,3,5,-1 LOCTXT: DEFW L0 ;Pointer to descriptions DEFW L1 L0: DEFM 'I am in an empty room DEFB 80H L1: DEFM 'I am by a stream' DEFB 80HThe action table is the section of the database interpreted or executed by the main program. It consists of word, conditions and actions performed. If there is an entry in the table for the words entered by the user and the conditions specified are met, the actions are performed.
For example, he may be in the same room as a Vampire without a crucifix so the computer may make the Vampire attack. The user action table is named EVENT and the computer's table STATUS. Both have the same format:
EVENT: DEFB 0,1 ;words 0 and 1 DEFW C0 ;Pointer to conditions DEFW A0 ;Pointer to actions DEFB 3,-1 ;Only word 3 required DEFW C1 ;Pointers DEFW Al C0: DEFB 0,1,1,2,-1 ;Must be at location 1 (0,1) ;Object 2 must be here(1,2) A0: DEFB 5,3,-1 ;Print message 3The lists of actions and conditions are terminated by a byte of 0FFH (-1). Note that the examples are only very small extracts from a real table. A full-size database may have up to 255 locations and any number of entries in the event and object tables.
Assembly listings for every processor would occupy far more space than the magazine can provide and flowcharts would not really describe the action of the program at the level of detail we want. For those reasons, the program is represented in pseudo-code.
For those not familiar with the term, pseudo-code is a non-existent language or shorthand representation of a program often used by programmers for detailed design when the actual target language is not yet known. Pseudo-code provides far more detail than flowcharts and is, in fact, detailed instructions for the actual coding of the program.
Although the listing should be more or less self-explanatory, it's worth mentioning two conventions used. If a variable is preceded by a "@" it means that the variable is used as a pointer to the data. For example, if "HL" contains the value 100 and we say "A=@HL", "A" is loaded with the contents of memory location 100.
A Similar convention is used to identify the address of a variable except the "#" character is used - also used by the IF statement for not equal to. For example, if we say "HL=#OBJLOC", it means that the variable HL is loaded with the address of OBJLOC and not the contents.
Variables used are defined as either BYTE, 8-bit, or WORD, 16-bit, and the contents are assumed to be set to zero unless a value is included between two 'P's. For example, to define two 8-bit variables in memory, one set to zero and the other to 3 we use:
BYTE VARA,VARB/3/A memory block is reserved by:
BYTE VARC/<7>/which means reserve seven bytes of memory starting at label "VARC".
That leads to the implementation of arrays used by the program. All references to arrays mean an offset to the base label of a memory area. For example, VARC(3) simply means the address found by adding three to the value of label VARC.
Thus VARC(0) is exactly equivalent to VARC. Remember that words occupy two bytes, so, if VARC was a word array, VARC(3) would actually be addressing VARC + 6 and also VARC + 7 for the top byte.
Knowing this, you should now be able to produce a version of the program for your particular system by working through the listing and generating the appropriate assembly code for your machine. If you have access to a medium-level language; such as PL/M for example, that is of course, equally acceptable.
The pseudo-code program shown here has in fact been compiled by a specially-written compiler to ensure that it is sound.
Let us work through the program considering what makes it tick and explaining the meaning of the pseudo-code representation.
Referring to the listing, we can see that the first section is simply the definition of items not within this listing, that is the items marked "GLOBAL". Four subroutines not described here are called, but as these are relatively simple entities they should present no problem in coding.
The first subroutine required is called "$REPLY" and it is simply a routine to read a response from the user and return a value of one if it was a "Y", and a value of zero if it was a "N". The routine should check that either a "Y" or a "N" was entered and prompt "PLEASE ANSWER YES OR NO" for any other reply.
The second routine is named $MESS and is the routine used to print messages on the console. It must take the ADDRESS of a message as a parameter and print all the bytes found there until a byte with the most significant bit set is encountered. The routine used also had the additional feature that it printed a return/line feed if it was called with an address of zero.
The next routine, $LINE, is the opposite of $MESS; it obtains a line from the user and passes back the address of the stored text.
It can be done by reading the refresh register if you have a Z-80 system, or if your keyboard is software controlled, you may increment a counter in, the keyboard - wait loop and use that value as the random number. If you want a more elegant solution, the random numbers used in the prototype program were generated using the algorithm:
[Generated number] = 11x[Last generated number] + 999 MOD 101although this does require 16-bit multiply and divide.
The next group of globals refer to the addresses of the various tables in the database.
A further point is that some items are used for temporary storage only and may be replaced by the processor registers if you desire. The only variables that must be in memory are Here, the current location and User, the variables the data- base may access. If you run out of registers, remember they may be saved on the stack while a register is used for something else.
Proceeding to the code, we can see that the program begins at label "Start" which simply sets the first location to zero. The code beginning at "Desc" describes the current location by printing the description found adding the contents of 'HERE' to the base address LOCTXT and using the pointer there
The current location will, of course, change as the game progresses. A small piece of code checks to see if the database has set user flag zero and if so, we are in dark locations and object zero must be present (a lamp) to obtain the location description. Otherwise the message "Everything is dark. I cannot see" is displayed.
The code then goes onto scan through the object location table "Objloc" and if any objects position is the same as the current position "Here", the object description is printed.
Next, the program looks quickly as the status table which is effectively the computer's turn at the game. However, as the same mechanism which decodes the player's command is used, we will consider it later. That function, when completed returns to the label "PROC".
The routine that obtains a line from the user is called ($LINE) and the address of the entered text obtained. The routine used returned the address on the top of the stack and the instruction "HL = @ SP" finds that address.
That reduction of the line allows complex sentences like "TURN ON THE LAMP" to be reduced to simpler entities like "ON LAMP", provided the words TURN and THE are not in the vocabulary. Hence it is important to consider carefully which words are not in the vocabulary as well as which ones are.
If none of the entered words is found in the vocabulary, the message "I don't understand" is printed and we go and obtain another line from the player.
After we have converted the user's command into one or two single-byte codes, we take the first code and see if it is one of the words which cause movement at the location. If it is the current position (HERE) is updated and we return to label "MOVED" to describe the new place. If it is not, we proceed to examine the main event table to see if there is an entry there.
If the first word code '"W1"' matches the first byte of an entry and "W2" matches the second byte, we proceed to extract the conditions and test them. If all the conditions are satisfied, we extract the list of actions and execute them.
If all the conditions do not match or the two-word codes do not match, we try the next entry in the table. That is repeated until an explicit command to leave the table is given-or the table is exhausted.
The action or condition is decoded by using it as an index into a list of addresses for the function we want and simply moving the address to the program counter (PC). It can usually be done on most machines by pushing the address on to the stack and executing a return from subroutine instruction.
The comments in the program listing explain the operation in greater detail and indicate what actions and conditions are available.
Looking at some examples of a database should further clarify the operation of the program. To make the database more readable, the example extracts shown below were produced using a macro assembler and calling various macros to make the entries in the appropriate table.
VOCAB:: TABLE <SOUT> ,1 TABLE <S> ,1 TABLE <EAST> ,2 TABLE <E> ,2 TABLE <WEST> ,3 TABLE <W> ,3 TABLE <NE> ,4 TABLE <NW> ,5 TABLE <SE> ,6 TABLE <SW> ,7 TABLE <UP> ,8 TABLE <U> ,8 TABLE <DOWN> ,9 TABLE <D> ,9 TABLE <NORT> ,12 TABLE <N> ,12 TABLE <END> ,13 TABLE <TOP> ,13 TABLE <QUIT> ,13 TABLE <ABOR> ,13In the objects shown here, note how items which can change state are two objects although only one of the pair may exist at any given time.
OBJECT 0, <0,8>, <A lit lamp> OBJECT 1, <S7,0>, <An old oil lamp> OBJECT 2, <S5,0>, <A small cloth bag> OBJECT 3, <S5A,0>, <A bottle of holy water> OBJECT 4, <0,8>, <An empty bottle> OBJECT 5, <0,8>, <A match> OBJECT 6, <0,8>, <A spent match>The first byte of the location information is used to mark the location of the object. If the second byte is non-zero, the object is at one of the special places. These are:
2 - Object is carried  4 - Object is worn  8 - Object does not exist (yet) The value in "" indicates the number obtained when the two bytes are considered as a single 16-bit word.
LOC S0, <HELP,S1,BEGI,S2> TXT <Welcome to Adventure!> TXT <If you know what to do type BEGIN otherwise type HELP> LOC S1, <BEGI,S2> TXT <I have managed to get myself lost in the forest on my> TXT <quest for the seven golden keys of Waydor and don't know> TXT <what to do next. So it is up to you to help me.> TXT <> TXT <Give me your instructions and I will obey. For example,> TXT <if you want me to go to the north. Type "Go NORTH", if> TXT <we should come across some keys and you want me to get> TXT <them, type "GET THE KEYS".> TXT <Some other words that you may find useful are:> TXT <INVENTORY to find out what I'm carrying> TXT <QUIT to give up.> TXT <> TXT <Type "BEGIN" when you are ready to start.> LOC S2, <S,S4,PATH,S4> TXT <I am in a clearing in a very dense forest.> TXT <There is a path leading off to the south.> LOC S5, <N,S2,E,S5,W,S6> TXT <I am at a "T" junction with exits to the north, west and east> LOC S5, <W,S4,EXIT,S4,E,S5A,ALTA,S5A> TXT <I am amongst the ruins of a church. At the far end there> TXT <are the remains of an altar. The exit is to the west.> LOC S5A, <EXIT,S5,W,S5> TXT <I'm beside the altar.> LOC S6, <E,S4,IN,S7,CRYP,S7> TXT <I'm outside the entrance of a crypt.> LOC S7, <EXIT,S6,DOOR,S6> TXT <I'm in a vaulted chamber. Thick cobwebs hide the ceiling. TXT <There is an empty coffin in the corner and a passage leading> TXT <off into darkness to the north.> LOC S8, <D,S9,STEP,S9> TXT <I'm at the top of a steep flight of steps. I can see a> TXT <dim light to the south.>The event table is the real heart of the database as it contains the actions performed by each command from the user. This section also contains the various messages which may appear under database control.
EVT 2 <N,-1> <0,S7,-l> <9,0,8,S8,6> EVT 3 <S,-1> <0,S8,-1> <10,0,8,S7,6> EVT 4 <GET,LAMP> <1,0,-1> <2,0,13> EVT 5 <GET,LAMP> <1,1,-1> <2,1,13> EVT 6 <DROP,LAMP> <1,0,-1> <3,0,13> EVT 7 <DROP,LAMP> <1,1,-1> <3,1,13> EVT 8 <LIGH,LAMP> <1,1,1,5,-1> <11,0,11,5,5,11,18,-1> EVT 9 <OFF,LAMP> <1,0,-1> <11,0,13> EVT 10 <LIGH,LAMP> <1,1,-1> <5,14,-1> Status: EVT A <-1,-1> <7,5,5,0,2,10,-l> <5,7,15,2,8,9,5,-1> EVT B <-1,-1> <6,2,1-1> <5,8,12> EVT C <-1,-1> <5,2,-1> <5,5,-1> EVT Z <-1,-1> -1 7 MSG 5,<I feel sick and dizzy!> MSG 7,<Some one has lept out of the shadows and BITTEN MY NECK!!!!> TXT <He vanished as suddenly as he appeared!> MSG 8,<Everything is getting dark! I Think I'm dy...> MSG 11,<I have lit the lamp with the-match which has now burned out> MSG 14,<1 don't have anything to light it with.>It is worthwhile examining some of the entries in the table in detail to show just what can be accomplished in the database. For example in the location S7 shown, there is a passage leading north, but there is no entry in the movement list for it.
That is because rooms past there are dark and we want to tell the program. So let us look at entry 2. The word codes which must match are "N" (north) and anything will do for the second. There is a single condition, namely that he must be at location S7. If that is so, actions are performed which are: 9,0 - Set flag zero; 8,S8 - Go to location S8; 6 - Describe the location and obtain another command from the player.
An informative message is also printed. The final command (18) aborts the scanning of the table as a little later in the table, there is an entry for LIGHT LAMP when no match is present - which gives message 14 - and we do not want to fall through to it if we have already lit the lamp.
The table is terminated by a word code of zero. Note that in the example the words GET, DROP etc., are shown but in a real table the word code is used.
The entries in the STATUS table show an example of how a "wandering monster" may be implemented. The conditions are: Flag 5 must be zero; he must be in "dark" locations and 10 percent probability will generate the actions. The actions are: print message 7; store 8 in flag 2 - counted-down by the program - and set flag 5 to prevent more vampires.
The program should fit in less than 4K but you will find that the descriptive text, particularly for locations, will eat memory.
In terms of software, all you need are an editor and an assembler. However, if you have access to a disc-based system, all the better. Perhaps the best way to go about it is through your local computer club working on the program as a team and generating your own adventures.
As the database is pure data, any database will run on any machine - providing there is enough memory. However, the program still needs to know the position of the tables in memory.
ORG 2000W ;start of program LOCTXT EQU 200H ;Define table address VOCAB EQU 1000H ;ETC for rest of tables OBJLOC EQU 50HAnother approach would be to make the tables of a fixed length and define specific addresses for them. That removes the need to re-assemble the program for each database but does not use memory very efficiently.
Unfortunately, Adventure is not the kind of game you can describe in such a way that the program can be blindly copied and played. However, I hope that the description given here will allow anyone to implement it on his system. If you're wondering if it is worth the effort, ask anyone who has played before.
! ************************************************ ! * ADVENTURE * ! * * ! * Programmed by - K Reed * ! * Date - 12-May 80 * ! * * ! ************************************************ BEGIN DATA ! External subroutines ! $REPLY - Gets a YES/NO response from the user ! $MESS - Output to console ! $LINE - Read a line from the console ! $RAND - Get a random number (Range 1-100) GLOBAL $REPLY,$MESS,$LINE,$RAND ! Driving database labels ! Message - User messages ! Vocab - Basic vocabulary ! Loctxt - Location descriptions ! Objloc - Object locations ! Objtxt - Object descriptions ! Event - Main event table ! Movemt - Location movements ! Status - Status check table GLOBAL Message,Vocab,Loctxt,Objloc,Objtxt GLOBAL Event,Movemt,Status WORD Here,HL,BD,DE,Rnum,I,J,User/<15>/ BYTE Flag,W1,W2,Btemp,Ctemp,Domeit BYTE Word1/<4>/,Space/' '/,Cret/0/,Bneg1/-1/,Bzero/0/ END DATA PROGRAM Adventure Start: here=0 ! Start at location 0 Moved: CALL $mess(0) ! New line ! User flag 0 when set indicates a dark location ! He cant see unless object 0 is here ! Note that Objloc(0) is equivalent to simply Objloc Desc: BEGIN IF (User#0) IF (User(3)#0)User(3)=User(3)-1 IF (Objloc=Here)GO TO Seen ! Object here IF (Objloc=512)GO TO Seen ! Carried TYPE 'Everything is dark. I cannot see' IF (User(4)#0)User(4)=User(4)-1 GO TO Command ENDIF Seen: CALL $MESS(Loctxt(HERE)) ! Describe Here Look: Flag=0 ! List objects here I=0 Look1: IF (objloc(I)=-1)GO TO command ! End of objects IF (objloc(I)#here)GO TO next BEGIN IF (Flag=0) ! Object here CALL $mess(0) ! New line TYPE 'I can also see' Flag=1 ! That message only once ENDIF CALL $mess(objtxt(I)) ! Describe object CALL $mess(0) Next: I=I+1 ! Next entry GO TO look1 Command: HL=$Status ! See if anything happens GO TO Active Proc: ! Returns here IF (User(2)#0)User(2)=User(2)-1 ! Count down active CALL $RAND(#Rnum) ! Keep random spinning CALL $Mess(0) CALL $Line ! Get a line HL=@SP ! Point to it GETWD: CALL Lookup(#W1) ! See if we know it BEGIN IF (W1=Bneg1) ! Not found in table BEGIN IF (@HL=Cret) ! No more words Err1: Type 'I just don't understand what you mean' BEGIN IF (Word1>90) TYPE 'Perhaps if you used UPPER CASE' ENDIF GO TO Command ! Try again ENDIF Scan: BEGIN IF (@HL=Space) ! Next word HL=HL+1 GO TO getwd ENDIF IF (@HL=Cret)GO TO Err1 ! No more words HL=HL+1 GO TO Scan ENDIF ! If we fall out here we have a known word in W1. Now see ! if we can find one for word number 2 W2=Bneg1 ! No word yet Scan2: IF (@HL=Space)GO TO Second ! Found one IF (@HL=Cret)GO TO Allin ! No more HL=HL+1 GO TO Scan2 Second: HL=HL+1 ! Point to word CALL Lookup(#W2) ! See if an object BEGIN IF (W2=Bneg1) ! Not found Scan3: IF (@HL=Cret)GO TO Allin IF (@HL=Space)GO TO Second ! Another word found HL=HL+1 GO TO Scan3 ENDIF ! See if this word causes a change of location Allin: HL=Movemt(Here) ! Point to movements Moveit: IF (@HL=Bneg1)GO TO Nomove ! End of list BEGIN IF (@HL=W1) ! Entry found HL=HL+1 ! Point to dest Btemp=@HL ! Go there Here=Btemp ! Keep to bytes GO TO Moved ENDIF HL=HL+2 ! Next entry GO TO Moveit Nomove: ! Look up the words in the main event table to see ! what (if anything) happens HL=#Event ! Point to table Doneit=0 ! Clear flag Active: BEGIN IF (@HL=Bzero) ! End of table IF (Doneit#0)GO TO Command ! We did something BEGIN IF (W1<13) ! Explicit movement TYPE 'I cannot go in that direction' ELSE TYPE 'I cant' ENDIF GO TO Command ! Get another command ENDIF IF (@HL=Bneg1)GO TO Entry ! Any match IF (@HL=W1)GO TO Entry ! Exact match HL=HL+6 ! Next entry GO TO Active Entry: HL=HL+1 ! Point to 2nd word IF (@HL=Bneg1)GO TO Match ! Any match IF (@HL=W2)GO TO Match ! Exact match HL=HL+5 ! Next entry GO TO Active Match: HL=HL+1 ! Condition pointer BC=@HL ! Get it HL=HL+2 ! Point to actions Check: IF (@BC=Bneg1)GO TO Doit ! End of conditions Btemp=@BC ! Get this condition BC=BC+1 ! Next operand Ctemp=@BC ! Preload PC=TABLE1(Btemp) ! Computed GO TO C0: IF (Ctemp=Here)GO TO passed ! Check current location Cont: HL=HL+2 ! Next word pair GO TO Active ! Try next table entry C1: IF (Objloc(Ctemp)=HereGO TO passed ! Object present IF (511<Objloc(Ctemp)<1025)GO TO passed GO TO Cont C2: CALL $RAND(#Rnum) ! Probable event IF (Ctemp>Rnum)GO TO passed GO TO Cont C3: IF(Objloc(Ctemp)=Here)GO TO Cont ! Object not here IF (511<Objloc(Ctemp)<1025)GO TO Cont GO TO passed C4: IF (Objloc(Ctemp)#1024)GO TO passed ! Object not worn GO TO Cont C5: IF (User(Ctemp)=0)GO TO Cont ! Flag not zero Passed: BC=BC+1 ! Next condition GO TO Check C6: BC=BC+1 ! Check flag value Btemp=@BC ! IF (User(Ctemp)#Btemp)GO TO Cont GO TO Passed C7: IF (User(Ctemp)#0)GO TO Cont ! Flag zero GO TO Passed C8: IF (Objloc(Ctemp)#512)GO TO Cont ! Object carried GO TO Passed ! Condition met so perform actions Doit: BC=@HL ! Point to actions HL=HL+2 ! Point to next entry Doneit=1 ! Say we've done something Nxtact: IF (@BC=Bneg1)GO TO Active ! All done Btemp=@BC ! Get action BC=BC+1 ! Point to next Ctemp=@BC ! Preload value PC=TABLE2(Btemp) ! Computed GO TO ! In the following TABLE3 is simply a continuation of TABLE2 ! and not a separate entity. It is done this way to keep the ! compiler happy as it can't handle continuation lines BEGIN DATA WORD TABLE2/A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,A10/ WORD TABLE3/A11,A12,A13,A14,A15,A16,A17,Done/ END DATA A0: TYPE 'I have with me' ! Inventory Flag=0 I=0 Inven: IF (Objloc(I)=-1)GO TO inven0 ! End of list BEGIN IF (511<Objloc(I)<1025) ! Carried Flag=1 CALL $mess(objtxt(I)) BEGIN IF (Objloc(i)=1024) ! Worn TYPE ' which I am wearing' ELSE CALL $mess(0) ! New line ENDIF ENDIF Nextob: I=I+1 GO TO inven Inven0: IF (Flag=0)TYPE 'Nothing at all' GO TO Done A1: BEGIN IF (Objloc(Ctemp)#1024) ! Remove worn object TYPE 'I am not wearing it' GO TO Done ENDIF BEGIN IF (User(1)=4) ! Hands full TYPE 'I cant. My hands are full' GO TO Done ENDIF Objloc(Ctemp)=512 ! Say carried User(1)=User(1)+1 ! Update tote GO TO Nxtop A2: BEGIN IF (User(1)=4) ! Pick up object TYPE 'I cannot carry any more' GO TO Done ENDIF BEGIN IF (Objloc(Ctemp)=Here Objloc(Ctemp)=512 ! Say carried User(1)=User(1)+1 ! Update total GO TO Nxtop ENDIF TYPE 'Im already carrying it' GO TO Done A3: BEGIN IF (Objloc(Ctemp)=Here) ! Drop object TYPE 'I don't have it' GO TO Done ENDIF IF (Objloc(Ctemp)=512)User(1)=User(1)-1 Objloc(Ctemp)=Here GO TO Nxtop A4: BEGIN IF (Objloc(Ctemp)=512) ! Wear it Objloc(Ctemp)=1024 ! Say carried User(1)=User(1)-1 GO TO Nxtop ENDIF BEGIN IF (Objloc(Ctemp)=1024) TYPE 'I am already wearing it' ELSE TYPE 'I don't have it' ENDIF GO TO Done A5: CALL $Mess(Message(Ctemp)) ! Type message GO TO Nxtop ! Get next action A6: GO TO Desc ! Describe location A7: GO TO Proc ! Procede A8: Here=Ctemp ! Immediate move GO TO Nxtop A9: User(Ctemp)=255 ! Set flag GO TO Nxtop A10: User(Ctemp)=0 ! Clear flag Nxtop: BC=BC+1 GO TO Nxtact A11: DE=Objloc(Ctemp) ! Swap objects Objloc(Ctemp)=Objloc(Ctemp+1) ! Move 1st object Objloc(Ctemp+1)=DE ! Move 2nd object GO TO Nxtop A12: STOP ! Stop the program A13: TYPE 'Okay' ! Say okay GO TO Done ! And procede A14: TYPE 'Are you sure you want to quit now' CALL $reply(#i) IF (I=0)GO TO Nxtact STOP 'Okay ... bye' A15: BC=BC+1 ! Store value in flag Btemp=@BC ! Get it User(Ctemp)=Btemp GO TO Nxtop A16: Objloc(Ctemp)=Here ! Create object GO TO Nxtop A17: Objloc(Ctemp)=2048 ! Destroy object GO TO Nxtop Done: GO TO Command ! Lookup - Find word in table ! Each entry consists of a four byte name ! followed by an byte identification code. Eg 'FRED',2 ! this code is returned if found, otherwise -1. SUBROUTINE lookup(DE) LOOP J=0 TO 3 ! Clear out word Word(J)=Space ENDLOOP J LOOP J=0 TO 3 ! Extract 1st 4 letters IF (@HL=Space)GO TO Gotwrd ! End of word IF (@HL=Cret)GO TO Gotwrd ! End of word Word(J)=@HL ! Get character HL=HL+1 ENDLOOP J Gotwrd: BC=$Vocab ! Point to table @DE=Bneg1 ! Assume no match Find: Flag=0 ! fndit Flag LOOP I=0 TO 3 ! 4 bytes IF (@BC=Bneg1)RETURN ! End of table IF (Word1(I)#@BC)Flag=1 ! No match BC=BC+1 ENDLOOP I BEGIN IF (Flag=0) ! Matched Btemp=@BC ! Get ID @DE=Btemp ! Pass it to caller RETURN ENDIF BC=BC+1 ! Skip over ID GO TO Find ! And try again END(Practical Computing - August 1980)