Adventure Construction Table of Contents Alan Language Grammar


This appendix describes the errors that may occur during the running of the adventure, i.e during interpretation of the generated Acode. There are two classes of errors, player input response messages and system errors.

Input response errors are not fatal but abort the execution of the current player command and discard the rest of the user input, which is a normal part of the interaction between the player and the Alan run-time system. System errors are fatal and abort the execution of the adventure.

A.1 Input Response Messages

Various messages are printed for the benefit of the player. Most messages probably come from the adventure itself, i.e.they where provided by the adventure author. But there is a set of messages that can be given directly by the Arun interpreter. They are presented below using the Alan STRING-format, i.e. containing the special character combinations described in Output Statements . These standard messages exist for all languages and the default value of the texts are selected depending upon the setting of the language option.

The contents of any message can may be modified using the MESSAGE statement (see Messages ). The identifier on the first line of a message explanation is the identifier that should be used in the MESSAGE statement to change the contents of that message. The second line is the default english message text, and finally a short explanation is given.

All messages are available in all supported languages but below the english message texts are shown.

"I don't understand.",

The input did not follow any syntax the Arun parser knows about.

"I don't know what you mean by 'all'.",

The player input ALL , but the Arun parser could not find any objects or actors that it could refer to.

"I don't know what you mean by 'it'.",

IT may only be used when the previous command contained a reference to one object or actor.

"I don't know what you mean by 'them'.",

THEM refers to the set of objects or actors mentioned in the previous command. If there were no multiple parameters in the previous player command, Arun will issue this message.

"You can't refer to multiple objects with '$v'.",

The syntax for the indicated verb did not allow multiple parameters.

"I can't guess what you want to $v.",

The verb required a parameter.

"You must supply a noun.",

The player started to specify an object or actor but only supplied the adjectives.

"You must give an object after 'but'.",

In a command containing ALL BUT , the player must also give the object or objects excluded.

"You can only use 'but' after 'all'.",

The words BUT and EXCEPT may only be used after ALL.

"That doesn't leave much to $v!",

The player used an ALL BUT construct which explicitly excluded everything matched by the ALL .

"I don't know which $1 you mean.",

There were multiple objects (or actors) that matched the description given by the player. More adjectives are necessary to distinguish between them.

"I can't see any $1 here.",

The player referred to an object or actor that was not present.

"You can't go that way.",

A directional word was used but there is no exit in that direction.

"You can't do that.",

Somehow Arun found no verb body to execute. This may be a situation overlooked by the author or the player may be trying to do something that is not possible.

"You can't $v the $1.",

A variation of the above.

"There is",

"$$, ",

"and ",


These four messages are used to construct the default text for describing objects present at the current location (unless they have a description clause, in which case they are used instead). The message parts are used as in "There is <article> <object>, <article> <object> and <article> <object> here." The underlined parts are the ones in the messages and <article> and <object> are inserted as appropriate.

"is here.",

The default message for presenting actors present, unless they present themselves (have a description).



", ",

"and ",


The four messages above are used to construct the default contents listing of a container in much the same way as for the object listing above. The messages are used according to the pattern "The <container> contains <article> <object>, <article> <object> and <article> <object>."


"is empty.",

The default messages for empty containers.

"You have scored",

"points out of",

Two parts of the default scoring message.

"I don't know that word.",


The classic message when the screen is full. The player should press RETURN to proceed.


This message is presented immediately after the location name if the location has been visited before to give the player the information that he has visited this location before (a good thing in some adventures). If you wish to disable this set this message to an empty string.

"Enter file name to save in",

When executing a SAVE the player can enter the name of the file to save in. The name used in the previous SAVE is used as a default.

"That file already exists, overwrite (y) ? ",

If the save file already existed the player must confirm the overwrite.

"Sorry, save failed.",

When executing a SAVE , the file system indicated some error, usually a write protected directory or full disks.

"Sorry, the save file was created by a different version.",

The save file found was created by a different version of the Alan interpreter.

"Sorry, the save file did not contain a save for this adventure.",

The indicated save file did not contain a save of this adventure.

"Enter file name to restore from",

A RESTORE statement can restore from any named file. The previously used file name is used as the default.

"Sorry, could not open the save file.",

When executing a RESTORE , Arun could not find a save file with the indicated name in the current directory.

"Do you want to RESTART, RESTORE or QUIT ?",

The QUIT statement requests an action from the player.


The indefinite article is needed for objects, objects which have none declared (using the ARTICLE clause) will receive the default article. This is mainly available for the ease of constructing adventures in unsupported languages.

A.2 System Errors

System errors are errors caused by internal malfunctions. Mainly these are implementation errors (aka. bugs!), but may (in some manner) also result from user errors. The system error messages also have a purple prose style to fit in with your game, e.g.:

As you enter the twilight zone of Adventures, you stumble
and fall to your knees. In front of you, you can vaguely
see the outlines of an Adventure that never was.

SYSTEM ERROR: Can't open adventure code file.

Author Errors

The following system errors are in some sense caused by the Adventure author (you).

Out of memory.

The adventure was so large that the interpreter could not allocate enough dynamic memory for it. Try to finish other running applications (does not work or is not possible on all systems), get more real memory, or complain to the Alan implementors (see FUTURE DEVELOPMENTS for how to reach us).

Incompatible version of ACODE program.

The interpreter you are using have a different version than the Alan compiler used to compile the adventure. Use a different Arun or recompile the adventure with the matching compiler.

Recursive LOOK.

This message is shown when a LOOK statement is executed as a result of a LOOK , i.e. a recursive LOOK ! The LOOK statement should only be used in global verb bodies, not in descriptions of LOCATIONs and OBJECTs as there is a definite risk that it will be executed as the effect of a LOOK , either explicit or implicit (by the hero entering that location!).

Locating something inside itself.

This means that an attempt to locate an object (that is a container) inside itself has been made. This might happen if the adventure author has neglected to check this in a verb like put_in = 'put' (o) 'in' (c) .

Non-existing parameter referenced.

A parameter that wasn't available was referenced. This is probably due to using for example $2 in a string in a context where the syntax was restricted to only one parameter. This may avoided by using the SAY statement instead of the embeped string parameter references, which would result in compile time checking avoiding the risk of having this happen to the player.

Player Errors

Errors caused by incorrect arguments or file names.

Can't open adventure code file.

Can't open adventure data file.

The player attempted to run an adventure for which there were no code or data file available, probably a misspelling.

Could not read all ACD code.

Checksum error in .ACD file (%1 instead of %2).

These two messages indicate problems in the adventure files. Possibly caused by transfer problems of the .acd and .dat files which must be made in binary mode.

Implementor Errors

Any other text in a system error message is really a SYSTEM ERROR. Scribble down the text and contact the implementors (see FUTURE DEVELOPMENTS ). If possible supply the source for your adventure, a trace of the few last player commands (if possible with single step and trace turned on, see Debugging ).

Adventure Construction Table of Contents Alan Language Grammar