Text Adventure Tutorial

Part Seven: Tricks and Tips

USING SYNONYMS AND DELETIONS
=============================
By having lots of different 'handles' or alternative words for objects, characters, verbs, nouns and prepositions you can make your game more user friendly, playable and responsive to input. The player then has less trouble getting the program to understand what he/she means.
For instance, if you created a 'bartender' located in a country inn, the player might try and refer to this person as an 'innkeeper', 'landlord' or 'barman'.
A 'knapsack' could be referred to as a 'rucksack', 'sack', or 'bag'.
Remember also that adjectives describing objects should be entered in the 'Deletions' list on the Vocabulary Editor so inputs like:

>get the green bottle out of the red box

might be understood. The words 'the', 'green', 'of' and 'red' should be present in the 'Deletions' List. Also it would be nice to have plenty of acceptable phrases which the player can type to accomplish the desired action by using the forward slash symbol (/) in the initial Response 'words condition' if at all possible eg:

[start]unscrew panel/open panel/unscrew panel with screwdriver/use screwdriver on panel/open panel with screwdriver#........

[start]tie rope/tie rope to tree/tie rope round tree/tie rope around tree#......

Ensure the words you use are KEYWORDS and exist in the Vocabulary.   It would be handy, too, to give suitable replies to player actions which are quite reasonable but not actually required to solve the game eg:

[start]listen[acts]cmessYou listen but hear nothing out of the ordinary.[end]

[start]jump[acts]cmessYou jump off the ground. Whee! That was fun.[end]

More descriptive text can only enhance a game.

MULTIPLE CHOICE ADVENTURES
==========================

These sorts of games can be created in TAB very easily.
Normally in a MCA some text is printed and then a list of choices or possibilities is given to the player to decide which action to take. The list of choices is usually numbered or lettered so that the player simply types in the relevant letter or number to see what happens next.   Example

Location Description (Room 1):

I am in the dark, dingy basement. There is a low tunnel to the east.
A table and chair are here covered in cobwebs. The hermit is here.   What should I do now?

A. Examine the table and chair
B. Enter the tunnel
C. Talk to the hermit
D. Attack the hermit

Please type in your decision: A, B, C, or D.  

>b  

In games like these the only inputs required by the game are the letters (or numbers) of the respective choices, so most of the standard default Response entries will probably not be required, except maybe 'save', 'load', 'look', 'quit' 'score' and 'restart'. You could allow the player to type 'look' to redescribe their surroundings.   Example Response entries:

[start]a#room=1#flag20=0[acts]cmessYou carefully examine the table and chair and find a small golden key!#flag20=1[end]

rem: set flag 20 to 1 when key found.

[start]a#room=1#flag20=1[acts]cmessYou`ve already done that![end]

[start]b#room=1[acts]cmessYou enter the dark tunnel.#room=2#desc[end]

rem: move player into room 2 when option 'B' selected

[start]c#room=1[acts]cmessHermit: "Beware the giant spider."[end]

[start]d#room=1[acts]cmessYou attack the hermit. The hermit whips out a concealed dagger and stabs you through the heart. You are dead!#gameover[end]

CHARACTER MESSAGES
=====================
Perhaps you have designed a 'friendly' character who is to follow the player around most of the time, or is necessary to be on hand to aid the player in some way with game puzzles.
To give the character some semblance of substance or personality you could arrange for short messages to pop up now and again relating to its actions, feelings, conduct or behaviour.
These could be humorous, irrelevant, mischievous or downright rude! for instance:

'The dog barks in delight and wags his tail furiously.'
'The dog groans, covering his eyes with his floppy ears.'

The first one could be printed when the player performed a correct action, whereas the second shown each time the player made a stupid error or mistake...   Character messages could also be output on a specific turn of the game eg Tabletwo entry:

[start]turns=5#charpresent1[acts]cmessThe dog looks at you with interest awaiting your next move.[end]

[start]turns=12#charpresent1[acts]cmessThe dog sniffs the ground trying to catch a scent.[end]

 USEFUL VERBS AND SYNONYMS
