CODING ★ 8. TRIGGERS IN AKS ★

Writing Adventure Games on the Amstrad - 00 - ContentsWriting Adventure Games on the Amstrad - 08 - Triggers in AKS
★ Ce texte vous est présenté dans sa version originale ★ 
 ★ This text is presented to you in its original version ★ 
 ★ Este texto se presenta en su versión original ★ 
 ★ Dieser Text wird in seiner Originalfassung präsentiert ★ 

Actions in AKS can be activated in two ways, either directly from the player input, or indirectly inside the program. These are known as triggers and events respectively, and we will look at the former in this chapter.

The format of a trigger command is:

T, word list, condition
A, action

The word list is simply a list of words, which will cause this trigger to become active if they appear in the player's input. These are followed by a condition, which governs the condition under which the actions may be performed. The trigger line is then followed by a list of actions which will be performed.

While triggers are easy to implement, it is important to pick the correct words for the word list, to ensure that you have covered all the possible player input, which should cause the actions to trigger. For example, if the player has to give an object to another character in the game, he might use “GIVE”, but you should also include words such as "SHOW”, “HAND”, etc. Only using one direct phrase such as "GIVE THE COINS”, results in a very limited vocabulary and causes great frustration to the player. You want players to enjoy your game — not tear their hair out while playing it!

There are two forms of trigger in AKS, local and global triggers. The first of these, as their name suggests, are triggers which can only be activated when the player is at the current location, and which are ignored at all other locations. The second type, global triggers, are active all the time, and can be triggered by player input from any location. The AKS system examines the local triggers before the global triggers are searched, which enables you to alter the behaviour of commands within different locations. Let's look at some examples to see what we mean by this, and how to use triggers in your own adventures.

Firstly, the global triggers. These are entered in the database as part of location 0. This is a special location, which does not appear in the actual adventure game — the player can never visit location 0. It is here that we can declare all the synonyms for our global vocabulary. For example, we might want the player to be able to perform a "GET'1 action, enabling them to pick up objects. As well as “GET”, it would be convenient to allow the player to type in “TAKE”, “PICK UP”, and so on. This is done by declaring a global trigger as follows:

T, get, take, pick up,*
A, GE

So, if the player inputs any of the words in the trigger line, then the system performs a GET action. We can do the same for all the usual commands as well — if you look at the listing for WITCH HUNT, you will see that most of the global commands you'd ever want to use have been declared.

The local triggers are very similar to this, except that they are declared within the location description they apply to. They are declared in exactly the same way, so a declaration of:

T, feed ducks, feed duck,*
A, PR, the ducks gobble up all the bread and leave.
A, ZO, 5

would only trigger if it was at the player's current location. If this was true, and the player typed in “FEED DUCKS”, then the system would print the appropriate message and then remove the ducks from that location (the ducks being object 5).

As well as declaring actions which manipulate objects, we can change the possible directions the player can move. If the current location has connections east and west, with a small building to the east, the player can move east or west by using the usual movement commands. However, most adventure players will expect to be able to go east to the building by typing "IN”, not just "EAST". This can be allowed by declaring a trigger such as:

T, in, enter,*
A, GO, E

which will move the player east when they type “IN” or “ENTER".

We can also alter the actions a command word had in each of the locations. For example, suppose we have declared this global trigger:

T, rub amulet, stroke amulet, *C5
A, PR, nothing happens.

If the player rubs the amulet (object 5) the system will simply inform him that "NOTHING HAPPENS". In one location, however, we want rubbing the amulet to actually cause a very different action. This can be implemented by declaring a similar trigger in the desired location. This might take the form of:

T, rub amulet, stroke amulet,*C5
A, PR, The portcullis rises up and out of sight!
A, AF, 10, T

This means that rubbing the amulet causes a message to be printed and the flag 10 to be set to TRUE. This is possible because, as noted before, AKS scans the current location for triggers before scanning the global triggers. When a trigger is found, it is activated, and the trigger search is terminated. This ensures that only one trigger will be activated for each of the player's inputs.

★ YEAR: 1985
★ AUTHORS: Mike Lewis & Simon Price

Page précédente : Writing Adventure Games on the Amstrad - 07 - Actions in AKS?
Je participe au site:

» Vous avez remarqué une erreur dans ce texte ?
» Aidez-nous à améliorer cette page : en nous contactant via le forum ou par email.

CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 617 millisecondes et consultée 722 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.