Introduction Table of Contents The Language


2.1 What is an Adventure?

As long as man has been around there has been stories, fairy tales and fantasies. In early days the stories were told by story tellers to silent and astonished audiences. After Gutenberg, the stories were printed and the readers partook in the fantasies of the author. In our days, passive viewers are fed from the silver screen or through the tube.

In our century, at last, there has evolved a way for the "audience" to take part in the story themselves. It started in the forties and fifties and continued to develop into the games today known as Dungeon and Dragons, Tunnels and Trolls, etc. Games where a game leader designs the story, but the players decide (and perform) the actions of the characters in the story.

These games, of course, have a computerized counterpart.

The games are played interacting with the computer. The program describes a scene or situation (usually in text, but pictures are more and more frequently used), the player decides on some action and gives orders to the computer to carry out his wishes. Usually there are objects to manipulate, traps to negotiate and puzzles to solve, the object being to find the hidden treasures or save the world.

This form of games was started by Crowther & Woods in the late sixties when they designed the famous Colossal Cave Adventure now available on many mainframe computer systems. Inspired by this, Lebling (then at MIT) took a giant step forward in adventuring by creating the Great Underground Empire and making it available for venturing Adventurers in the game Dungeon. This game contained a much more developed story and could handle much more complex commands.

Later, Dave Lebling & Co started Infocom, a company where they continued to develop their technique, first with Zork I , II and III (the first a reimplementation of Dungeon, the others equally successful sequels). Since then a host of games has been released ( Starcross , Witness , Enchanter are some of the names that come to mind). Infocom today only exists as a label with Mediagenic, the original authors scattered, but the Infocom games are still among the best available today.

Other companies have followed in Infocom's footsteps and a handful of them seem to make a living out of creating adventure games. However, today most of the works are performed by devoted people that produce games for the fun of it, as shareware or completely free.

There have been many attempts to use computer graphics to display the surroundings and objects in adventure games. Some of the more successful are the Sierra OnLine games (notably the Leisure Suit Larry and the Kings Quest series) which have mouse oriented moves but also allows single line text commands, games from ICOM Simulations ( DejaVu and The Uninvited ) which are purely graphics games with mouse and icon interfaces. Other manufacturers have tried to use (some times optional) pictures to accompany the text, for example Magnetic Scrolls games (e.g. the Pawn ), which shift the picture automatically as you move around using the normal directional commands.

A large number of so called Arcade Adventures are also available but they are always more Arcade than Adventure and do not belong in this discussion.

The Alan Adventure Language is designed to aid construction of pure text adventures or, in the words of Infocom, interactive fiction. Possibly, in future versions sound and graphics functions may be available.

2.2 Elements of Adventures

