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 CHECKs 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 VERBs 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.
CHECKs 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.