===========================
The larger the vocabulary and the variety of actions that can be achieved during a game can enhance and enrich gameplay, so here are some ideas for verbs (doing words) to consider making use of:   search, inspect, tie, fix, fasten, untie, unfasten, undo, drink, eat, consume, swallow, burn, light, open, close, lock, unlock, unscrew, hit, attack, shoot, kill, kick, punch, break, chop, cut, make, use, construct, smash, empty, fill, cast, fly, swim, dive, jump, shout, listen, ask, tell, blow, move, strike, climb, swing, detach, slide, strike, stab, throw, sail, drive, sit, press, push, turn, dial, insert, switch, lie, sleep, help, hint, clue, ride, dig, bend, stretch, lower, lever, fire, release, enter, read, display, status, find, locate, extinguish, laugh, launch, float, build, reflect, shine, hold, wave, buy, offer, give, bribe, select, pull, tug, jerk, drag, say, grab, grasp, kiss, pray, kneel, stand, put, carry, fold, unfold, revolve, lift, tear, eject, draw, knock, roll, extend, retract, squeeze, shake, rattle, study, freeze, strap, hide, spread, scatter, crawl, plant, bury, water, chase, catch, detonate, heat, wash, clean, sweep, brush, paint, paste, glue, wrap, spray, inject, watch, start, siphon, ignite,  write, abracadabra, snap, twist, inflate, pump, stroke, pet, loosen, phone, call,  etc....

If you enter prepositions such as 'under' and 'behind'  together with their synonyms you can make the player inspect things more thoroughly eg: 'look behind painting' ; 'look under staircase'   Similarly 'on' and 'through' can be utilised: 'look on table' ; 'look through window'   And how about 'over' and 'across': 'jump over river' ; 'jump across lake'  

ASKING AND ANSWERING QUESTIONS
=================================
If you are writing a game where the player has to interrogate characters to gain information, why not create the verb 'ask' and the preposition 'about' and devise entries to deal with such inputs as:

>ask <character> about <object/character>

Response example:

[start]ask butler about maid#charpresent2[acts]mess301[end]

A character could also ask a question to the player, cooperating with him if it received a correct reply. To implement this requires use of the 'ask' action and the 'answer=' and answer<>' conditions and a flag usually.

Response entry:

[start]ask goblin about ring#charpresent1#flag20=0[acts]cmessThe goblin screeches: "If you want my help, What`s the password?"#flag20=1#ask[end]

2 Script 2 entries:

[start]flag20=1#answer<>grunch[acts]cmessGoblin: "That`s not the password!"#flag20=0[end]  

[start]flag20=1#answer=grunch[acts]cmessGoblin: "Correct! The gold ring lies in a wooden tree trunk."#flag20=2[end]

See how if the player gets the answer wrong he is able to ask the goblin for another try. The correct answer supplies the hint/clue and flag 20 is set to 2.  

USING THE 'timeout=x' ACTION
======================
You could reduce the time the player can take to enter his input at a critical point in your adventure before something nasty occurred. If the player made a wrong action or took too long in typing in command(s) then the player might be killed and the game ended...
For instance you could tell the player via a message that he had 15 seconds to act before poisonous gas is released.

Script 2 entries, in order:

[start]flag50=1[acts]cmessClouds of poisonous gas billow from vents high up in the wall. You struggle frantically, choking and gasping as the gas takes its lethal effect.... You are dead!#pause5#gameover[end]

[start]flag50=0#room=6[acts]cmessSensors in the floor activate an alarm and trigger an intruder warning. A staccato mechanical voice booms: SECURITY ALERT! DEFENCE SYSTEMS ACTIVATED! YOU HAVE 15 SECONDS TO GAS RELEASE!!!#flag50=1#timeout=15[end]

Response entries:

switch on neutracom/switch neutracom on#flag50=1#here4[acts]cmessYou use the neutracom. The intruder defence mechanism has now been safely deactivated!#score+5#flag50=2#timeout=0[end]

[start]switch on neutracom/switch neutracom on#flag50<>1#here4[acts]cmessNothing happens. You switch it off again.[end]