The success of all Infocom games can probably be attributed to three distinctive features. First, they all have a `believable' and consistent plot, which is flavoured with humour and wittiness. Second, the descriptions are extensive and give a lot of atmosphere to the game. Third, the command handler recognizes and understands a large vocabulary and complex input. Add to this the worlds best graphics device (the human brain) and you are unbeatable!

Looking at Adventures in more detail, one sees some common features. There is, of course, a world or universe (called the map) where the Adventure is taking place. Although you can move around quite freely there are usually some problems getting into certain parts of the world (like locked doors, no air to breathe or even finding the entrance).

The size of the map ranges from hundreds of locations (like in some of the Infocom games) to just two or three (some of the Scott Adams games are very compact and very difficult).

Then, there are the objects in the game. These range from your tools, like lamps and shovels, to immaterial things like a hole in the ground, in short, anything you can manipulate. Ideally everything that is mentioned in a description should be an object, but this is normally impossible because of storage limits (and perhaps the stamina of the games designer!).

Most objects have uses. A key is easy to guess how to use, but what about the velvet pillow? Red herring objects are also common in adventuring.

The player must be able to express his wishes. Natural language commands, advocated in many advertisements, are probably overkill since most players do not wish to wear their fingers out typing full sentences, but single verb-object input is not sufficient for a good game either. The player must be able to say things like

> take all except the blue vase


> put the ring and the bag in the box

2.3 Alan Fundamentals

The Alan Adventure Language is a high level computer language designed to make it easy to create text Adventures. The Alan system handles all the tiresome tasks and supplies reasonable defaults so you can concentrate on the plot, the puzzles, the objects and the map.

There are no variables, subroutines or other traditional programming constructs in Alan because Alan is not a programming language. Instead Alan takes a descriptive view of the concepts of adventure authoring. The Alan language contains constructs to make it possible for the author to describe the various features of these concepts. By describing for example how the locations in the adventure are connected you have described the geography in which the story will take place. Much of what should be described is in terms of text that should be output to make the player experience the story that you have designed.

Another fundament of Alan is that the execution of an adventure is event driven. This means that the things happening in the adventure are triggered by one thing only, namely the input of a player command. This command is analysed according to the allowed syntax and transformed into execution of verbs or movements which in turn executes other part of the description in the Alan source. After a player turn other actors can move and scheduled events can be run, then the player takes another turn.

2.3.1 The Map

In Alan, the map is a number of locations connected (or not!) by any number of exits. A location has a description that is presented to the player when it is entered. A location may also have a number of exits stating in which direction the exit is and to which location it leads. Alan places no restrictions on the layout of the map, any topology is allowed. Note, however, that since exits are one-way, an explicit declaration of a backward path (if such is desired) must be made.

2.3.2 The Objects

The other vital entity in Alan is the object. Most Alan objects are things that in real life would be objects too, like a knife or a key. In addition, other things that should be manipulable by the player, e.g. parts of the scenery, must be declared as an object. For example if you require the player to `whistle the melody', then the melody must be an Alan object.

Objects, like locations, have a description that is presented when they are encountered during the game.

Every object may also have a set of properties, like eatable and movable, which may be changed during the execution of an Alan program. Most objects would probably not be eadible so there is also a mechanism for giving default properties to objects.

Some verbs have special meaning or effects when applied to a certain object. These verbs and their effects are also declared within the object.

2.3.3 The Verbs

Verbs are imperative statements input by the player to command some action. These must also be declared in an Alan adventure, either in an object (as described above) or as a general (global) verb that describes the effects of the verb when applied to any object or for verbs to which no object may be given.

To make it possible for the player to input more complex commands a means to specify the syntax for a verb is also available. Using this verbs can also be made to operate on literals (strings and integers) giving the player the possibility to input things like

> write "Merry Christmas, Mr. Lawrence" on the xmas card

2.3.4 The Actors

An extra thrill and dimension are additional characters in the game. These are called actors and have a life of their own. For each move the player makes these programmed characters also get a turn to do their thing. An actor may be a thief running around and stealing your collected treasures, a dragon guarding the entrance to its lair and so on.

Actors get their behaviour from scripts that step by step describes what is going to happen for each player interaction.

One of the interesting things about playing adventure games with actors is to figure out how to interact with and influence the other characters.

2.4 Alan Language Description

Alan is an Adventure language, i.e. a language designed to make it easy to write Adventures. This means that the Alan language must reflect the various entities encountered when creating an Adventure plot.

The first step after having come up with a plot for your Adventure is to draw a map of the world where the Adventure is taking place. For this purpose the LOCATION construct is provided.

The next step is to introduce tools, weapons and other manipulable objects. Here the OBJECT construct is used.

Then the player will need words to command action. The Alan language construct to supply these with is the VERB . You may also define more complex types of player input using the SYNTAX construct.

Additionally, you may also want other characters and creatures in your adventure. For this the ACTOR construct is provided.

2.4.1 The LOCATION

The scene for your Adventure is a series of "rooms" or, rather, locations. They are connected by paths that lead from one location to another, making it possible for the hero to travel through the world of your design, exploring it and solving the puzzles.

