7 - Lesson Seven


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.)

7.1 - Save and Restore

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 .

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.

7.2 - Game Opening Text

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.

7.3 - Examine Object Verb

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.

7.4 - Local and Global Verbs

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.

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

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.

7.4.1 - Another Example - 'Take the Bomb'

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.

7.4.2 - Yet another local/global example - 'read'

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.

7.5 - Equivalent Verb Definitions

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')

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.

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

7.6 - 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.

7.6.1 - Door Objects and 'Open' Verb

A door could be defined along with a few object attributes - to be used in the definition of an 'open' verb - like this

The 'open' verb along with a 'close' verb can then be defined

Note the use of the MAKE statement to change the value of an attribute.

7.6.2 - Exit Check Example

Whether the door is open or not can now be checked in an EXIT statement.

7.6.3 - The other side of the door

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.

7.7 - 'enter'/'exit' synonyms for exits

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.

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.

7.8 - Container Object

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.

7.9 - Blank Object Descriptions.

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

To avoid this the author can define a blank description for the button objects.

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.)

7.10 - Disabling 'put' for a Container Object

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'

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.

(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.)

7.11 - Winning and Losing

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.


Example Alan source code | Table of Contents | Next Section