The second Script 2 entry will be done when the player enters room 6 for the first time. The warning message is given and timeout set to 15 seconds. Flag 50 is set to equal 1.
If the player fails to respond within the 15 seconds or types any valid command except the correct one, then he is doomed, because if flag 50 is still equal to 1 on the next turn the first Script 2 entry will trigger and the player will die thus causing the game end situation!   If, however, the player switches on the neutracom (object 4), assuming it is 'here' (carried, worn or in room) within the allotted time then flag 50 is set to 2, thus overriding the death scenario and jamming the defence systems. The player`s score is also increased for overcoming the problem and timeout reset to 0 to disable timeouts completely.   If the player tries to switch on the neutracom at any other time or anywhere else, before or after this puzzle then the second Response entry is done because flag 50 is not equal to 1.  A puzzle of this nature might make a fine addition to a game as it calls for a quick decision and some nifty typing on the part of the player and increases the tension and excitement factor, putting pressure on the player to react quickly within a few valuable seconds...   

CHANGING STRENGTH AND CARRYABLE VALUES
==========================================
Player strength rating could be increased a result of drinking a 'magic potion', eating an 'energy tablet', wearing a 'mystical amulet', owning a 'spell scroll' and the like.
This might enable the player to carry heavier objects than before and allow progress in the game.
Similarly, the number of objects allowed to be carried could be increased as a reward for overcoming an obstacle or completing a certain task.

Two things that should always be checked are:

1) That the number of initially carried objects at the start of the game does not exceed the Carryable value inserted in the 'Game Settings Editor'.

2)That the total weight of the initially carried objects at the start of the game does not exceed the Strength Rating as entered in the 'Game Settings Editor'. This is only sensible after all and will prevent any problems with object weights.   The action commands for changing strength are:  

strength=x
strength+x

The action command for increasing object carryable status is:

carrylimit+x

where 'x' is a valid number.

These are useful if you are going to progressively increase the values as a reward for finding 'energy boosters' such as a talisman, crystal, tonic or swimming in a sacred pool etc. There are action commands for changing the individual weight of an object:

weightx=y
weightn1=x
weightn2=x

weightobjn1=X
weightobjn2=X

Problems could occur if you INCREASE the weight of an object which is carried or which may be inside a container object that is carried or worn. It could cause problems with the Strength and Carryable reporting system messages. You can, however,  safely change weight values of objects which are not  held, worn or owned in the player`s inventory.   No such problems will occur if you are REDUCING the weight of an object. This can be done at any time without the above problem. eg: a 'bucket' might weigh 5:

[start]empty bucket#here5#flag23=0[acts]cmessBucket - emptied!#flag23=1#weight5=1[end]

A TAB CLOCK
===========

Here`s how to implement a 24 hour game 'clock' in TAB that increases by a minute each turn of the game. It only requires a few short, simple entries.
 
The example below uses 2 flags - 60 (keeps track of hours) and 61 (keeps track of minutes)
 
The first Script 2 entry sets the start time of the clock (12:00) at the start of the game.
 
On each turn the 2 flags are adjusted accordingly.
 
This is an alternative to the 'time' input command that calls the 'clock' action which only displays the internal computer real-time clock and the date and year.
 
The advantage of using a clock devised with flags is that conditions and actions can be carried out at a particular 'game time' by testing the values of flag60 (hours) and flag61(minutes) You can also limit the game to a certain number of hours. eg:
 
[start]flag60=4#flag61=0[acts]cmessIt is four o`clock. Sorry your 4 hours are up! The game is over.#pause5#score#gameover[end]
 
EXAMPLE
---------
Script 2:

[start]turns=0[acts]flag60=12#flag61=0[end]

[start]turns>0[acts]incflag61,1[end]

[start]flag61=60[acts]flag61=0#incflag60,1[end]

[start]flag60=24[acts]flag60=0[end]
 
[start]flag60<10#flag61<10[acts]wintitleThe time is 0%flag60%:0%flag61%.[end]
 
[start]flag60<10#flag61>9[acts]wintitleThe time is 0%flag60%:%flag61%.[end]
 
[start]flag60>9#flag61<10[acts]wintitleThe time is %flag60%:0%flag61%.[end]
 
[start]flag60>9#flag61>9[acts]wintitleThe time is %flag60%:%flag61%.[end]
 
These entries print the time in the window titlebar using the "wintitle" action, so the 'game time' is always viewable to the player. The time is printed in 24 hour format using 4 digits eg: 12:00. eg: 19:17 eg: 00:15 by the "wintitle" action command.

EXIT LISTING
==========
To prevent the player from using a visible listed exit from a location usually requires an extra entry in the Response Editor and use of a flag.

Example:

Location 1:

You are in a square room.
Exits lead: north, south, east, west.

>go east

>A forcefield prevents your passage eastward!

Here the player is informed that a valid exit leads east, but is unable to travel that way just yet because of a 'forcefield'.
This is created in TAB by a Response entry placed BEFORE the standard default 'go %directn1%' entry that deals with player movement between locations eg:

[start]go east#room=1#flag20=0[acts]cmessA forcefield prevents your passage eastward![end]

When the player has solved the 'forcefield puzzle' it is a simple matter to set flag 20 to a value greater than zero to now allow the player freedom of movement to the east from location 1 eg:  

[start]pull lever#room=3#flag20=0[acts]cmessYou pull the rusty lever. There is a crackling noise in the distance as the forcefield is turned off.#flag20=1[end]

Notice how flag 20 is set to 1 so that the normal default 'go %directn1%' entry will now be done when the player tries to go east.

To reveal a new exit in a location requires use of the 'connect' action and use of a flag generally.
Here`s an example Response entry:

[start]press button#room=5#flag30=0[acts]cmessThere is a whirring noise as a panel slides up to reveal a passageway in the northwest corner of the library...#connect5=nwto18#flag30=1[end]

Flag 31 controls whether the button has been pressed or not. When its pressed for the first time the new exit is revealed. This will now be listed as an exit when the player redescribes the location, or subsequently revisits the location (5). The new exit northwest leads to location 18 in the example. Remember to use direction noun abbreviation synonyms within the 'connect' action (except 'in' or 'out' which must be typed in full)   A further 'press button' entry might be inserted in Response:

[start]press button#room=5#flag30=1[acts]cmessNothing happens.[end]
 

To remove a visible listed exit from a location again requires use of the 'connect' action and use of a flag.
Example Response entry:

[start]press button#room=5#flag30=1[acts]cmessThere is a whirring noise as the panel slides down closing the passsageway to the northwest...#connect5=nwto0#flag30=0[end]

The action "connect5=nwto0" in the above entry removes the exit leading northwest from location 5. Flag 30 is reset to 0 to show this has been done.

STATIC OBJECTS/HIDDEN OBJECTS
==============================
A static object is an object (in the object range 1 - 200) which cannot be taken, dropped, worn or removed. It is an object which is a permanent fixture in a location eg: a tree, a postbox, a wall, a fence, a lake or a bush etc.
Static objects are created in the 'Object Editor' just like normal objects. To ensure the object is classed as a static immovable object entails setting the "static" checkbox.
Static objects may also act as containers to hold other objects eg: a box, a hole, a drawer, a cupboard etc.
The static object will be listed along with any other objects in a location under the 'Also visible:' system message. Static objects, which are not containers, can be moved to other locations quite easily to create the illusion of there being more than one such object in an adventure. For instance there may be several 'forest' locations in a game in which the same 'tree' object is permitted to be shown. Only one of these 'trees' may be important in the game and it would be up to the player to discover which one...

Example:   Locations 10 to 14 and Location 21 are 'forest' location descriptions

Object 5 text description: 'a tree.'
Object 5 Noun: tree
Static Object Checked
Start Location: 0 (not created)
Object Message 5: The tree is a large oak. (Object examine message)

Now some entries in the Script 1 Editor:

[start]room>9#room<15[acts]objloc5=room[end]

[start]room=21[acts]objloc5=room[end]

These entries create and put the static oak tree (Object 5) into the locations 10 to 14 and location 21 whenever the player visits those particular locations. An 'oak tree object' will always be present in these locations!   Now example RESPONSE EDITOR entries:

[start]climb tree#objloc5=room#room=21[acts]cmessThis oak is quite gnarled and is easy to climb. You climb up to the topmost branches...#room=30#desc[end]

[start]climb tree#objloc5=room#room<>21[acts]cmessThe bark on the oak tree is too slippery, making it impossible to climb![end]

Only the tree at location 21 can be climbed out of the 6 tree locations. Location 30 would be the description for the top of the tree where there might be a useful object secreted eg:

Location 30:

You sit in the high branches of a tall oak tree. A majestic, panoramic view of the surrounding countryside greets you.
Exits lead: down only.

You can also see:
a golden songbird.

Although in the example only the tree at location 21 can be climbed, the other 5 'tree objects' might have Response entries assigned to them for different actions eg:

[start]shake tree#room=10#flag20=0[acts]cmessYou shake the oak tree violently. Something drops to the ground...#objloc40=room#flag20=1[end]

rem: create Object 40 when tree shook and set flag 20 to 1.

[start]shake tree#objloc5=room[acts]cmessYou shake the oak tree. Nothing happens.[end]

rem: deals with any further shaking or shaking 'tree object' at other locations.

[start]search tree#room=13#flag25=0[acts]cmessYou find a note in one of the lower branches of the tree. You pick it up.#objloc16=501#flag25=1[end]

rem: note found if tree searched in room 13.

[start]search tree#objloc5=room[acts]cmessYou carefully search the tree, but find nothing of importance.[end]
 
This is a good example of how a static object can be used several times in a game and have multiple puzzles assigned to it.

Further Static Object example:

Object 4 text description: 'a wooden sign.'
Obect Noun 4: sign
Static Object checked
Start Location: 0 (not created)
Object Message 4: The sign has something written on it.... (Object examine message)

SCRIPT 1 ENTRIES:

[start]room=20[acts]objloc4=20[end]

[start]room=52[acts]objloc4=52[end]

These entries create and place the 'sign' (object 4) to locations 20 and 52 if the player goes there. RESPONSE ENTRIES:

[start]read sign#room=20[acts]cmessThe signs says: 'BEWARE OF THE DOG".[end]

[start] read sign#room=52[acts]cmessPainted on the sign are the words ABANDON HOPE ALL YE WHO ENTER HERE![end]

Theoretically it would of course be possible to have a 'sign object' like this in every single one of the games locations!!! eg:

SCRIPT 1ENTRY

[start]room>0#room<501[acts]objloc4=room[end]

rem: have a sign in all 500 locations!!!

Thus you can see there are some clever things which can be done with STATIC objects which are not container objects. You could code a similar effect by an even easier method! If the noun word 'sign' or 'tree' was placed in the Vocabulary ORDINARY Noun list (ie not a true object entered in the Object Editor) then you could simply mention the sign or the tree as part of the location description itself (hidden object) and make Response entries for them....

Location 10 (one of the 'tree' locations):

You are in a shady glade encompassed by a vast tract of woodland. The sound of running water can be heard in the distance. A tall tree stands in the midst of small bushes and thorny undergrowth. You can smell the scent of azaleas and primroses. The wood seems thicker to the north through the hazy mist.
Exits lead: north, east, west.

If the 'tree' were a true static object then it would be listed under the 'You can also see:' System Message thus alerting the player to the fact it held some special significance in the game and deserved some further inspection. By 'hiding' or 'masking' it within the confines of the location text description no undue attention is drawn to it. Cleverly disguising things, articles and items important to the game within the location text OR within messages can make a game more interesting and less 'easier' to solve. The player has to proceed cautiously and try more inputs in case anything is missed...   In this instance tree or sign 'objects' wouldn`t come into the equation at all. There would be no need to insert the Script 1 entries for moving the tree or sign either. The Response conditions would just need to check the location numbers and flag values to carry out the Response entries. Here are amended Response entries for the 'tree' example above which produce identical results. Notice that 'room' conditions are used instead.