What is necessary to describe a location? Every location (or LOCATION , when we are referring to the Alan language construct) must have a name. This is so that you, the designer, may refer to that LOCATION easily, instead of having to remember a magic number for each LOCATION .

Unless you provide other means for transportation from a LOCATION , you should also describe in which directions there are exits and to which LOCATION s they lead.

In fact, this is all that is really necessary in a LOCATION , so lets look at an example (you would probably like to try this out, referring to SYSTEM DETAILS for instructions for your particular system).

	EXIT east TO hallway.

	EXIT west TO kitchen.

START AT Kitchen.

This is a complete Alan Adventure (although very primitive). As you see, every Alan construct ends with a period ('.') and there is also a " START AT" sentence at the end, indicating in which location to put the hero when the game starts.

Run this little Alan source through the Alan Compiler (see HOW TO USE THE SYSTEM and SYSTEM DETAILS ) and try the Adventure. After starting the Adventure, two lines will be shown on your screen. The first line will contain "Kitchen" and the second a ">", which is the prompt for the player to input a command. Now try typing "east". The word "Hallway" and the prompt will appear. Typing "west" will take you back to "Kitchen" again.

We see that the name of a LOCATION is automatically used as a description shown when that room is entered. We also see that the words used in the EXIT -parts are translated by Alan into directional commands that are usable by the player.

You should remember that exits are strictly one-way. An EXIT from a LOCATION to another does not automatically imply the opposite path. Thus one must explicitly declare the path back, in the definition of the other LOCATION .

But just the name of the location is not much of a description. So in order to provide the "purple prose" descriptions often found in high-class Adventures there is an optional DESCRIPTION -clause in the LOCATION . Let us describe the Hallway.

		"In front of you is a long hallway. In one end
		is the front door, in the other a doorway. From
		the smell of things the doorway leads to the
	EXIT west TO Kitchen.
END Hallway.

We introduce another feature in this example, namely the text enclosed in double quotation marks ('"') which is called a STRING or, when used on its own like this, an output statement. When executed this string will be presented to the player and formatted to suit the format of his screen.

Invent a description for the Kitchen, enter it in the Alan source and run the changed adventure. You notice, of course, that the text in the output statements is reformatted during output to suit your screen, in order to make room for as much text as possible. Note also that you do not have to worry about this at all - in your source file you may format the text any way you like.

This type of output statement is just one of the statements in the Alan Language, and we will see more of them later.

It is also possible to have conditions and statements in the EXIT -clauses of a LOCATION to restrict the access to the next location or to describe what happens during this movement.

EXIT west To Kitchen
	CHECK 		kitchen_door IS open
		ELSE "The door is closed."
		"As you enter the kitchen the smell of
		something burning is getting stronger."
END EXIT west.

2.4.2 The OBJECT

Another essential feature in Alan is the OBJECT . Like the LOCATION , the OBJECT is a means to describe the "physical" world where your Adventure is taking place. Most objects are probably used to provide puzzles, like closed doors, keys and so on, but other objects should be promoted to OBJECT s too. A large number of objects that can be examined and manipulated makes a game so much more enjoyable.

OBJECT s, like LOCATION s, have names and descriptions, so you might guess the general structure of an OBJECT .

OBJECT door AT Hallway
	IS closed.
		"The door to the kitchen is a sliding door."
		IF door IS closed THEN
			"It is closed."
			"It is open."

An OBJECT may initially be located at a particular LOCATION (although objects do not have to start at a particular place in which case they are not present in the game until located at some place where the player may lay his hands on them). This is indicated by the AT -clause, in this case telling us that the door is initially located in the Hallway.

In addition, OBJECT s may have attributes indicating the state of certain properties of the object. In this example with a door, the IS closed part indicates that the OBJECT door should initially have the attribute closed set to TRUE (i.e. the door is initially closed). The opposite would be indicated with a NOT, (i.e. IS NOT closed ).

