Because we're not looking at them in this lesson some more of the verbs we defined in earlier lessons have been taken out of the main example file and added to the verbs in library1.ala
to make library2.ala
.
( Library2.ala
is $include'
d into the lesson7.ala
file.)
A player may not want to play the whole game at one time. The Alan SAVE
and RESTORE
statements allow the player to record where they got to in a game and return to that point at a later time. SAVE
records the current state of the game (eg: player's current location, value of object attributes, etc) to a disk file. RESTORE
reads a previously saved disk file and restores all the game attributes to the recorded state.
As with the QUIT
statement we need to create simple verbs to allow the player to use SAVE
and RESTORE
.
SYNTAX 'save'='save'. VERB 'save' DOES SAVE. END VERB. SYNTAX 'restore'='restore'. VERB 'restore' DOES RESTORE. LOOK. END VERB.
The 'restore' command includes a LOOK
statement to display the description of the player's location after the restore. This isn't essential but its most likely the player will need a reminder of where they were at when they last saved the game.
See the START
section in the lesson7.ala
file for an example.
In previous lessons the START
section of the game only contained the VISITS
statement. Other statements can go in the START
section too and, of course, some text to introduce the game is a good idea. You can put in a game title and copyright information as well as a paragraph or two to set the scene for your game.
The player will normally expect to be able to take a closer look at any objects in the game. If an object is mentioned in the location description the player will probably try to examine it.
So for each defined object we should define an examine verb which describes it in detail.
OBJECT Control NAME Remote Control AT Hallway DESCRIPTION "There is a home-made electronic remote control here." VERB Examine DOES "The remote control has two large buttons. One button is made of green plastic, the other is red." END VERB. END OBJECT Control.
Local verbs, defined within an object or location, can be used in combination with global definitions, defined in the main body of the source code.
A common example of this approach is the examine verb. With some objects there may be nothing worth saying about it except what is already described in the location description. We can define a default examine verb outside any object definition that will apply to all objects.
VERB Examine DOES "There is nothing significant to say about the $1" END VERB.
That introduces a problem when the player examines an object that does have a specific 'examine' verb defined. Normally, when there is both a global and 'local' object definition of a verb Arun will execute first the global verb and then the object one. So in this example the following contradictory text would be displayed
There is nothing significant to say about the control. The remote control has two large buttons.
One button is made of green plastic, the other is
red.
So we need to tell Arun to only execute the object-specific verb. This is done by adding the keyword ONLY
to the object's verb definition.
VERB Examine DOES ONLY "The remote control has two large buttons. One button is made of green plastic, the other is red." END VERB.
There is another example of a verb defined for an object in the example game for this lesson. In previous examples if a player tried to 'take' the bomb a message "You can't take that" was displayed because the bomb object was defined as ' IS NOT takeable
'. We can make the bomb 'takeable' by removing the ' IS NOT takeable
' statement. The bomb will then become 'takeable' as that is the default for all objects as specified in the OBJECT ATTRIBUTES
statement at the start of the source code. We can then define a 'take' verb within the bomb object definition which describes the disastrous consequences of trying to get the bomb and then ends the game - by using the QUIT
statement.
VERB Take DOES ONLY "The vibrations as you try to remove the bomb from the lamp post upsets its delicate internal mechanism. The bomb explodes.$p$p You have lost the game.$p" SCORE. QUIT. END VERB.
In some cases it is useful to have both the global and local definitions of a verb execute. In such cases you wouldn't have an ONLY
clause in the local verb definition.
For example, the verb 'read' could have global definition that checks whether the player has the object and if not, automatically picks it up while a local definition within each object displays what's written on that particular object.
OBJECT Note AT Street DESCRIPTION "There is a grubby piece notepaper here with some scrawled writing on it." VERB Read DOES "Its just someone's old shopping list scrawled on the notepaper." END VERB Read. END OBJECT Note. VERB Read DOES IF OBJECT NOT IN Inventory AND OBJECT IS Takeable THEN LOCATE OBJECT IN Inventory. "(You pick up the $1.)$p" END IF. END VERB Read.
We've already seen how to allow the player to use alternative names for verbs by defining synonyms. For example we can define the abbreviation 'x' as a synonym for 'examine'. In some cases you may want to allow an alternative way of phrasing a command which can't be handled by verb synonyms because the syntax for the two verbs is different.
For example we may like to allow 'look at object' as an alternative to 'examine object'. This verb is obviously different from 'examine object' as it has three words, not two. You could define a separate verb with its own CHECK
s and DOES
statements and so on but this would be a bit tedious if, like 'examine', the verb is defined in many different places in the source code. Fortunately Alan allows you to list more than one verbname in a single VERB
definition. So while you must define the syntax for alternative verbs individually, as long as the verbs have the same parameters, you don't need separate VERB
s definitions.
A 'look at object' command requires two words - 'look' and 'at' - plus an object name. The default Alan verb syntax doesn't allow that so the syntax for 'look at object' must be explicitly defined. We would define the syntax for a command called 'look_at' to contain two words - 'look' and 'at' - followed by the name of object (referred to by the parameter name 'obj1')
SYNTAX look_at='look' 'at' (obj1).
We didn't need to define a syntax for the 'examine' verb earlier because 'examine' used the default 'verbname-followed-by-objectname' syntax. That means 'examine' uses, by default, the parameter name 'object'. We now want to allow the player to use it and 'look_at' interchangeably which means 'examine' and 'look_at' will share the same verb definitions. Therefore the 'examine' verb must have the same parameter name (obj1) as 'look_at'. To specify the parameter name for 'examine' we need to include a syntax statement for 'examine' in our source code too.
SYNTAX examine=examine (obj1).
Then wherever we define the 'examine' verb we can simultaneously define 'look_at' as well simply by adding ' , look_at
' to the VERB
statement - like this
VERB Examine, look_at CHECK Obj1 HERE ELSE "Its not here." DOES ONLY "The remote control has two large buttons. One button is made of green plastic, the other is red." END VERB.
CHECK
s in Exits As with verbs, the CHECK
statement can be used with location exits to make exits change depending on current circumstances. The most common example found in text adventures is doors. When a door is open the player can exit otherwise a message is displayed saying the door is shut.
A door could be defined along with a few object attributes - to be used in the definition of an 'open' verb - like this
OBJECT Front_Door NAME Door AT Porch IS NOT Takeable. IS NOT Open. IS Openable. END OBJECT Front_Door.
The 'open' verb along with a 'close' verb can then be defined
VERB Open CHECK OBJECT IS Openable ELSE "You can't open that." AND OBJECT IS NOT Open ELSE "The $o is already open" DOES "The $o is unlocked and opens easily." MAKE OBJECT Open. END VERB. VERB Close CHECK OBJECT IS Openable ELSE "You can't close that." AND OBJECT IS Open ELSE "The $o is already closed" DOES "The door is now closed." MAKE OBJECT NOT open. END VERB.
Note the use of the MAKE
statement to change the value of an attribute.
Whether the door is open or not can now be checked in an EXIT
statement.
LOCATION Porch NAME Front Porch DESCRIPTION "You are standing on a wooden porch. The front door of the house(to the north of you) seems newly installed and very strong." EXIT south TO Street. EXIT north TO Hallway CHECK Front_Door IS open ELSE "The door is closed." END EXIT north. END LOCATION Porch.
Those object, verb and exit definitions will work ok but that's only half the story. When the player goes through the doorway to the other location the door should still be visible and openable. As far as the player is concerned he expects to see the same door but as it is another location the game author needs to create a second door object at the second location and create verbs that open and close the two objects simultaneously.
In this example game there are only two openable objects so global 'open' and 'close' verbs would do but normally its best to use a combination of global and local verbs.
The global 'open' and 'close' verbs can check that the commands are feasible while local verbs within each door object can be used, if the global checks are passed, to change the attributes of the correct objects.
--Global verbs VERB Open CHECK OBJECT IS Openable ELSE "You can't open that." AND OBJECT IS NOT Open ELSE "The $o is already open" END VERB. VERB Close CHECK OBJECT IS Openable ELSE "You can't close that." AND OBJECT IS Open ELSE "The $o is already closed" END VERB. OBJECT Front_Door NAME Door AT Porch IS NOT Takeable. IS NOT Open. IS Openable. VERB Open DOES "The door is unlocked and opens easily. Inside the house you can see a dark corridor" MAKE Front_Door open. MAKE Door2 open. END VERB. VERB Close DOES "The door is now closed." MAKE Door2 NOT open. MAKE Front_Door NOT open. END VERB. END OBJECT Front_Door. OBJECT Door2 NAME Door AT Porch IS NOT Takeable. IS NOT Open. IS Openable. VERB Open DOES "You open the hallway door, letting in some welcome light and fresh air" MAKE Front_Door open. MAKE Door2 open. END VERB. VERB Close DOES "You close the door. With the light from the outside world gone, the hallway is now dark and mysterious." MAKE Door2 NOT open. MAKE Front_Door NOT open. END VERB. END OBJECT Door2.
As with verb definitions, you can allow alternative player commands to use the same EXIT
definition by listing the allowed words in the EXIT
definition.
Defining 'enter' as a synonym for 'north' would mean that, in any part of the game, the player can type 'enter' to go north. In many locations using 'enter' this way wouldn't make sense. So listing 'enter' as an alternative in the EXIT
definition at this particular location is better.
EXIT north,enter,'in' TO Hallway Check Front_Door IS open ELSE "The door is closed." END EXIT north.
In the example above 'north, 'enter' and 'in' are all equivalent. 'in' is in single-quotes because it is an Alan keyword. Similarly if you wanted to use 'exit' as an EXIT
command you would have to put it in single-quotes as it is obviously an Alan keyword also.
EXIT south,'exit' TO Porch Check Door2 IS open ELSE "The door is closed." END EXIT south.
The container property can be applied to objects that aren't obviously containers. It can be a useful way to group items together so that the game can treat all the objects in the group as one unit. For example, if the player picks up the remote control device in the example game he also picks up the two buttons on it. The two buttons are individually defined as objects so the player can push and examine them.
OBJECT Control NAME Remote Control AT Hallway CONTAINER DESCRIPTION "There is a home-made electronic remote control here." VERB Examine, look_at DOES ONLY "The remote control has two large buttons. One button is made of green plastic, the other is red. Above the green one is a plastic tag labelled 'Disarm'. Above the red one is another tag labelled 'Detonate'." END VERB. END OBJECT Control.
The two buttons are mentioned in the 'examine' text for the 'control' object so they don't need their own descriptive text defined in their object definitions. If the author simply left out the DESCRIPTION
statement when defining the button objects, Alan would insert the default "There is a objectname here" so text like this would be displayed
There is a home-made electronic remote control here. There is a green button here. There is a red button here.
To avoid this the author can define a blank description for the button objects.
OBJECT Butt1 NAME Green Button IN Control DESCRIPTION END OBJECT Butt1.
The buttons should also have the attribute NOT Takeable
else the player could 'take' a button separately from the rest of the remote control. (Making the buttons NOT Takeable
won't stop the player picking up the remote control itself and therefore the buttons along with it.)
OBJECT Butt1 NAME Green Button IN Control IS NOT Takeable. DESCRIPTION END OBJECT Butt1.
Normally the player would expect to be able to put objects into a container. Though its not obvious from the description that the remote control is a container object, if the player should happen to try to put something into the remote control, Arun will happily oblige with, for example, "You put the notepaper in the remote control."
One way to disable 'put' is to define a local 'put' verb within the 'control' object which will over-rule the normal action of 'put'
VERB put CHECK Obj1 IN Inventory ELSE "You don't have the $1." DOES ONLY "You can't put anything in the $2." END VERB.
Another way is to use a feature of the CONTAINER
attribute called LIMITS
. The author can define the maximum number of objects a container can hold by specifying the maximum 'count' in a LIMITS
statement. In the case of the remote control, the maximum count can be set to zero to effectively disable putting anything in the control.
OBJECT Control NAME Remote Control AT Hallway CONTAINER LIMITS COUNT 0 THEN "You can't put anything in there!" DESCRIPTION "There is a home-made electronic remote control here." END OBJECT.
(In the case of this container which already contains the two button objects you could alternatively use ' LIMITS COUNT 2
' so the player can't add any more objects to the container.)
The object definitions for the remote control and its two buttons are now done. With a definition of the verb 'push' for each of the button objects the author can provide a way for the player to solve the bomb 'problem' and win the game.
OBJECT Butt1 NAME Green Button IN Control IS NOT Takeable. DESCRIPTION "" VERB Push DOES ONLY "You push the green button. You hear a small click. Nothing else happens. Then you hear a voice call $p ""Hey! The bomb has stopped ticking!"" $p$PYou have won the game!$p" SCORE. QUIT. END VERB Push. END OBJECT Butt1. OBJECT Butt2 NAME Red Button IN Control IS NOT Takeable. DESCRIPTION VERB Push DOES ONLY "You push the red button. You hear a small click. There is a dazzling flash of light which is almost instantly followed by an overwhelming blast of noise and fire.$p The bomb has exploded. $p$PSorry, you have lost the game!$p" SCORE. QUIT. END VERB Push. END OBJECT Butt2.