RESPONSE ENTRIES:

[start]examine tree#room>9#room<15[acts]cmessThe tree is a large oak.[end]

[start]examine tree#room=21[acts]cmessThe tree is a large oak.[end]

[start]climb tree#room=21[acts]cmessThis oak is quite gnarled and is easy to climb. You climb up to the topmost branches...#room=30#desc[end]

[start]climb tree#room<>21[acts]cmessThe bark on the oak tree is too slippery, making it impossible to climb![end]

[start]shake tree#room=10#flag20=0[acts]cmessYou shake the oak tree violently. Something drops to the ground...#objloc40=room#flag20=1[end]

rem: create Object 40 when tree shook and set flag 20 to 1.

[start]shake tree#room>9#room<15[acts]cmessYou shake the oak tree. Nothing happens.[end]

rem: deals with any further shaking or shaking 'tree object' at other locations.

[start]shake tree#room=21[acts]cmessYou shake the oak tree. Nothing happens.[end]

rem: deals with any further shaking or shaking 'tree object' at other locations.

[start]search tree#room=13#flag25=0[acts]cmessYou find a note in one of the lower branches of the tree. You pick it up.#objloc16=254#flag25=1[end]

rem: note found if tree searched in room 13

[start]search tree#room>9#room<15[acts]cmessYou carefully search the tree, but find nothing of importance.[end]

[start]search tree#room=21[acts]cmessYou carefully search the tree, but find nothing of importance.[end]

If you use 'hidden objects' in your adventures the player will tend to want to examine all things which are mentioned in a location text that he/she thinks just might throw up a clue or have some bearing on the game. You should consider having Responses for most things they might conceivably interact with. For example entries might be constructed for the 'azaleas', 'primroses' and 'bushes'  mentioned in Location 10.