Alternatively, attributes may be numeric (e.g. HAS weight 5 ) or be of string type (e.g. HAS inscription "Kilroy was here" ).

We also introduce another Alan statement, the IF statement. The IF statement allows you to select which statements to execute according to some condition. In the example, the closed attribute of the door selects which description to show. There are further variations of expressions and the IF statement, but we will come back to these later ( Expressions and If ).

Instead let's look at some other statements in relation to OBJECT s.

The attributes of an OBJECT must, of course, be changeable, and this is done with the MAKE statement or the SET statement. For example if the door should be opened (the player having said "open door", perhaps) this could be performed by

MAKE door NOT closed.

or closed (i.e. setting the closed attribute to TRUE again) by

MAKE door closed.

The SET statement changes numeric or string attributes, for example

SET level OF bottle TO 4.

Another OBJECT manipulating statement is the LOCATE statement. This is the statement to use when moving objects from one location to another. Opening a lid might cause a previously hidden object to fall to the floor, something that could be performed by moving the object from a limbo LOCATION to the current one with

LOCATE treasure HERE.

Or to a particular place with

LOCATE vase AT hallway.

2.4.3 The ACTOR

The ACTOR is used to populate the adventure with other creatures. They might be pirates or monsters, but the thing they have in common is that they move around and perform various actions more or less in the same way as the player does.

An ACTOR may have a DESCRIPTION and attributes like OBJECT s and LOCATION s. An ACTOR performs his movements by following scripts, each having a number of steps. Each step corresponds to one player move.

ACTOR charlie_chaplin NAME Charlie Chaplin
	SCRIPT going_out
			LOCATE ACTOR AT outside_house.
			LOCATE ACTOR AT hallway.
			USE SCRIPT going_out.
END ACTOR charlie_chaplin.

2.4.4 The VERB

The VERB is the construct that implements the effects of an action requested by the player. VERB s may be global, local to a particular LOCATION or associated with an OBJECT . We will look at the implications of various combinations of these in the next few sections.

To implement a VERB you need a name for it (which is also the default word the player should input to request that action). You must also decide which effects this verb should have under various circumstances.

If we want to implement the VERB open for the door we could use the following code

VERB open
		MAKE door NOT closed.
END VERB open.

This implementation makes direct references to the door, so to make the verb more general it would instead need to reference the object the player mentioned in his command (see The SYNTAX for a discussion on this). In this case the attribute closed must also be available for all objects (by making it a default object attribute, see Attributes and Default Attributes ).

Of course, there are also conditions that have to be checked before we could execute this code (perhaps to see if it was possible to open the object!). Therefore VERB s may have CHECK s.

Checking Things

In order to assert that the correct conditions are fulfilled before a VERB is actually executed the VERB has an optional CHECK part.

VERB open
	CHECK OBJECT IS openable 
		ELSE "You can't open the $o."
END VERB open.

This is a more probable definition of the open VERB than the previous one. What it means is that before the statements after DOES are executed, the condition after CHECK must be checked (that the object indicated by the player is really openable). If the condition is TRUE then the requirements are fulfilled and the body of the VERB may be executed. If this is not the case, the ELSE part is executed instead (normally some error message).

A CHECK may have multiple conditions as the following code shows:

VERB take
	CHECK OBJECT takeable
		ELSE "You can't take that."
	AND OBJECT NOT IN inventory
		ELSE "You already have it."
		LOCATE OBJECT IN inventory.
END VERB take.

Here we encounter a variation on the LOCATE statement - the capability to place an object inside a container.

Global, Local and Objective VERBs

VERB s may be defined on three levels.

  • Globally. These are always used, no matter in what location the player currently is, or what object he is trying to manipulate.
  • Locally (within a particular LOCATION ). A local VERB is only considered when the player issues the VERB at a particular LOCATION .
  • Within an object. When the player tries to manipulate the object within which the VERB is defined, the VERB definition in that OBJECT is executed.

