Program: T. J. Gilberts, Graeme Yeandle and Phil Wade
Manuals: T. J. Gilberts and Graeme Yeandle
The PC Adventure Writer (PAW) provides you with the facilities to produce text adventures on an IBM compatible PC.
PAW will provide you with the basic framework for writing a game, but it is still up to you to provide an imaginative storyline and original puzzles.
The manuals supplied with PAW cover all aspects of its use. This manual provides a tutorial covering the construction of an adventure and we would recommend you work your way through it and it's accompanying examples before attempting a game of your own.
The other manual (Technical Guide) provides a detailed breakdown of the entire system and can be used as a reference guide while writing your own games.
Good luck...
A great deal of time and effort has been put into ensuring PAW deals with all conceivable situations in a logical and useful manner. This has resulted in a complex program, and it is entirely possible that somewhere deep within the code a few well hidden bugs remain. Indeed a well known quote states that; "Testing only proves the presence of bugs, not their absence". If you should find a problem please tell us so that we can correct it if necessary.
To create your adventure you will need a Text Editor or Word-Processor that can be used to produce 'Non-Document' files, i.e. text files without control codes. Notepad or Programmers File Editor (PFE) are suitable examples.
Although you can use a windows based text editor you will need to use a DOS prompt to be able to run the compiler or interpreter.
parse v.t. to classify a word or analyse a sentence in terms of grammar. parsing n. (Minster English dictionary)
PAW features a fairly powerful parser to convert what the player types when playing your adventure into a series of simplified 'Logical Sentences' (LS's) to which you will have defined the responses. The parser does this by extracting 'phrases' from the input string one at a time and allowing the rest of PAW to interpret their meaning. Phrases are separated by any punctuation mark and the conjunctions 'AND' or 'THEN' - although you can change this if required. When it runs out of phrases in the current input string it will request another. A phrase consists of at least a Verb (a doing word!), optionally two Nouns (words which name objects) possibly with associated Adjectives (which describe objects), an adverb (which modifies the verb), a preposition (shows the relation of one Noun with another word) and finally a string enclosed in quotes that is used for speech to other characters in the adventure.
To illustrate the recommended approach to writing an adventure we will consider the design and development of a simple game from initial idea to final testing.
Subjects for adventures are all around in many day to day actions, in exotic places around the world and out of this world!
If you decide to base a game on a book or film you have enjoyed, and intend using it commercially, make sure you have obtained permission from the original author or copyright owners.
For our sample we will use a simple problem which besets a passenger on his/her way home:-
While standing at the bus stop the passenger's ticket blows away in the breeze and is carried away by a small bird into an adjacent park. The computer will play the part of the passenger who you must direct to find the ticket before the bus arrives.
diagram 1
An adventure consists of a number of 'discrete' that is separate, 'locations' or places the player can visit. Each location must be allocated a number as in diagram 1.
Try to make the scale consistent or logical (unless the game is illogical by intent!) as a single step to an airport earlier described as 10 miles away doesn't help the impression of realism. You can introduce a method of transport such as a taxi, etc., if needed. Now location 0 is always reserved as a title screen for a game, and we want location 1 for a special use later, so we have numbered the locations from 2 upwards.
For our example we have chosen 7 locations as follows:-
2 The Bus Stop.
3 On the Grass.
4 By the Bench.
5 The Bandstand.
6 The Ornamental Pond.
7 By the Tree.
8 Up the Tree!
Now we can start to write the textual description of each location. Try not to make them a dry and uninteresting monologue on the state of the nation. Short and snappy is just as effective in creating an atmosphere if a little imagination is brought to bear. Remember to stick to one form of address ('I' or 'You' usually) or the player will suffer a serious identity crisis. Note that if you use 'You' as a form of address you will need to change the system messages - see the technical guide for details.
The source file consists of a number of sections that describe the adventure. Let's take a quick look at the source file to see what's there. The first line is a comment, which tells us that this is a START source file and the date it was last altered. Any line that starts with a semi-colon is a comment. Comments are totally ignored by the compiler and thus take up no room in the database file when it is produced. Copious comments will help you remember what is going on in your game.
The CONTROL section begins with a line that starts with '/CTL' and gives some control information for the compiler.
The VOCABULARY section begins with a line that starts with '/VOC' and defines all the words which PAW will 'understand' e.g. QUIT.
The SYSTEM MESSAGES section begins with a line that starts with '/STX' and defines the messages that the system can issue e.g. "What next?"
The MESSAGE TEXTS section begins with a line that starts with '/MTX' and defines the messages actually needed by the adventure e.g. "It's a cheese sandwich!"
The OBJECT TEXTS section begins with a line that starts with '/OTX' and defines the descriptions of all the objects in the adventure e.g. A rotten egg".
The LOCATION TEXTS section begins with a line that starts with '/LTX' and defines the descriptions to be used for every location in the adventure e.g. "You are in a prison cell. There is no way out."
The CONNECTIONS section begins with a line that starts with '/CON' and defines the connections between every location in the adventure.
The OBJECT DEFINITION section begins with a line that starts with '/OBJ' and defines every object in the adventure e.g. Object 0 starts the adventure being carried and has a weight of 1 unit, it is not a container and cannot be worn etc.
The PROCESS TABLE section begins with a line that starts with '/PRO 0' and provides the main game control. e.g. when the player types in LOOK, action DESC is done to describe the current location.
Getting back to our tutorial, firstly change the comment in line 1 to read:-
;TUTORIAL source file DD/MM/YYwhere DD/MM/YY should be replaced with the current Day, Month and Year. It is a good idea to keep track of file versions like this, so you can always tell if you are working on the latest version.
Now we are going to concentrate on the locations. Find the line which starts with /LTX and you will see that a description for location 0 already exists. The connections section, a few lines lower, also has an entry for location 0 but this is a null entry.
Change the location and connections sections so that they read as follows: -
/LTX ;Location Texts
/0 ;Intro
The Ticket
While standing on the bus stop my bus ticket has been
blown away, can you help me to find it?
/1
I'm inside the bag!
/2
I'm standing by a bus stop, on a road that runs North to South.
To the West a park gate set in iron railings stands open.
/3
The grass on which I stand is neatly trimmed.
To the North is a path and bench while to the West is an
ornamental pond.
/4
I am on a gravel path running East to West, by a park bench,
to the South is a grassy area while to the North I can see a
bandstand.
/5
I am standing on the bandstand that appears to be made of
ornate cast iron painted white. To the South is a path.
/6
The sun glitters on the surface of the ornamental pond,
whose waters ripple in the gentle breeze.
A path runs North towards a large tree, while to the East
is a grassy area.
/7
The path curves South and East here beside a large tree.
/8
I am sitting on a branch in a broad leafed tree,
the park is spread out before me, and to the West I can
see the bus stop through the gate in the railings.
; - - - - - - - - - - - - - - -
/CON ;Connections
/0 ;Start of game
N 2
/1 ;In bag
/2 ;Bus stop
W 4
/3 ;By bench
N 4
W 6
NW 7
/4 ;Path
N 5
E 2
S 3
SW 6
W 7
/5 ;Bandstand
S 4
SW 7
/6 ;Pond
N 7
NE 4
E 3
/7 ;By tree
U 8
NE 5
E 4
SE 3
S 6
/8 ;Up the tree
D 7
; - - - - - - - - - - - - - -
The Ticket
While standing on the bus stop my bus
ticket has been blown away, can you help
me to find it?
Check these entries thoroughly against diagram 1 until you are sure they are correct then save TUTORIAL.SCE, and exit back to DOS so that we can try the compiler. Assuming that PAWCOMP.EXE and TUTORIAL.SCE are in the same directory and that it is your current directory you need to type:
PAWCOMP TUTORIALto compile the adventure as it stands at the moment. We have not included any deliberate errors so you should eventually get a message saying "Compilation ends OK" and a file called TUTORIAL.PDB. If you get any errors or warnings you will have to correct them and recompile the source file. Note that you can redirect the compilation listing to a file if you prefer by specifying PAWCOMP TUTORIAL >TUTORIAL.PRN which will create TUTORIAL.PRN. Another option is to pipe the output through MORE to stop it scrolling so quickly, using the command PAWCOMP TUTORIAL|MORE. If you get really stuck with errors in the source file then the file TICKET.SCE may help you but note that this file contains the whole tutorial adventure.
Note. An extremely common mistake, which can cause apparently unfathomable problems, is inserting a blank line! Particularly a blank line between the end of one section of the source file and the header of the next. i.e. above the /VOC, /PRO etc., lines. Or a blank line anywhere in the /CTL section which PAW will get very upset about!
PAWINT TUTORIAL
The screen should be cleared and at the top it should say something like:-
The TicketThe input line is used to enter commands for PAW to interpret into things to do - according to the information you have entered when writing your game. So far we have only told it where to take us when certain directions are entered. So try starting the game properly by typing NORTH or N.
While standing on the bus stop my bus
ticket has been blown away, can you help
me to find it?
What now?
>
The screen will clear and the description for location 2 will appear - if it doesn't you probably have the entry in the connections section wrong. Don't worry, you can leave the Interpreter by typing QUIT (which is a command PAW knows to start with) and replying Y; you do want to quit and N; you don't want to try again; then you can correct the entry, recompile and try again.
You can now try moving between your locations, testing the possible moves (make a note of any that are wrong so that you can correct them).
You might also like to try some of the other commands which PAW knows, e.g. R or REDESCRIBE will display the location description again - which is useful if a lot of text has been output and the description lost. I or INVENTORY will list the 'objects' you are carrying, you will be carrying one object to start with but will be able to do nothing with it.
You are probably dying to see the parser in action by now (why not?) so if you work your way back to the bus stop and enter the following line you will get a flying visit round the game!
GO WEST THEN NORTH THEN SW THEN UP AND DOWN THEN SOUTH AND EAST THEN NORTH THEN EAST. INVENTORY
By the way W.N.SW.U.D.S.E.N.E.I will have the same effect but doesn't look half as impressive...
When you have had enough enter QUIT to leave the Interpreter.
We need a quick mention of the diagnostics program now. If instead of running PAWINT TUTORIAL you run PAWINTD TUTORIAL you will be using a modified version of the Interpreter which includes diagnostics. In this program if you press ENTER without typing anything in first, the Interpreter will be switched into diagnostics mode and you will see a line something like:-
Flag 38=2 ?
which shows you the value of flag 38. There are two things to be learnt here. Firstly, pressing ENTER again (without typing anything in first) will switch the Interpreter out of diagnostics mode. Secondly, that flag 38 always contains the value of the current location, i.e. 2 in the example above.
Right back to the boring bit, QUIT from the game so that we can deal with the next chapter in this saga.
In our simple game we will have the following objects (not all of which have a function in the final game).
Object 0 A lit torch.
Object 1 A bag.
Object 2 A sandwich.
Object 3 An apple.
Object 4 A ticket.
Object 5 A lead.
Object 6 An anorak.
Object 7 An unlit torch.
Note that the torch is in fact two separate objects which we could swap over if the player turned it on or off.
Start editing TUTORIAL.SCE again and find the line that starts with /OTX. You will see that a description for object 0 already exists. Change the object text section so that it reads as follows:-
Point to note:-/OTX ;Object Texts /0 A lit torch. /1 A bag. /2 A sandwich. /3 An apple. /4 A ticket. /5 A lead. /6 An anorak. /7 An unlit torch. ; - - - - - - - - - - - - - -
Points to note:-/OBJ ;Object Definitions ;obj starts weight cont- wear/ noun adjective ;num at ainer remove /0 _ 1 _ _ TORCH LIT /1 2 3 Y _ BAG _ /2 CARRIED 1 _ _ SANDWIC _ /3 CARRIED 1 _ _ APPLE _ /4 8 1 _ _ TICKET _ /5 3 1 _ _ LEAD _ /6 WORN 3 _ Y ANORAK _ /7 CARRIED 1 _ _ TORCH UNLIT ; - - - - - - - - - - - - - -
This is an excellent time to show you some compiler errors so save TUTORIAL.SCE and try to compile it again. (PAWCOMP TUTORIAL if you've forgotten).
When the compiler finds an error, the line number of the source file and the contents of the line are printed (when appropriate) then the error number and error reason e.g.
344 /1 2 3 Y _ BAG _ *** ERROR 5 - BAG is not in Vocabulary
We are expecting the compiler to find 8 errors so the compilation should end with the line:-
*** Compilation ends with 8 ERRORS
The 8 errors have been found because we have used words e.g. BAG that have not been defined in the vocabulary section. Guess which section we are going to look at next!
Each entry for a word consists of up to five letters which will either be a complete word e.g. NORTH or the first five letters of a longer word e.g. ASCEN(D), a word value and a word type (e.g. Noun, Verb etc).
The use of only five letters to store a word reduces the amount of memory required to store the entire vocabulary, the amount of typing the player must do and makes PAW faster at looking up words when required. Five letters is also more than adequate to differentiate the majority of important words in the English language from each other.
Start editing TUTORIAL.SCE again and find the vocabulary section - /VOC. You should be able to see that each entry consists of a word followed by a word value and a word type e.g.
PAW understands 7 types of word i.e. noun, verb, adjective, adverb, preposition, pronoun and conjunction.N 2 noun
If you look at the first part of the vocabulary section you should be able to find all the directions that we used in the connections section (e.g. N & SW). Note that any words with the same word value and the same word type are regarded as synonyms, i.e. they mean the same thing e.g. N & NORTH are synonyms. It does not matter which order the words are defined in the vocabulary section. We have chosen to group all the adverbs together and all the adjectives together etc..
We need to increase the number of Nouns by inserting a word for each of our objects. Now the first free number appears to he 15, but Noun values less than 50 have special meanings thus;
Nouns less than 50 are Proper Nouns, for example people's names or places. More specifically for PAW they are Nouns which will not affect the subject of 'it'. Take the sentence:-
GET THE SWORD AND CLEAN ITIT (a word known as a pronoun) refers to the SWORD obviously. PAW will (as long as SWORD is a Noun in the vocabulary with a value greater than 49) know this, and assuming you have dealt with the possibility of cleaning the sword, allow you to do so. But take the following sentence:-
GET THE SWORD AND KILL THE ORC WITH IT THEN DROP IT.Normally PAW assumes 'it' to be the last used Noun but as long as ORC is a Noun in the vocabulary with a word value less than 50, PAW will remember 'it' as being the sword, and carry out the action correctly. This feature is noted in the comments along with mention of word values less than 20. These are Nouns, which if PAW cannot find a Verb in a 'phrase' containing one, will convert temporarily (i.e. it does not change the vocabulary) into a Verb. The major use of this is for things like NORTH which may be typed on their own implying GO NORTH, which in normal English is invalid but is common when playing adventures.
Finally verbs and nouns less than 14 are assumed to be movement words - any word which is a direction. This merely determines the message that will be printed if PAW cannot do anything with the phrase it has found (i.e. it determines if "I can't" or "I can't go in that direction" is displayed). Note that this tag of 'less than 14 is a movement' applies to both Verbs and conversion Nouns.
Since all our objects are 'its' we must give them word values greater than 49 as follows:-
Note that there are two words with value 54. This makes BUS and TICKET synonymous so if the player types GET BUS TICKET or GET TICKET, PAW will know they mean the same thing.TORCH 50 noun BAG 51 noun SANDW(ICH) 52 noun APPLE 53 noun BUS 54 noun TICKE(T) 54 noun LEAD 55 noun ANORA(K) 56 noun
We also need some words to describe the difference between our two torches to PAW. The words that describe a Noun are called Adjectives. We need two extra adjectives LIT and UNLIT as follows: -
All word values from 1 to 254 are available for each type of word and there is no limitation on the number of words with the same word value (synonyms), so the vocabulary can become quite large if you want.LIT 10 adjective UNLIT 11 adjective
Alter the vocabulary section to include our extra 8 nouns and 2 adjectives, save TUTORIAL.SCE and compile it again. Correct any errors and recompile until there are no errors or warnings.
PAW contains 256 of what are known as 'flags'. Each flag can be used to contain a number from 0 to 255 and is used to indicate (or flag!) the state of some part of the game. As an example you could decide that flag 11 when set to 1 meant that the park gate was closed, and when set to 0 meant it was open. We will see examples of the way flags can be set and used in the next section.
PAW has set aside several of the flags to indicate specific things (flags 0 to 10 and 29 to 59 actually). The value displayed is the contents of flag 38 that PAW knows is your current location e.g.
You can look at the values of other flags by typing their number before pressing ENTER again. Try 100 to look at flag 100, which will display:Flag 38= 2 ?
A very powerful feature allows you to set the value of a flag by putting = in front of the number. Try =10 ENTER and the line should be redisplayed as:Flag 100= 0 ?
Flag 100 does nothing in our game and its value is unimportant, but if you decide to practice on your own do not change the values of any other flags for the moment or you may get some funny effects if you happen on a flag which is important. Return to the input line when you have finished (press ENTER) so that we can see what else PAW can do.Flag 100= 10 ?
We should now be able to manipulate the objects in the game. At the moment the bag will be at the bus stop with us. We will be carrying the sandwich, apple, unlit torch and wearing the anorak.
Use the diagnostics to look at the value in flag 1. This has the value 3, which is the number of objects carried but not worn. Return to the input line and type GET BAG. PAW will print the message "I now have the bag.", which is known as auto-reporting (PAW automatically reports any action it has carried out). This command has caused the current position of the bag to be changed from location 2 (the bus stop) to 'location' 254 (carried). Note that no change has occurred to the object definition section of the database, only to a copy of it that was made when the game started. If you look at the value of flag 1 again (notice how the flag you looked at last is displayed when you reselect diagnostics) you should find it has been increased to 4.
Now try REMOVE ANORAK and the report "I can't remove the anorak, my hands are full" will be printed. This is because PAW initially (by default in other words) allows the player to carry only four objects at any one time. This situation must prevent the player from taking off clothing etc (actually removing is changing an objects position from location 253 to location 254!) Try DROP BAG and then REMOVE ANORAK again - this time you should be able to do so. Look again at flag 1 and you should discover it is still four - this is because removing the anorak has increased the number of things you have in your 'hands'.
Try the following and see if you can work out why they do what they do:
GET BAGNotice that all except the last report actually mentioned the objects by name. This is because they were in plain sight and thus the player would know they existed. But to a player who did not know the game, the ticket has not yet been found and to mention it by name would imply that it existed or that there was only one in the whole game thus giving a clue!
REMOVE ANORAK
WEAR ANORAK
GET APPLE
GET TICKET
If you try to put anything in the bag you will discover that PAW drops that object instead. This is because we haven't yet told PAW what can be put in the bag, only that it is a container. The next chapter deals with this subject.
Finally we will find a 'bug' in our game; type GET GATE which will result in "There isn't one of those here". It shouldn't say that because the description says there is a gate here!
The problem arises because although we told PAW about the apple the sandwich, the torch and so on, we didn't tell it about the gate. If you use GET (or DROP, WEAR and REMOVE) with any word that is not in the vocabulary then PAW assumes it is an object which is 'not here'. Of course once the word is in the vocabulary, PAW will know it isn't an object (if there is no entry for the word in the object definition section) and report "I can't do that.", which is correct.
So edit TUTORIAL.SCE and insert the following vocabulary entries:-
Notice how all the ways the player can refer to the tree are catered for. We have no intention of allowing the manipulation of leaves or the branch, but if you did you would need to give them separate word values - this is an important design consideration.GATE 57 noun RAILI(NGS) 58 noun GRASS 59 noun PATH 60 noun BENCH 61 noun POND 62 noun BANDS(TAND) 63 noun IRON 63 noun TREE 64 noun BRANC(H) 64 noun LEAF 64 noun
You might like to use the Interpreter again to ensure that GET GATE does indeed produce the correct response - don't forget to re-compile TUTORIAL.SCE if you do, or the 'bug' will still be there! This arises of course because the database file reflects the state of TUTORIAL.SCE the last time it was compiled.
We have now dealt with; creating locations and connecting them together, creating and describing objects, assigning them a word from the vocabulary, a starting point in the game, a relative weight, flagging if they are wearable (and removable) and if they are a container. The next chapter goes on to create problems and characters to make the game world a more interesting place by allowing the player to do things!
Earlier we mentioned that the parser in PAW breaks sentences down into phrases, which are then organised into what is known as a LS (logical sentence). In the case of directions like NORTH (which are LS's on their own) it uses the connections section to discover where (if at all) it should move the player. Before it does that however it carries out a check against the response table to see if that table contains an entry that can deal with the LS, i.e. give a response to part of/entire command the player originally typed.
Every possible phrase the player types and therefore every LS that your game will respond to, will have a corresponding entry in the response table, except for most movements which you set in the connections section.
The most important part of a LS is the Verb, this shows the purpose of the LS, next most important is the first Noun which shows the subject of the LS; e.g. GET APPLE, GET is the purpose and APPLE is the subject.
Look at TUTORIAL.SCE and find the start of the response table. It starts with the line:-
For the moment ignore the other entries and consider the first entry only:/PRO 0...
the two words "I" & "_" indicate the Verb and Noun respectively of the LS that this entry can deal with. Now I is a conversion noun (as we saw in the section on vocabulary) which means if it is the only word the player types in a phrase, it will become the Verb for the LS. The underline (_) indicates that the Noun is not important in this entry. What this means in simple terms is that if the player types I on its own PAW will match it up with the first entry in the response table and carry out that entry as described next. In order to carry out the entry, PAW will execute each of the condacts (commands) in the list which follows. Now the first entry contains only one condact;I _ INVEN
INVEN is an action (the act part of the word condact!). It is an action because it carries out the act of listing the objects the player is carrying and wearing on the screen, you do not need to worry how INVEN does this it just does.
When you typed I (or INVENTORY which is synonymous remember) during testing the game, it was this entry in response that caused something to happen because a logical sentence of "I _" was created by the parser, which PAW then found matched the first entry in the response table.
INVEN, once it has listed any objects you are carrying, instructs PAW it has 'done' something, when PAW discovers this it asks the parser for another LS, which the parser provides by decoding the next phrase in the players input, PAW gets this LS and checks it against the entries in response and so on. This 'loop' is shown in diagram 2 in the form of a flowchart which you should follow from the box marked 'start'. The loop is slightly more complex than the diagram might lead you to believe and a complete one is given in the technical guide, but diagram 2 will do for now.
We advise you to reread the above paragraphs and study the diagram
until you are happy with the way PAW operates on LS's before
proceeding.
diagram 2
Let's consider the second entry in response:
as you might have worked out this entry deals with the phrase TAKE INVENTORY (GET is a synonym of TAKE and I is a synonym of INVENTORY). This deals with another way the player might request a list of the objects he has with him.GET I INVEN
We will skip the next few entries and move onto:
Now, QUIT is a Verb in the vocabulary. As the minimum valid phrase is a Verb, if QUIT is typed on its own by the player then the parser will generate an LS of "QUIT _". On searching through the response table PAW will find the above entry and start to carry out the condacts that follow;QUIT _ QUIT TURNS END
QUIT is a condition, (the cond part of the word condact). Do not confuse the Verb QUIT in the vocabulary with the condition QUIT. If you were to make STOP a synonym of QUIT and then delete the word QUIT from the vocabulary, then the player would have to type STOP to end the game, but the condition QUIT would still be carried out i.e. the entry would then read:
A condition merely decides if PAW should carry out the next condact in the list. QUIT determines if the next condact should be carried out by asking the player "Are you sure?". If they reply "NO" then QUIT tells PAW it has 'done' something which causes PAW to go and get another LS (i.e. it stops the QUIT) this is slightly different to the normal way a condition works as you will see later. If the player types "YES" then QUIT does nothing and allows PAW to look at the next condact in sequence which is TURNS.STOP _ QUIT TURNS END
TURNS is an action, which prints "You have taken x turn(s)." on the screen where x is the number of phrases that PAW has carried out since the player started the game. Despite the fact it has done something it does not tell PAW to stop looking at condacts and it proceeds to look at the next condact END.
END is a special action, which prints "Would you like another go?" on the screen. If the player types "YES" then END will cause the game to be restarted with all objects restored to their required position and so on. Otherwise END exits the program.
Note that you should always have an END action somewhere in the game (if you should happen to remove the QUIT entry that is) or you may not be able to exit the program very easily.
The other entries that are present in the response table deal with a number of other standard commands that the player of an adventure will usually need. The condacts used in the other entries are discussed below. You may be wondering why these entries are in the table and not part of PAW if they are needed in every game. Well apart from the fact it is easier to make them a table entry, your game might not need them and as they are a table entry they can be deleted.
DESC is an action, used by the "R _ " entry in the table, which causes PAW to abandon scanning the response table and reDESCribe the current location of the player.
SAVE and LOAD are two actions which allow the current state of the game to be saved and reloaded from disc. The current game position includes every piece of information needed to restore the game after a LOAD to exactly the same position it was before the SAVE and includes the values of flags, position of objects plus sundry other information. Again do not confuse the Verbs SAVE and LOAD in vocabulary with the actions SAVE and LOAD. You could equally as well use STORE and RECAL(L) as your vocabulary Verbs but they would still use the SAVE and LOAD actions in the response table. Note that both SAVE and LOAD effectively do a DESC action when they have finished which means any condacts which follow will be ignored and that they also cause any further phrases in a players input to be ignored.
RAMSAVE and RAMLOAD are two actions similar to SAVE and LOAD, except that they use a 'buffer' (area of free memory) to store the game position. Only one position can be stored and as it is stored in memory it will be lost if the computer is turned off, this should be made clear to the player. The number after RAMLOAD is a parameter and tells the condact how many of the flags to restore from the previous RAMSAVE, this allows scores etc to be maintained even if the player 'cheats' by using RAMSAVE and RAMLOAD in a difficult part of the game. They are both followed by a DESC action as unlike SAVE and LOAD they just continue onto the next condact.
If PAW runs out of condacts in a list without being told it has DONE something it will 'drop off' the end and realising this will continue to search response for another matching LS. We also said that QUIT was a bit different to normal conditions. Well for a start it is the only condition that asks the player for information and secondly it tells PAW something has been done if the player replies "NO" (they don't want to abandon the game) which causes PAW to get a new LS. A normal condition if it 'failed' would merely cause PAW to continue searching the response table for another entry matching the LS.
The other condacts that are used will be considered now in relation to the entries they are part of. To simplify our explanations we can consider the position of an object to be in one of four places;
| HERE: | The current location of the player (the value stored in flag 38 if you remember) |
| CARRIED: | 'location' 254, the imaginary location that is where all objects the player is carrying are stored |
| WORN: | 'location' 253, the imaginary location that is where all objects the player is wearing are stored |
| NOTHERE: | Anywhere else! This may also include 'location' 252 which is the imaginary location where any objects which do not yet 'exist' within the game are stored |
Take the following two entries in the response table:
GET ALL DOALL HERE
GET _ AUTOG
DONE
these two entries allow the player to GET an object. GETting an object involves changing its location from HERE to CARRIED.
Ignoring the GET ALL for a moment let us look at the GET _ entry, as we said earlier underline means 'any word' so no matter what Noun the player types, in the phrase containing the GET, the GET _ entry will match (this is called triggering the entry). Take the phrase GET THE APPLE; THE will be ignored because it is not in PAW's vocabulary, so the LS will be "GET APPLE", this will 'trigger' the GET _ entry resulting in PAW looking at condact;
AUTOG is an action which AUTOmatically Gets the object specified by the Noun. This is where the object definition section comes into effect. AUTOG looks through the object definition section for an entry that matches the Noun in the LS. When it finds one (APPLE in the example) it then knows the number of the object it refers to (the apple is object 3). It then ensures that the current location of that object number is HERE and if so changes it to CARRIED and prints the message "I now have the _." where the underline is replaced with the description of the current object. i.e. the one AUTOG just looked up. If it does not succeed in finding an entry then there are five possibilities;
If AUTOG succeeds then PAW looks at the next condact DONE;
DONE merely tells PAW that this entry is finished and it should go and get another LS.
Next we will look at the GET ALL entry, you may have guessed what this does (it attempts to GET all objects at the current location), so we shall explain the mechanism;
Should the player type the phrase GET ALL, the parser will create a logical sentence of "GET ALL", which will match the entry and cause PAW to look at the DOALL action;
DOALL is an action that is followed by a parameter that gives a location number to use. DOALL looks through the current location list for each object looking for entries that are at the same location as the parameter. When it finds one it looks in the object definition section to find the vocabulary word that describes that object number. This is placed in the current LS (thus replacing the Noun ALL), a flag is set to indicate that DOALL is active and the rest of response is scanned by PAW for an entry that matches the newly modified LS. This will be the GET _ entry discussed earlier, which will GET that object. Once this has been done PAW will discover that DOALL is active and go back to the GET ALL entry (actually it goes direct to the DOALL action). This allows DOALL to look for another object that generates a new LS and so on for all objects at the specified location. When DOALL runs out of objects it resets the flag to show it is not active and tells PAW to get a new LS.
This may seem a rather roundabout way to approach this task, but if you examine the very similar DROP, WEAR and REMOVE entries you will see that the same mechanism is used to create all four commands. AUTOD, AUTOW and AUTOR work in a very similar way to AUTOG while DOALL merely uses CARRIED as the parameter for DROP and WEAR (i.e. DOALL searches all the CARRIED objects when you try to DROP or WEAR ALL!) and WORN when you try to REMOVE ALL.
If the above seemed a bit heavy going don't worry about it for now as DOALL is one of the two most complex condacts in PAW and hopefully the penny will drop as we continue. At this point you might like to use the Interpreter to try out the 'all' commands which may make the mechanism clearer.
Messages should be a breath of fresh air after that discussion of the response table. The purpose of messages is to contain all the text that will be displayed to describe what is happening in the game to the player, excluding the messages that PAW itself displays (like "I can't do that." etc).
We are going to deal with the player wanting to examine things in the game, e.g. EXAMINE APPLE. Now examining an object merely requires the writer to provide a message that gives more information about the specified object, so in the case of the apple we could say "The apple is crisp and green.".
Change the message text section so that it reads as follows:-
We are going to deal with only four items in the demo game but in a large game you would usually provide detail for most things, even if they serve no purpose it provides a touch of realism which always makes the player feel involved./MTX Message Texts /0 The apple is crisp and green. /1 It's a cheese and pickle sandwich. /2 The ticket has "City Bus Company" printed on it. /3 The bench is firmly screwed to a concrete base. ; - - - - - - - - - - - - - - - - - - - - - - - - -
Now back to the response table. Let's take the apple first; the phrase which the player will type will be EXAMINE THE APPLE (or EXAMI APPLE if they are lazy!) producing a LS of "EXAMI APPLE". So we need to insert an entry with these two words.
Now we must only allow the player to examine the apple if it is actually HERE, CARRIED or WORN (most normal people have a distinct disability at looking round corners or through walls!). This is collectively known as present and can be checked for using the condition PRESENT followed by the number of the object we are considering (the apple is object 3). If the object is indeed present then we can display our message (0) that describes the object, using the action MESSAGE which is followed by the number of the message you want to display. Finally we top it off with a DONE action to tell PAW that we have completed the task
So the entry we need is:-
EXAMINE APPLE PRESENT 3
MESSAGE 0
DONE
It makes no difference to the compiler or the interpreter whether our new entry uses the words LOOK APPLE or EXAMINE APPLE. However it makes reading and understanding the response table easier if we always choose the same word. Therefore change the response table to insert the following entry before the existing LOOK _ entry:-LOOK _ DESC
LOOK APPLE PRESENT 3 ;Apple here?
MESSAGE 0 ;Describe it
DONE
RAMLOAD _ RAMLOAD 255 ;Reload all flags
DESC
LOOK APPLE PRESENT 3 ;Apple here?
MESSAGE 0 ;Describe it
DONE
LOOK _ DESC
;- - - - - - - - - - - - -
So at the moment if the player tries to EXAMINE anything except the apple (or tries to EXAMINE APPLE when it isn't present) they will be rewarded with a fresh description of their current location. This is why the LOOK APPLE entry MUST be specified before the LOOK _ entry. Let's insert the entries to deal with the sandwich, ticket and bench - they are:-
LOOK SANDW PRESENT 2 ;The sandwich is here
MESSAGE 1 ;Describe it
DONE
LOOK TICKET PRESENT 4 ;The ticket is here
MESSAGE 2
DONE
LOOK BENCH AT 4 ;The bench isn't an object
MESSAGE 3 ;so check location
DONE
AT is a condition that is followed by a location number. It will succeed (i.e. allow PAW to continue onto the next condact) if the player is at the same location. This was used because the bench was not an object, but as it is part of the description for location 4 it will always be there!
Compile the adventure and test it to check that you can examine these four items correctly and that the location is described at any other time.
It was stated earlier that the response table was process table 0. There can be up to 254 process tables as we shall see.
There are three process tables (0, 1 & 2) in the source file to start with, just like response PAW scans through them, but, unlike response, it scans them not after obtaining a LS, but;
Process 1 is scanned immediately after PAW has described a location. This allows information to be printed only once when the player arrives at a location or when he requests a redescribe.
Process 2 is scanned just before requesting a new LS from the parser. This is used to provide PAWs 'turn' at the game.
So far while playing our demo game we have had to end the game by typing QUIT. Now the original storyline (if you can remember that far back!) was to help the passenger find the ticket before the bus arrived. Now we obviously could have an entry in response so that if the player said GET TICKET (and it was present) could trigger the end of the game e.g.
GET TICKET PRESENT 4 ;The ticket is here
TURNS
END ;That's all folks!
We shall do so, but, first we need a message to describe the arrival of the bus, so add the following message to the message text section:-
Note that message 4 must be entered after message 3. The conditions for the end of the game are that the player is at the bus stop (location 2) and is carrying the ticket (object 4). The first condition of course will be AT 2, the other can be checked with CARRIED 4 (pretty unusual names these conditions have...) so the final entry needed in Process 2 is:-/4 The bus arrives. I hand the ticket to the driver who smiles and says "Sorry I'm late, hope you haven't been standing too long?".
_ _ AT 2 ;at bus stop
CARRIED 4 ;with ticket
MESSAGE 4 ;finished
TURNS
END
Add this entry to Process 2 now i.e. at the end of TUTORIAL.SCE.
If you look at process table 1 you will see that the following entries are present:-
_ _ NEWLINE
ZERO 0 ;If it is light...
ABSENT 0 ;and the light source is absent
LISTOBJ ;List the objects
_ _ PRESENT 0 ;If the light source is present
LISTOBJ ;List the objects
NEWLINE prints a carriage return/line feed. It's main purpose here is to ensure that any text displayed will be on a new line because PAW does not start one at the end of displaying a location description. The technical guide shows how to use this to good effect to modify the location description to reflect changes in the location.
From now on the two entries must be considered as a pair, their ultimate purpose is to list the objects at the current location, first a bit of background information;
PAW uses flag zero to determine if there is light for the player to see by (this feature is not used at the moment in our demo game). If there is no light the flag will have a value other than zero and PAW will say "It's too dark to see anything." instead of the description for the location. In this case the objects that are present must not be listed.
Object 0 is assumed by PAW to be an object, which provides light, which is why object 0 in our demo is a lit torch. If this is present while the game is 'dark' (flag 0 is non zero) then it will override the darkness and so the objects must be described.
The two entries provide an example of using PAW to create an OR situation i.e. List the objects if it is light OR if object zero is present;
ZERO is the first condition we have met which tests the state of a flag. ZERO 0 will succeed if flag zero contains 0 which means there is light.
ABSENT ensures that Object 0 is not present (opposite of PRESENT condition - all conditions have an opposite). The next _ _ entry lists the objects if object 0 (the source of light) is present so we do not want this entry to succeed as well (i.e. This deals with the situation of it being light and object 0 being present which would otherwise list the objects twice!).
LISTOBJ lists any objects that are present at the players current location, if none are present it does nothing - it would look a bit silly saying "I can also see nothing."!
Think about the above as it represents a fairly useful feature of PAW which you may well need to adapt for use in your own games.
Right, now we shall reveal the better way of getting from the introduction screen to the start of the game at the bus stop:
_ _ AT 0 ;Start of game
ANYKEY
GOTO 2
DESC
ANYKEY prints "Press any key to continue." and waits for you to press a key, it then allows PAW to continue onto the next condact.
GOTO is followed by a location number and moves the player to that location, it effectively sets flag 38 (players current location) to the value given, it does nothing else so it is followed by a DESCribe to get PAW to display the new description.
This entry thus causes the title screen to be displayed (when PAW displays the first location description), a wait for a key and then the game itself is started at the correct location.
You might like to go to the connections section and remove the entry for NORTH in location 0 as this is not needed now.
Compile and test the adventure to see the above two entries in action. The following input while at location 2 (the bus stop) will 'solve' the game in one go:
You should then get the finishing message and an option to play again. If not, check the entries in Process tables 1 and 2 thoroughly.GO WEST, WEST AND UP. GET THE TICKET. GO DOWN, EAST AND EAST.
Let's have a break and go back to deal with the ability of the bag to contain objects. Thought we had forgotten about that, didn't you? Well we nearly did. This will require some entries in the response table and we are going to allow the player to LOOK IN BAG, so we need a new message "In the bag is:", add this (it should be message 5) to the messages section. We are going to provide the player with the option of saying PUT ALL IN BAG as well as PUT object IN BAG. We can use exactly the same system as GET/DROP ALL discussed earlier. PUT is a synonym of DROP (which takes care of DROP TICKET IN BAG and such similar phrases). So the LS we must check for will be DROP _ (i.e. player is trying to put or drop something), now if the player includes IN BAG as part of the phrase we want PAW to put the object in the BAG. This means we must override the DROP _ entry already present, and if the extra words are included in the LS put the specified object in the beg.
Therefore the entry we need is:-
DROP _ PREP IN ;Put something in bag
NOUN2 BAG
PRESENT 1 ;Bag here?
AUTOP 1
DONE
PREP is a condition that is followed by a preposition from the vocabulary. Prepositions are words used before a Noun to show its relation to another word in the phrase, in this case the condition will succeed if the player has used IN as part of the phrase.
NOUN2 is a condition that is followed by a Noun from the vocabulary. This will succeed if the player has used BAG in the phrase. Combined with the previous entry it effectively stops PAW looking at the condacts unless the LS was PUT _ IN BAG where the underline is any object.
AUTOP is followed by a location number. Now we set aside location 1 for a special purpose early on in the tutorial, this is it, it is used as the inside of the bag! So AUTOP just like AUTOD scans the object definition section for a Noun which matches the current first Noun in the LS, when it has found one it places it at the location given, reporting "I have put the _ in the bag."!
The DROP ALL entry that exists will also work to deal with PUT ALL IN BAG, because it does not ensure that IN BAG is part of the LS. It will trigger on both occasions, and in both cases 254 (or CARRIED) is the location the objects will be coming from.
Now for a GET object OUT OF BAG type command we need an entry similar to the above to override the GET _ entry which already exists so insert the following entry between the existing GET ALL entry and the existing GET _ entry:-
GET _ PREP OUT ;Get something out of BAG
NOUN2 BAG
PRESENT 1 ;Bag here?
AUTOT 1
DONE
The implementation of an ALL version of the command needs an entry of its own, at the moment GET ALL causes a DOALL HERE (or 255), which is the current position of the player, to be carried out. In order to get all from the bag we need to generate all the objects that are inside it (location 1), so insert the following entry prior to the existing GET ALL entry:-
GET ALL PREP OUT ;Get all out of bag
NOUN2 BAG
DOALL 1
LOOK BAG PREP IN ;Look in bag
MESSAGE 5
LISTAT 1
DONE
which is correct, unlike LISTOBJ, which because of its main use does not print anything at all in that situation.In the bag is: nothing.
So compile and test the adventure again to ensure that you can indeed PUT ALL IN BAG and GET object OUT OF BAG etc.
The bird will complicate the scenario as follows. The bird will have the ticket at the start of the game (normally you would assign an unused location to contain the birds objects, but we will use location 252 - object does not exist in game - as we have only one PSI that can have an object). This means you must persuade the bird to drop the ticket, trying to GET it will result in an "I can't do that" message and the bird flying away. The bird also flies between the Bandstand and the Tree Branch at regular intervals. The way to get the bird to drop the ticket will be to drop the sandwich at the same location. So lets get that little lot working first.
Firstly change the object definition of object 4 to:-
This makes the ticket a "does not exist" object which we are using to indicate it is in the birds beak. Insert the Nouns DOG and BIRD in the vocabulary with word values 21 and 22 respectively. Then insert the following messages that will be needed./4 _ 1 _ _ TICKET _
We will insert the messages to deal with the dog later after an ear bending on yet another feature of PAW./6 The bird drops the ticket to peck at the sandwich. /7 The bird snatches the ticket. /8 The bird ignores me. /9 A small bird is here. /10 The bird has a ticket in its beak. /11 A small bird settles on the ground. /12 A small bird lands on the branch. /13 The bird sees the dog and flutters away quickly. /14 The bird flies away.
In a large game which contains several PSIs and a lot of background action, Process tables 1 and 2 soon become so full of entries it is difficult to work out what they do. Enter stage left the other process tables to the rescue, these can be 'called' from Process 1, 2 or Response and used as an extension of the table they are called from. Calling a process causes PAW to save where it is at the moment and shift the action to the indicated table. Note that when something is DONE in the called process, then PAW will still shift back to the original table, so some very powerful things can be achieved with thoughtful use of these sub-process'. Users who program in other languages will recognise this as a 'subroutine'.
While PAW is in a sub-process it is quite possible for it to be asked to call yet another sub-process - a sub-sub-process? and so on down to a sub-sub-sub-sub-sub-sub-sub-sub-sub-sub-process! That is 10 levels of subroutine calls may be carried out, this is called 'nesting' a call, attempts to go further will result in an Interpreter run time error.
We are not going to use anything like that here, only a sedate sub-process. This will contain all the entries to deal with the bird's activities.
We will use process table 3 for the bird.
Flag 11 will be a 'working' flag to contain a value for use in a comparison.
Flag 12 will contain the current location number of the bird.
Flag 5 is a special flag which if it has a value other than zero PAW will reduce by one whenever it scans process 2 - this is called an auto decrement flag. In this case it is used to count the number of 'time frames' that have passed in the game, a time frame is a single time round the big loop shown in diagram 2, and at the moment this is done before every phrase the player types. The bird will change location every three phrases on behalf of the player, which will create the appearance of action in the game independent of the players input.
New insert the following entries, in order after process 2, each entry is preceded by an explanation of its purpose and any new condacts it uses:
First determine if the bird is going to fly away this time through the table. This is indicated by flag five being zero (as it counts down from 3). If the ticket is at the same location as the bird it will be destroyed (i.e. put at location 252 so the bird 'has' it) and if the player is at the same location as the bird they will be told that the bird has snatched the ticket. Note that the bird will continue its cycle of movement even if the player does not see it, a tree certainly does fall even if there is no one to see it in PAW!
/PRO 3 ;Bird
_ _ COPYOF 4 11 ;Copy loc'n of obj4(ticket) to flag1
SAME 11 12 ;ticket at same loc'n as the bird.
ZERO 5 ;Bird going to fly?
DESTROY 4 ;Bird 'GETS' the ticket
SAME 12 38 ;Bird at same location as player?
MESSAGE 7 ;Tell player about it.
The /PRO 3 line marks the beginning of process table 3.
COPYOF is an action followed by an object number and a flag, it copies the current location of the specified object to the specified flag. We use it in this situation to see if the ticket is at the same location as the bird by following it with;
SAME is a condition that compares the contents of the two flags and succeeds if they are the same.
DESTROY is an action which places the specified object at location 252, the not-created location.
Now deal with the two possible movements of the bird. If the bird is at the bandstand and flag five has reached zero then move the bird, set flag 5 to 3 again and tell the player the bird is gone if they were at the same location. Vice Versa if the bird is on the branch,
_ _ EQ 12 8 ;Bird on branch?
ZERO 5 ;Time to fly?
LET 12 5 ;Move bird to bandstand
LET 5 3 ;Three phrases 'till move
AT 8 ;Player here as well?
MESSAGE 14 ;Tell them bird has flown
_ _ EQ 12 5 ;Bird on bandstand
ZERO 5 ;Time to fly?
LET 12 8 ;Move to branch
LET 5 3 ;Three phrases 'till move
AT 5 ;Player here as well?
MESSAGE 14 ;Tell them...
LET is an action that is followed by a flag and a value. It sets the flag to the value.
Now we have dealt with the birds departure, next we must deal with its arrival, and if it arrives in a location which contains the player tell them about it.
_ _ EQ 5 3 ;Bird just flown?
SAME 12 38 ;Now at players location?
AT 5 ;On bandstand?
MESSAGE 11 ;Landed on ground
_ _ EQ 5 3 ;Bird just flown?
SAME 12 38 ;Now at players location?
AT 8 ;On branch?
MESSAGE 12 ;Landed on branch
_ _ EQ 5 3
SAME 12 38
ISAT 4 252 ;Ticket not-created?
MESSAGE 10 ;Has a ticket in beak.
Finally if the sandwich is at the same location as the bird, the bird will drop the ticket to peck at the sandwich. This entry does not rely on flag 5 so it will be checked for every time PAW checks process 2, so even if the player drops the sandwich after the bird has arrived the correct sequence will still be carried out.
_ _ COPYOF 2 11 ;Sandwich
SAME 11 12 ;at same location as bird?
ISAT 4 252 ;Ticket in beak?
COPYFO 12 4 ;Put ticket down
SAME 12 38 ;Player here as well?
MESSAGE 6 ;Tell them...
That completes the control routine for the bird, but we need an entry in Process 2 to call this table every time frame, so insert the following entry at the beginning of process table 2:-
which will cause PAW to execute our bird control table every pass round its main loop._ _ PROCESS 3 ;Bird
We must ensure the bird starts at the correct location and that the player knows the bird is there when the location is described (or they will see messages about a bird arriving and flying off, with the description containing no mention of it). So amend the entry we made earlier to process 1 to contain a LET 12 8, which will ensure the bird is on the branch at the start of the game. The modified entry should read thus:
_ _ AT 0 ;Start of game
ANYKEY
LET 12 8 ;Bird is on branch (locno. 8)
GOTO 2
DESC
_ _ SAME 12 38 ;Bird at same location?
MESSAGE 9 ;Tell player
ISAT 4 252 ;Ticket in beak?
MESSAGE 10 ;Tell player
GET TICKE SAME 12 38 ;Bird at same location?
ISAT 4 252 ;with ticket in beak?
CLEAR 5 ;Force it to fly away
NOTDONE ;"I can't do that"
CLEAR is an action that is followed by a flag number and sets the flag to have the value 0. This will cause the bird to fly away (which it might have been going to do anyway) simulating its fright at having a great hand descend on it to get its prized possession.
NOTDONE is an action similar to the DONE action but it fools PAW into thinking that nothing was done and thus causes it to print the "I can't do that" message.
Now the moment of truth, upon testing the game you should be able to watch the bird fly in and out of the bandstand and the branch, play with the game for a while to see the fact that the bird does indeed continue its roving existence. Then try dropping the sandwich at the same location. Note that if you do not pick up the ticket before the bird flies away it will snatch the ticket back.
Before we examine the entries in Process and Response needed to control the dog insert the following words into the vocabulary section: -
and the following messages into the messages section:-TIE 34 verb UNTIE 35 verb SIT 36 verb STAY 36 verb COME 37 verb HERE 37 noun
Ensure you include the underline in message 15 as it serves a special purpose we will discuss later./15 The _ falls to the ground at the foot of the tree. /16 The dog's bright eyes stare at me with mindless love. /17 A dog is here. /18 The dog follows me wagging his tail. /19 A lead trails behind the dog. /20 The dog is tied to the bench by a lead. /21 Trustingly the dog lets me put the lead around its neck. /22 I've tied the lead to the bench. /23 Who should I say it to? /24 The dog is sitting quietly. /25 I've untied the dog from the bench.
There is no real need to make the control routine for the dog a separate process table as it is only one entry, but we shall do so in case you wish to expand the game later.
Flag 13 will contain the current location of the dog.
Flag 14 will contain: 0 - the dog is free to roam, 1 - the dog has the lead around its neck, 2 - the dog is tied to the bench, 255 - the dog is sitting quietly.
The Process table needed for the dog is:-
/PRO 4 ;Dog
_ _ NOTSAME 13 38 ;Dog not where player is?
LT 14 2 ;Still able to move?
NOTAT 8 ;Player isn't up the tree?
COPYFF 38 13 ;Move dog to players locno.
MESSAGE 18 ;Tell them its followed...
LT is a condition that succeeds if the flag specified contains a value Less Than the specified value.
Insert at the beginning of process table 2;
Note that this comes before the entry for the bird to ensure the dog will be moved to the players new location before the bird is checked._ _ PROCESS 4 ;Log
Similarly to the bird, entries are required in process table 1 to inform the player of the dogs presence and these should be before the entry for the bird:-
_ _ SAME 13 38 ;Dog at same location?
MESSAGE 17 ;Tell player
EQ 14 1 ;With lead?
MESSAGE 19 ;Yes so tell player
_ _ SAME 13 38
EQ 14 2 ;Dog tied to bench?
MESSAGE 20
_ _ SAME 13 38
GT 14 2 ;255 is greater than 2 so
MESSAGE 24 ;tell player dog is sitting
Now in order for the bird to be frightened away by the dog we need an extra entry in process table 3. Now the entry must go before the entry which decides to drop the ticket and after the entries which make the bird fly. This will ensure that the bird will fly away with the ticket if it has it and leave it if it does not. So we need to insert the following as the seventh entry in Process 3:-
_ _ SAME 12 13 ;Bird and dog at same location
LET 12 8 ;Only ever on bandstand so
LET 5 3 ;move to branch, three phrases
AT 5 ;Player on bandstand?
MESSAGE 13 ;tell them bird is gone..
/PRO 5 ;Speak to dog
_ _ PARSE ;Convert string to LS
MESSAGE 16 ;Not valid phrase so
DONE ;dog does not understand!
SIT _ ZERO 14 ;Dog not partially tied up?
SET 14 ;Now sitting quietly
MESSAGE 24 ;Tell player (always at same
DONE ;place as dog) then DONE
COME _ EQ 14 255 ;Dog must be sitting
CLEAR 14 ;Now normal
MESSAGE 18 ;Dog follows
DONE
_ HERE EQ 14 255 ;Dog sitting?
CLEAR 14 ;Now normal
MESSAGE 18 ;Dog follows
DONE
_ _ MESSAGE 16 ;Anything else.
PARSE will allow PAW to continue looking at condacts if it fails to find a valid phrase. Be careful here as the current LS may be a bit jumbled up (i.e. the parser managed to get some sense out of the phrase) so you should normally only print a message like "They didn't seem to understand" or something similar and DONE to return to your calling action. If it does form a valid LS, PAW will start to search the following entries for a match as with Response. PARSE should only be used in a sub-process called from Response as it has no meaning in any other table.
Notice how the COME and HERE entries deal with a variety of phrases that the player might try to call the dog again having made it sit.
The last entry catches all the valid LS that may have been in the string and the dog has no specific response to.
Now to the Response table to allow us to insert the extra entries to control speech and the dropping of objects in the tree.
First off the mark is the entry which causes all objects dropped in the tree to fall to the ground, now this must go between the entry which deals with putting objects in the bag and the normal DROP _ entry.
DROP _ AT 8 ;Player on branch?
WHATO ;I say old boy!
LT 51 255 ;Valid object?
EQ 54 254 ;Object carried?
MESSAGE 15 ;Its now bottom of tree.
PUTO 7 ;Put it there
DONE
WHATO is an action, which looks up the first Noun in the current LS in the object definition section converting it into an object number. This number is then placed in flag 51. Flag 51 always contains the number of the last object referenced by PAW and whenever it is set the associated flags 54 to 57 are also set. Flag 54 contains the current location of the object.
PUTO is an action that changes the location of the currently referenced object to be the one specified.
Message 15 contained an underline. Whenever PAW meets an underline in text (be it message or location) it replaces it with the current object hence the message is changed to suit the object currently being dealt with.
Next a relatively simple entry to deal with PUT LEAD ON DOG and this should go after the DROP ALL entry:-
DROP LEAD PREP ON ;Ensure not just a DROP LEAD
NOUN2 DOG
CARRIED 5 ;Player has the lead
SAME 13 38 ;is at same location as dog
LET 14 1 ;Dog now has lead on
DESTROY 5 ;So player hasn't
MESSAGE 21 ;Tell them so.
DONE
TIE DOG LET 34 55 ;Convert DOG to LEAD
TIE LEAD PREP TO
NOUN2 BENCH
AT 4 ;Where bench is.
SAME 13 38 ;dog is here
EQ 14 1 ;with lead on
PLUS 14 1 ;now tied to bench
MESSAGE 22 ;tell player about it
DONE
TIE _ NOTDONE ;Ensure an I can't
UNTIE DOG LET 34 55 ;Convert DOG to LEAD
UNTIE LEAD AT 4 ;Where bench is
EQ 14 2 ;dog tied to it
CLEAR 14 ;Now free
MESSAGE 25 ;Tell player
CREATE 5 ;Recreate lead
GET 5 ;Try and get it.
DONE
UNTIE _ NOTDONE ;Ensure an I can't
PLUS is an action that is followed by a flag number and a value. The flag is increased by the value. If the result exceeds 255 then the flag is set to 255.
CREATE is an action which is followed by an object number. It causes that object to be at the position where the player is.
GET is an action that is followed by an object number. It attempts to get the specified object.
We use these actions instead of just placing the object at 254 so that any weight and/or number of objects carried problems are reported.
Finally the entries to allow speech to the dog, we have else included the entry necessary to allow you to speak to the bird - It just ignores you! These can also go at the end of Process table 0:-
SAY DOG SAME 13 38 ;It's here
PROCESS 5 ;Someone else to do the work
DONE
SAY BIRD SAME 12 38 ;Bird here
MESSAGE 8
DONE
SAY _ MESSAGE 23 ;Who?
DONE
Now compile and test the adventure.
As a final test the following inputs should now work in the indicated situations, they show some of the power that the parser can provide your games with.
When on the path by the park bench with the lead and dog try;
then to untie it;PUT LEAD ON DOG AND TIE IT TO THE BENCH
When up the tree with the bag try;UNTIE DOG
To make the dog sit down;PUT ALL IN BAG AND DROP IT. GO DOWN AND LOOK IN BAG
and get back up,SAY TO DOG "SIT"
ASK DOG TO "COME HERE"
TURN TORCH PREP ON
CARRIED 7
SWAP 7 0
OK
TURN TORCH PREP OFF
CARRIED 0
SWAP 0 7
OK
DOWN _ AT 5 ;Player on bandstand?
SET 0 ;Flag 0=255=Dark!
GOTO 9 ;New location
DESC
To allow someone to run a finished game you will need to give them PAWINT.EXE and the appropriate .PDB file.
Finally, a small game in source form "TEWK" is provided. Looking through this should provide you with some more ideas on giving your game an individual look.
What should I do next? HAVE FUN! OK