Vocabulary Ordinary Nouns required: 'azaleas' ; 'primroses' ; 'bushes'

RESPONSE ENTRIES:

[startexamine azaleas/smell azaleas#room=10[acts]The azaleas smell lovely but make you sneeze![end]

[start]examine primroses/smell primroses#room=10[acts]The primroses smell so lovely. The heady, aromatic fragrance makes you dizzy for a moment...[end]

[start]examine bushes#room=10[acts]cmessA casual inpection reveals nothing out of the ordinary.[end]

[start]search bushes#room=10#flag24=0[acts]cmessA more careful forage in the bushes unearths a glittering emerald which you happily pick up.#objloc6=501#flag24=1[end]

[start]search bushes#room=10#flag24=1[acts]cmessA thorough search of the bushes for anything further reveals nothing else at all.[end]

AUTO DECREMENT/INCREMENT FLAGS
===============================
TAB has flag actions which can be used rather to 'auto decrement' or auto increment a flag  

incflagx,y   - increase flag x by y
decflagx,y  - decrease flag x by y

These useful actions allow the creator to increase or reduce the value of a particular flag by a specified number value. They can be made to do this on each 'turn' of the game.
 
Here are some Script 2 entries that could be used to implement a 'hunger' flag.
In this example the player dies if no food is eaten after 50 turns of game:
 
[start]flag20=0[acts]flag21=50#flag20=1[end]

rem: set flag 21 to 50 moves. Entry only done once.
 
[start]flag21<>0[acts]decflag21,1[end]

rem: decrease or subtract flag 21 by 1 each turn
 
[start]flag21=15[acts]cmessYou are very hungry.[end]

rem: message appears when flag 21 has decreased to 15.
 
[start]flag21=10[acts]cmessYou are absolutely starving for food.[end]
 
[start]flag21=5[acts]cmessYou are terribly weak and are dying from hunger...[end]
 
[start]flag21=1[acts]cmessToo late! Bad luck, you just died of starvation!#pause8#score#gameover[end]

The player dies when flag 21 equals 1 and the game ends.
 
If food is eaten then a successful RESPONSE 'eat food' entry might reset flag 20 to 0 again to restart the 50 moves once more, or set flag 21 to 0 to show that the food puzzle has been solved for good!
 
I used 'hunger' just as an example.  I don`t particularly prefer games where the player has to continually search and devour food and drink water to survive or exist.   Increasing or decreasing a flag in this manner can be successfully employed for puzzles which require a fixed number of turns to be solved in, and by outputting messages, such as those above, the player can be warned that something needs to be done or there will be soon be disastrous consequences! eg:   A roaring tiger may attack and kill the player unless he deals with it within 3 game turns.

RANDOM NUMBERS IN FLAGS
==========================
User Flags can be loaded with random numbers using the flag action command:

randomizeflagX,Y      (X=flag number ; Y=maximum numerical value)

Inserts a random number from 1 to Y into flag X.

eg:

randomizeflag15,20 would cause flag 15 to hold a random number in the range 1 to 20.

EXAMPLE SCRIPT 2 ENTRIES:

[start]f30=0#room=5[acts]randomizeflag40,36[end]

rem: flag 40 set to random number (1-36) each turn of game when player in location number 5.  

[start]flag40=10#notcarr12#room=5[acts]cmessA deadly dwarf jumps from the bushes, and in a surprise attack viciously stabs you dead!#pause5#score#gameover[end]

Here there is a 35 to 1 chance of the player being killed in location 5 each turn he is there (ie when random  number=10) unless he`s carrying object 12 as protection. (a sword, perhaps)

[start]flag40=10#carried12#room=5[acts]cmessA deadly dwarf jumps from the bushes in a surprise attack. Observing you are armed with the silver sword, it hastily backs away and disappears into the bushes...[end]

If the player IS carrying suitable armoury, there is the same  35 to 1 chance this message will be printed instead. (when flag 40 equals 10)   As you can see it is purely by chance that these messages will appear during the game, if at all.

This is just a simple example, but  I am sure you will be able to think of many more ingenious ideas for using flags in conjunction with random numbers that will give your players the sense that new and unexpected occurrences can take place during your adventure. Impromptu events like this may add a touch of realism to your plot scenarios.

GO TO PART EIGHT

Copyright catventure © 2006 , All Rights Reserved.