A VERB may be defined on all three levels (as well as in other LOCATION s and OBJECT s of course), and may have CHECK s in all instances. The implication is that all CHECK s must be passed before any execution and if they all do pass the verb bodies ( DOES parts) are executed. The order is global/local/object.

An example:

VERB throw
	CHECK OBJECT IN inventory ...
END VERB throw.
LOCATION dark_place
	VERB throw
		CHECK "Too dark to aim."
END LOCATION dark_place.
	VERB throw
			"The vase breaks."
			LOCATE vase AT limbo.
	END VERB throw.

The CHECK without a condition in dark_place is called unconditional and is always FALSE (i.e. it will always fall out as if the CHECK had failed).

Now assume the player is carrying the vase at dark_place . He says

	> throw vase

So we have a VERB globally as well as locally and in the mentioned object. The CHECK s are examined in the following order:

  • OBJECT IN inventory? (in the global VERB )
  • unconditional (in the LOCATION )
  • None (in the OBJECT )

We fall out already in the LOCATION (player receiving the response "Too dark to aim.") so the third (empty) CHECK is never tested. Now the player tries the same thing at bright_place where there is no restriction on throwing (no local VERB "throw").

This time there is no local VERB so we skip that level and get the CHECK s

  • OBJECT IN inventory? (in the global VERB )
  • None (in the OBJECT )

Each is tried in turn and none fail, so we can go ahead and execute. This is done in the same order, i.e.

  • LOCATE OBJECT HERE (in the global VERB )
  • nothing (in the LOCATION )
  • ''The vase breaks...'' (in the OBJECT )
  • Note: You can never destroy an OBJECT or remove it from the game. Instead, you will probably need a limbo location, i.e. a location that is not connected to any of the others and may thus be used as a storage for destroyed objects and other things the player is not supposed to see.

2.4.5 The SYNTAX

Normally a verb acts on one object or actor, henceforth called a parameter. This means that the format of player input normally is something like

> take vase

This form, or syntax, is the default form when you don't specify anything else. The default syntax might thus be described as

	? = ? (object)

where the question marks are replaced by the name of the verb.

But in order to allow different and more complex player input the SYNTAX construct is supplied.

The SYNTAX construct is a way to describe the words and parameters the player may use in order to execute a particular verb (its global and more specialised parts). Below is the syntax for put_in , the verb to put something inside a container.

	put_in = 'put' (obj) 'in' (cont).

This syntax defines the put_in verb to be executed when the player has input the word `put' followed by a reference to an object or actor (a parameter named obj ), followed by the word `in' followed by a reference to a second parameter (the container), as in

> put the green pearl in the black box

This will bind the parameter obj to the object that represents the green pearl and the parameter cont to the black box. It is also possible to restrict the types of the parameters:

	put_in = 'put' (obj) 'in' (cont)
			ELSE "You can't put that into anything."
			ELSE "Nothing fits inside that."

This restricts the parameter obj to being an object (as opposed to an actor for example) and the parameter cont to a container object (an object with the container property).

The parameters are used as normal identifiers in the Alan source, provided they are defined in the current context, i.e. they can only be used in the bodies of the verb (see also Run-time Contexts for a detailed discussion).

The SYNTAX construct generalises the verb execution order described previously from execution of verbs in one object, to verb bodies in all the parameters. In the example above, verb bodies in both the object or actor referenced as obj and cont (the green pearl and the black box) are executed (if present in their declarations).

Another use for the SYNTAX is to define the syntax for simple verbs such as quit , score etc. They also need a SYNTAX definition as they do not fit into the default verb/object format. An example would be

SYNTAX q = 'quit'.

But for simple verb/object forms no SYNTAX is actually necessary.

  • Note: In expressions, OBJECT always refers to the first parameter. This makes it consistent with the default syntax of verb/object (and also with the definition of OBJECT in version 1).
Introduction Table of Contents The Language