|Introduction||Table of Contents||The Language|
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.
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 et.al. (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.
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.
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).
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!).
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
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.
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.
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.
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.
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
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.
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 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 .
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).
LOCATION Kitchen EXIT east TO hallway. END LOCATION Kitchen. LOCATION Hallway EXIT west TO kitchen. END LOCATION Hallway. 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.
LOCATION Hallway DESCRIPTION "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 Kitchen." 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.
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 door AT Hallway IS closed. DESCRIPTION "The door to the kitchen is a sliding door." IF door IS closed THEN "It is closed." ELSE "It is open." END IF. END OBJECT door.
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 ).
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 ).
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
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
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.
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.
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 ).
VERB open CHECK OBJECT IS openable ELSE "You can't open the $o." DOES MAKE OBJECT NOT closed. 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 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.
VERB throw CHECK OBJECT IN inventory ... DOES LOCATE OBJECT HERE. END VERB throw. LOCATION dark_place VERB throw CHECK "Too dark to aim." END VERB. END LOCATION dark_place. OBJECT vase VERB throw DOES "The vase breaks." LOCATE vase AT limbo. END VERB throw. END OBJECT vase.
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").
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.
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
SYNTAX put_in = 'put' (obj) 'in' (cont) WHERE obj ISA OBJECT ELSE "You can't put that into anything." AND cont ISA CONTAINER OBJECT ELSE "Nothing fits inside that."
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
|Introduction||Table of Contents||The Language|