ThinBasic Adventure Builder (TAB)
=======================
USER GUIDE - TUTORIAL 
Author:  Catventure. 2026
========================
For PC Windows platform (XP and above) ; 32bit/64bit

An offline, parser-based interactive text adventure creator for Windows XP and above.

I have made this project to be available to all and be within the reach of anyone who is interested in using it to write text adventure games for the enjoyment and benefit of the Interactive Fiction community at large.

Contents of TAB directory
====================

Program/Application Files:

"tab_editor.exe" - TAB Adventure Editor
"tab_player.exe" - TAB Adventure Player

"graphics" directory - holds in-game graphics. (can be: .jpg, .png, .bmp, .gif)
"sounds" directory - holds music and sound files. (can be: .wav, .ogg, .mp3, .aiff, .mod)
"icons" directory   - holds 4 icons. Must be in 32x32 size format and keep same filenames.

TAB Adventure Datafiles (in 'adventure_games_to_play' dir):

"cloak_of_darkness.tab"
"character_demo.tab"
"default.tab"
"char_commands_demo.tab"
"door_demo.tab"
"tutorial.tab"
"graphic_demo.tab" (not included with the text only version of TAB)
"crystal_keepers.tab" (demo game)

"splash.bmp" - intro graphic

"readme.txt" - version history

"language.txt" - conditions and actions coding language.

"usertutorial.txt" - this user guide and tutorial.


What Is A Text Adventure?

Well, basically its a program, written by one or more persons, that has a plot - a storyline, a theme.
It can be text only or may have additional graphics and sound. As with a book or film, it has a beginning, a middle and an end. Usually there is a quest to complete, a destination to be reached or a mystery to be solved.

The computer text adventure differs to the book or film in that it is INTERACTIVE. The player actually participates in the game and affects its outcome. The player decides to some extent how the game will progress and has some control over the way the game unfolds.

The player will normally assume the role of the main character hero, who must be guided through a series of places, locations, exploring scenery, examining and searching things and collecting items and weapons which may be needed to use in various ways to overcome obstacles, solve problems, score points or make progress. The player may encounter other characters on his/her travels through the adventure world who may be friendly or hostile. Interaction with them may be essential to completing the quest. Some may provide a hint or clue on how to proceed in return for a gift or favour. Others may be downright deadly and have to be disposed of cleverly.

Interaction is accomplished via the keyboard. The player types in the commands and instructions in simple English words and sentences. These are then carried out by the program, and the results or consequences of the player`s input is then displayed on the screen. The player can then see how his/her actions have affected the current state of play and what, if anything has changed or altered.

As in the real world, the player is called upon to make decisions, choose paths to follow, weigh up alternatives and consider taking chances or risks. A wrong decision may result in loss of points, death or the necessity to restart the game.

The author of the adventure may have included 'red herrings' which might confuse, thwart or sidetrack the player from the main object of the quest. As with crosswords, cunning, logic, and lateral thinking may need to be employed in solving some of the more 'trickier' puzzles. There is the reward and satisfaction to be gained from completing tasks, making headway and discovering new areas of the game.

A good adventure will be well written, have an exciting, intriguing and memorable plot, unforgettable characters and challenging problems to contend with, and ultimately a satisfactory conclusion. It should be user friendly, have a large vocabulary and cater for the many responses and inputs a player might make.

Unlike its frenetic, joystick waggling space invader, shoot' em up, arcade game cousins, the text adventure is an altogether more different type of beast. More sedate, more laid back, cerebral and intellectual, it allows the player to move at his own speed, in his own time and ponder a planned course of action. It exercises his innate mental abilities, rather than his digital dexterity on a push button joypad.

Some games can be solved in a couple of hours or less, others take longer, maybe a week or two. A really complex one may require MONTHS, depending on the players skill or expertise.

If you have never played one before, I urge you to try a few. You might be pleasantly surprised. They can be a welcome diversion from the stresses and strains of modern day living. After playing some you may decide to have a go at making your own using an adventure construction program such as INFORM, HUGO, TADS or ADRIFT. Alternatively you can check out this "ThinBasic Adventure Builder" (TAB) which is being developed with the thinBASIC script automation language.

Interactive Fiction Text Adventure Commands.

Typical standard adventure commands used in most adventures:

Movement:
north, south east, west, northeast, northwest, southeast, southwest, up, down, in ,out
and abbreviations:

n, s, e, w, ne, nw, se, sw, u, d, in, out

eg:

>go north
>sw
>go out

Actions:

get, drop, wear, remove, examine, search, open, kill, eat, read, etc.
eg:

>get the knife
>drop all except the rope
>wear the red hat
>remove the hat
>examine a long rope
>search the cupboard
>climb tree
>drink water
>tie the rope to the tree
>light the lamp with the candle
>attack the giant
>open the ornate door
>unlock the chest with the silver key
>jump over hole
>talk to the ogre
>look under the bench
>press green button
>take everything but the gold pin out of the metallic box
>drop the pencil into the box
>look inside the bag
>follow the witch
>stop following

In many cases synonyms for verbs, nouns and prepositions will be understood.

TAB System Commands:

inventory or i - list objects carried and worn
score - display score and turns taken
wait/z - wait a turn
look - redescribe location
load - load a saved game position file
save - save current state of game
quit - quit game
restart - restart game from scratch
time - display time and date
again/g - repeat previous command
help - may or may not supply a hint/clue, or give a list of acceptable commands. 
undo - undo last turn (back one move)
quicksave/quickload - takes a temporary 'snapshot' of the current game position; reloads 'snapshot' game position
transcript - log a game transcript file

In TAB the [F1] Function Key holds up to the last 10 player input commands history which can be scrolled and edited in the Input Command textbox. 

TAB consists of 2 programs:

The TAB Editor (tab_editor.exe) allows you to construct, save and test your adventure games.

The TAB Player (tab_player.exe) is the Runtime version of TAB that plays game databases independent of the Editor for standalone adventures.

Included with the download are a few demo example databases made with TAB.
These can be found in the "ADVENTURE GAMES TO PLAY" folder.

Check out these small adventures, try the demo's and familiarise yourself with the various Editor and Player menu options.

There now follows some BASICS about the various TAB Editors...



LOCATIONS
==========
Room Descriptions, a brief description of it, and the direction exit connections between them.

These are the places the player can visit and usually describe the surroundings and scenery and the sights and sounds in the vicinity of the player. The exit direction boxes indicate the location to go to if the player moves that way.

If an exit direction is set to 0 then the player will be unable to go that way. You can also enter a 'brief' description of the room.

Any data entered is auto-accepted by TAB when you go [Back] to the Editor or if you use the [>], [<], and [Go] buttons to move forward and backward through Location numbers or if you move to a different location via the [Find Loc Text] button or the [Edit Location] dropdown listbox.
Type bits of valid Location text into the [Find LocText] editbox and click that button to go to locations that contain it or select a Location for editing by choosing  from the dropdown list and clicking [Edit Location]. 

There is a limit of 500 locations. 


Making a Dark Location
=================== 

A location can be initially set to DARK by Inserting a "!" (exclamation mark) as the first character in the 'Brief' description textbox.

eg: !Dimly Lit Cave

When the player visits the room the location text will not be described and they will receive System Message 78: "It's too dark. You can't see anything." instead.
However, if the player is carrying a lightsource object such as a torch or a lamp, or if a lightsource is present in the room, then the location, exits and objects visible will be described as usual.


Location Display
==============

There are some system commands that can be inputted by the player that can affect the way a location is described:

brief - show only brief one-line abbreviated room description.
verbose - show the full, verbose room description.
exits on - list any exits visible.
exits off - do not list any visible exits.


Random Locations
==============

The "randomroomX,X,X,X,X,X...." action command could be used to randomly select one of the room numbers indicated eg:

#randomroom1,5,23,56,70#desc#

would put player in a random pick of one of the above rooms 1,5,23,56 or 70 then describe the room.

There's no upper limit on the number of random rooms you can list - but they must be VALID location numbers.


Random Location Text
==================

Locations can also be set to display a RANDOM description each time it is visited. There is no fixed upper limit to the number of random elements a location text may contain.
It is simply a matter of embedding multiple %r% tags.
Here is an example template to show the correct format:

Location 3 text:
You are in a small cramped room.
%r%The room you are in is very small with not much room to move about.
%r%This small room you stand in is very narrow and cramped.
%r%This small room seems very cramped.
%r%The small room. Very cramped and uncomfortable.

(Each random element should end in a carriage return (newline) except for the LAST random element)



Cyclic Location Descriptions
=======================

Similarly, Locations can also be set to display a CYCLIC description each time it is visited. There is no fixed upper limit to the number of cyclic elements a location text may contain.

Example uses %c% -  tags to enclose elements of the cyclic location text:
Here is an example template to show the correct format:

Location 3 text:
%c%You are in a small cramped room.
%c%The room you are in is very small with not much room to move about.
%c%This small room you stand in is very narrow and cramped.
%c%There is not much space in here and it's awfully cramped.
%c%The small room. Very cramped and uncomfortable.
%c%

(Each cyclic element should end in a carriage return; newline) 

Cyclic location text can repeat cycle or stop at the last element of a cycle (using the %end% tag)
Here is an example template to show the correct format:

Location 3 text:
%c%You are in a small cramped room.
%c%The room you are in is very small with not much room to move about.
%c%This small room you stand in is very narrow and cramped.
%c%This small room seems very cramped.
%c%%end%The small room. Very cramped and uncomfortable.
%c%

Note that %r% (random) tags can be NESTED inside cyclic elements too so some quite clever text outputs can be achieved!

Alternative Location Texts
====================

A location can now have alternate, changing or different descriptions. (individual elements in a location text)
A spare User Flag needs to be loaded with a special numerical value to indicate to TAB that a location contains alternate location descriptions and that when doing a location describe to simply print out a particular numbered alternate description from out of the location text.
An example:

Room 5 is required to contain ALTERNATE descriptions.
We will also use a spare flag say... flag 31

At the start of the game we decide that we want to print the FIRST alternate description of room 5 when the player arrives in it - until, that is, we decide otherwise...

Because it's room 5 we load flag 31 with 5000 + THE NUMBER OF THE ALTERNATE DESCRIPTION!

In this case it will thus be set with the value: 5001

The formula is:
Flag Value = (room number * 1000) + THE NUMBER OF THE ALTERNATE DESCRIPTION

So we go to the Script1 Coding Editor and put in an entry early on to put in an ACTION #flag31=5001# like so:

[start]turns=-1[acts]flag31=5001[end]

"turns=-1" (minus 1) action ensures that this entry will be done before the game starts properly and before the turnscount is initialised...

(We might need also to set in that entry any more flags relating to OTHER alternate description rooms too that we might be using in a game so that TAB "knows" what to do)

Now we go to the Location Editor to enter our room description(s) for Location 5. We have decided beforehand that there will be 4 alternate scenes for room 5. (although most will probably use only 1 or 2 usually to reflect little changes in the room atmosphere etc) We will use bracketed number tags to make plain to TAB the starting and ending points of each individual segment...

Location 5 text description(s):

[1]This is the first room 5 description.[1]

[2]This is the second room 5 description.[2]

[3]This is the third room 5 description.[3]

[4]This is the fourth room 5 description.[4]

You can use carriage returns to space them out for clarity.
The number tags [x] are important and *MUST* be present for correct textual output.

TAB will grab the chunk it needs from between the number indicators BEFORE it goes on to do the checks for random formatting etc. - so it would be perfectly possible to include random elements within each alternate room description too!

Recap:

If the location were 16 and the spare flag used 56 we'd need to set an action such as:
#flag56=16003#
which would cause TAB to only print alternate description 3 of room 16

If the location were 500 and the spare flag used was 1 an action such as:
#flag1=500002#
would always print the second alternate description of room number 500.

I am sure you will think of times when it may be handy to use slightly different or altered descriptions after certain puzzles or changes in a game have occurred and changed the background scenery in the room. Now it will be possible.

For example, let's say a room description says "There is a closed cupboard." in the text.

The Player opens the cupboard (if this were successful then use the action to set a new "alternate room description flag")

The new room description could now inform the player somewhere in text that: "The cupboard door has been opened."

Important: If you apply this alternative room description feature for the initial game START LOCATION room you must set the flag via MESSAGE number 500 instead of the Script coding Editors. You can also set the flags for other rooms there at the same time if you wish...
For instance if you typed in:

flag31=1001

as Message 500 that would inform TAB to use the first Location 1 description when it describes the START LOCATION

flag31=1001#flag32=2002#flag33=3004

would set the starting default descriptions 1, 2 and 4 for locations 1, 2 and 3 respectively. (# hash is used as separator)

These flags can be changed via coding entries to cause TAB to print the desired location text as and when required.

Message 500 is ONLY really used for this purpose if the OPENING location in the game contains alternative location text descriptions.  

 

Formatting Location Text
====================

Text formatting in TAB text output uses UBB's code for
bold, underline, italic and strikeout eg:

[b]This is bold text[/b] and [u]I am underlined.[/u]

[i]This is italic text[/i] and [s]I am strikeout.[/s]

Good for highlighting or enhancing adventure text.

[left], [right] and [center] UBB embedding codes for
aligning paragraphs of text eg:

[center]I am centered text.[left]

Centres a line/paragraph then goes back to left alignment. 

There are also tags for font and fontsize:

[font=FontName]      set font to use  eg:

[font=Arial]

[size=xx]                  set font size eg:

[size=12]

Text color and backcolor tags; I like to think of them as pen and paper!

[color=%rgb_color] ; [bcolor=%rgb_color] ; [/color]

Usage examples:

[color=%rgb_beige]I am some beige text.[/color]

[color=%rgb_red]I am printed in red.[/color] 

[color=%rgb_red][bcolor=%rgb_black]I am red text printed on a black background.[/color][/color]I am default text color with normal control color background.

The second [/color] turns off the black background text color and reinstates the previous back color. (in this case the default)

There is a large list of acceptable %rgb_colors in the "language.txt" file.

(There are also action commands that can be used in coding entries for aligning text, setting font name and size and background and foreground colors)

Refreshing Text in a Location
=======================

Coding Action "cleartext" could be used to to clear the adventure window of all text. Text begins scrolling from bottom of richedit after this action.

[start]look[acts]cleartext#desc[end]

This would refresh the text window each time the player typed "look" to redescribe their surroundings.

An example of this is in the demo file: "character_demo.tab"


Locations and Flags
===============

There are a couple of actions where a room number can be changed to the room number held in a user flag eg:

room=flagX - set current location to be value of room integer held in flag X.

gotoflagX - go to the room number held in flag X and describe the room.

There are also some associated conditions with this:

room=flagX - check that the room is the same number as held by flag X.
room<>flagX
room>flagX
room<flagX
room>=flagX
room<=flagX


Locations and Graphics (Not applicable to this text-only version)
=================

If you want to use graphics then you need to get one of the graphics versions of TAB from the main site.

The display mode for graphics games is "2" so that should be set on the Game Settings Editor.

If the adventure is text/graphic (mode 2 in "Game Settings Editor") then Locations can have graphics assigned to them. These will be shown when the player arrives in a location or when a location is redescribed.

The image files should be held in a dedicated graphics folder within the main directory.

Acceptable image formats for the in-game graphics are: .jpg, .png, .bmp, or .gif.

To link an image to a location number each one required should have a corresponding filename. For example: 

locX.gif

(where X is the number of the associated location/room.)

This will be displayed in the upper graphicbox.

"logopic" (game title graphic) must be the name for an image which is shown by default in the lower graphicbox.

Note: a similar simple default naming and numbering is used for Object and Character images too eg:

charX.bmp
objX.png

These could be shown in response to player inputs. such as:

>look at <character>
>look at <object>

There are some special actions for showing images in the 2 graphicboxes in "language.txt" file.


Location Conditions and Actions
======================== 

There are many other conditions for checking locations, and actions for moving the player between locations when required. There are useful conditions and actions for dealing with characters and objects in association with locations too. For instance checking whether an object is or isn't there or if a character is present in the room or not etc...
Also, the "connect" action can open up new exits and/or remove an existing exit in a location.

See the "language" file for full list.



OBJECTS
========

Items/things which the player can examine, use or manipulate in some way. Objects can be set to be carried, worn or in some container or they can be a static, immovable type of object. Objects can be set to start off in a particular room or be flagged as currently not existing in the game. During a game an object can be destroyed, created or moved to different places. Objects can also be set to have a weight and size attribute as well. In the Object Editor you can enter the keyword Noun and any synonyms for it plus a short description of the object and a more explanatory text for if the player examines it closer.
There is a limit of 200 objects.

From the Objects Editor you can enter the Object text description eg:

"a coil of rope."

It's Vocabulary Object Noun keyword and any synonyms eg:

/rope/

/rucksack/sack/bag/knapsack/

rucksack is the KEYWORD ; sack, bag and knapsack are possible SYNONYMS of it.

A message for when the player EXAMINE'S an object eg:

"The rope is strong and quite long."

You can also set the Object's start location in the game, its weight, and size attributes too.

If an object starts off at 0 - that means it does not yet exist in the game or is not created just yet.

if an object start room is set to 501 or 502 that refers to the player's carried or worn location respectively.

An object can also start off being carried or worn by a Character.
Characters 1 to 100 use location numbers 601 to 700 for their carried inventory, and they use location numbers 701 to 800 for their worn inventory, so a start location of 734 would mean the object started off being WORN by Character #34. An object start location of 601 would mean the object began being CARRIED by Character number 1.

An object can also start off inside another object which is flagged as a container...

Container Objects:
Just as in the 80's QUILL or PAW creators if an object is a CONTAINER then the corresponding location number is used as its "inside". So these locations should not be used for normal game location text descriptions.

For instance a container object #3 such as "a box." would require Location #3 to hold its contents....  An important design consideration for your game.

Objects can be initially "placed in" such a container by entering the Object Start Location with the number corresponding to the "inside of the container". In the above example any object starting at 3 will begin inside the "box".

An object can also be checked as a container, be wearable, be a lightsource or be a static object. Only Static objects can have a weight of 500.

If an object is a lightsource and is present in a DARK location then the location will be described normally otherwise if no lightsource is present in a DARK location then System Message 78: "It's dark. You can't see anything" is printed.
Location pics, exits, objects visible, and any characters present will not be reported when the player is in any 'dark' rooms.

Any data entered is auto-accepted by TAB when you go [Back] to the Editor or if you use the [>], [<], and [Go] buttons to move forward and backward through Object numbers or if you move to a different Object via the [Find ObjText] button or the [Edit Object] dropdown listbox
Type bits of valid Object text into the [Find ObjText] editbox and click that button to go to objects that contain it or select an Object for editing by choosing from the dropdown list and clicking [Edit Object]. 


Object Conditions and Actions
========================

There are many special object conditions and actions that deal with checking and altering an object location and/or its attributes.

See the "language" file for full list.


Random Object Text Messages
======================== 

Object text descriptions and Object Examine messages can use %r% random tags as with Locations above.

Example:
An Object Text RANDOM description might be:

"a knife.%r%a sharp knife.%r%a knife. (looks like a penknife)%r%A knife. Slightly bloodstained."

Alternative Object Examine Messages
=============================

Alternate 'Object Examine' messages, can be entered into the Object Editor using the same procedure as with Locations above; using the flags with the following formulas:

The formula for alternate object examine messages:
Flag Value = (object number * 1000) + 100 + THE NUMBER OF THE ALTERNATE DESCRIPTION

If using alternate descriptions do not forget to set the relevant flags to contain the default starting description (formula value) in a coding table so as to trigger before a game starts.

This is useful if an object has been changed or altered in some way and thus needs a new examine message to reflect and update that fact in an amended text.

So we go to the Script1 Coding Editor and put in an entry early on to put in an ACTION #flag32=30103# like so:

[start]turns=-1[acts]flag32=30103[end]

"turns=-1" action ensures that this entry will be done before the game starts properly and before the turnscount is initialised...

Sets object 30's examine message to only print description 3 each time the object is "examined".


CHARACTERS
===========

Characters can be people, creatures, monsters and the like which are to appear in your game and thus make the game scenario a bit more interesting and colourful.

They can also move about in the game world independently (randomly?) according to their own whims or desires in valid directions - or they can be assigned a preset movement path (or pattern) following a list of specified directions.

If a character is in a player's location then TAB will announce the fact via a message such as "A farmer is here." TAB will also report if a character enters the player's vicinity or departs to move on to another location.

Like Objects the Characters have their Noun, 'examine message', start location, and other numeric and alphanumeric fields for their sex/gender and movement status which can be static, random moving, follow the player or move according to specified directions.

It is important that your Noun Keywords for characters be an occupation, trade, profession or a type of creature eg: 'blacksmith', 'dwarf', or 'bartender'.

An adequate, albeit limited form of interaction is possible by allowing the player to 'talk to <character>' when the character is present.

Characters really liven up an adventure and could be made to impart a message or provide a hint or clue. You can also allow the player to offer an object to a character to gain its trust or cooperation or to appease it in some way to make it more friendly or helpful.

This could be done by devising a 'give <object> to <character>' command. Each character has its own carried and worn inventory locations.

Locations 601 to 700 are the Character carried inventories.
Locations 701 to 800 are the Character worn locations

It will be possible to design responses to player commands such as:
'ask <character> about <object>/<character>'
'tell <character> about <object>/<character>'

Setting a Character to "random" will force the character to move randomly, roaming through the game world seemingly according to its own wishes or intelligence! They appear to move when they feel like it!

A random moving character may stay at a location for several game turns before 'deciding' to move elsewhere or it may go off on its travels for three or four successive turns before 'waiting' around again.

This adds a nice touch of realism to games. In general, the more exits in a character location then the more chances of movement from it. (because the odds of the random direction number matching a listed exit are greater)

Randomly moving Characters can be restricted from certain places and areas of the game which you do not wish them to visit as well.
To prohibit a character from travelling via exits which would lead to off-limits location(s), it will be necessary to construct a special "walk pattern" defining the locations which the random character is barred from entering. The pattern should consist of the location numbers to which access is prohibited, and each valid location number should be surrounded by a letter `x`. eg:

walk=x12x25x47x56x101x

[Char can move randomly e(x)cept via e(x)its which would lead to locations 12, 25, 47, 56, or 101.]

This type of walk pattern is input as normal from the Character Editor
(or you can use the 'pattcharx=' Action within coding entries)

This sort of walk pattern means you can confine random moving characters to specific areas, realms or parts of your game map. For instance a vampire might move randomly in its 20 underground locations, a dwarf might move anywhere except the palace and the gardens...etc

Setting a normal "walk pattern". This is a predetermined sequence of moves for a character to execute. The character will carry out these moves, one at a time, each turn of the game. When the character has completed its travels, its movement pattern will be repeated again from the start. Therefore, the character will follow this same series of moves continuously until you decide otherwise.
These "walk patterns" are useful for controlling a characters movement and for confining a character to a specific area or part of the game.
eg: a robot could be created for patrolling a particular section of an industrial complex...

It will also be possible to cause the character to pause or wait in a room for a turn or turns as part of its walk pattern. The player may be able to follow a character around on its journeys to see where it goes and what it may do. To follow a character simply type: 'follow <character>' from within the game. Whenever the character leaves a location at which the player is present TAB will cause the player to follow it to its next port of call. This will continue to happen until the player simply types 'stop following' or decides to follow another character instead.

Setting a Character to "static" means the Character is non-moving and will remain in its current location unless you, the author, decide otherwise.

Setting a Character to "follow" will cause the character to follow the player when he or she next moves in a valid direction from a room.

There is a limit of 100 Characters.

You can create random character name text, random character examine text and random character "announcement" text using the %r% tag.

Example templates:

Character name random text: 

"the farmer%r%Joseph the farmer%r%Joseph%r%Farmer Joseph"

(printed when a character moves to or from a room or if the character name is caused to be printed in a message)

Character examine random text:

"The farmer is a local yokel.
%r%The farmer is built like a brick outhouse.
%r%Joseph the local farmer is a big, hefty man.
%r%Farmer Joseph is a strong but friendly person." 
 (printed when a character is examined) 

Character announcement random text:

"a farmer is here.%r%Joseph the farmer stand near you.%r%Joseph is by your side.%r%Farmer Joseph watches you with interest."

(printed after location, exits and objects visible are printed)

Any data entered is auto-accepted by TAB when you go [Back] to the Editor or if you use the [>], [<], and [Go] buttons to move forward and backward through Character numbers or if you move to a different Character via the [Find Char Text] button or the [Edit Character] dropdown listbox.
Type bits of valid Character text into the [Find Char Text] editbox and click that button to go to Characters that contain it or pick a Character for editing by choosing from the dropdown list and clicking [Edit Character]. 

Alternate Character message text
===========================

The formula for ALTERNATE character examine messages:
Flag Value = (character number * 1000) + 200 + THE NUMBER OF THE ALTERNATE DESCRIPTION

The formula for alternate character announcement texts:
Flag Value = (character number * 1000) + 300 + THE NUMBER OF THE ALTERNATE DESCRIPTION

If using alternate descriptions please remember to set the relevant flags to contain the default starting description (formula value) in a coding table so as to trigger before a game starts.

Go to the Script1 Coding Editor and put in an entry early on to put in an ACTION #flag33=2202# like so:

[start]turns=-1[acts]flag33=2202#flag34=11301[end]

Sets Character 2's examine text to be text description 3; sets Character 11's announcement text to be segment 1.

"turns=-1" action ensures that this entry will be done before the game starts properly and before the turnscount is initialised...



MESSAGES
=========

These are text messages which can be outputted to inform the player of certain information or as result of things that have happened in the game or as a consequence of their input commands. Messages can be inserted, amended or deleted.
There is a limit of 500 Messages.

Any data entered is auto-accepted by TAB when you go [Back] to the Editor or if you use the [>], [<], and [Go] buttons to move forward and backward through Message numbers or if you move to a different message via the [Find Mess Text] button or the [Edit Message] dropdown listbox.
Type bits of valid message text into the [Find Message Text] editbox and click that button to go to Messages that contain it or pick a Message for editing by choosing from the dropdown list and clicking [Edit Message]. 

Note that Messages 1-500 do not end in a carriage return linefeed - unless you explicitly enter one - so you can combine messages to make a kind of "multi-message". An example of this is in the demo: "character demo.tab"

Script 2 entry:
' show a multimessage on turn 8 of game...
[start]turns=8[acts]mess1#mess2#mess3#mess4[end]

This prints: 
"This is an example of a single text output made up of 4 separate messages in the Message Editor." 

There are also other ways of printing message text via coding actions. For instance the "cmess" (custom message) action:
cmessI am a custom message that can contain formatting and various other %tags%.

Random text elements using the %r% tag can also be used in messages 1-500.

You can have Cyclic Messages but they will ONLY work properly if called using the "cyclemessX" action where X is a valid message number in the Message Editor. 

Example Message uses %c% -  cycle tags to enclose elements of the cyclical message:

"%c%I am the cycle 1 text.
%c%I am the cycle 2 text.
%c%I am the cycle 3 text.
%c%"

As with Locations, Cyclic messages can repeat cycle or stop at the last element of a cyclic message (using the %end% tag)

"%c%I am the cycle 1 text.
%c%I am the cycle 2 text.
%c%%end%I am the cycle 3 text.
%c%"

Note the carriage returns after each message element
Note that %r% (random) tags can be NESTED inside cyclic elements too, so some quite clever text outputs can be achieved!


SYSTEM MESSAGES
================

These messages form an integral part of the system and TAB uses them to print appropriate responses to player commands. You should be careful not to delete any of these messages - but if you should accidentally do so, then a full list is present in the "default.tab" database so you can re-insert them. Note that some entries have leading or trailing spaces to allow correct spacing when printing occurs. The entries are however configurable. That is, they can be customized to your own preference.
For instance, you could change all the messages to read 'I' instead of 'You', thus, 'You now have the ' could be changed to read 'I now have the '. etc.
Be careful if you amend a System Message to maintain the meaning and content of the message so that the TAB reporting system works properly.
There is a limit of 100 System messages.

Any data entered is auto-accepted by TAB when you go [Back] to the Editor or if you use the [>], [<], and [Go] buttons to move forward and backward through System Message numbers or if you move to a different System message via the [Edit SysMess] dropdown listbox. Click that button to go and edit a selected System Message.

Most System Messages may use %r% random text elements eg:

System Message 40:
"Also here you can see:%r%Visible objects are:%r%Notable things of interest are:%r%Also visible:%r%You can also see."
 



VOCABULARY
===========

This Editor will comprise all the words which the game will understand. Verbs, Nouns, Object Nouns, Character Nouns, Prepositions, and Deletions listboxes.

There are some reserved WORDS and corresponding NUMBERS in the Vocabulary used by TAB which should always be present in a game database. These are:

VERBS
1. /go/

NOUNS
1. /north/n/northward/northwards/
2. /south/s/southward/southwards/
3. /east/e/eastward/eastwards/
4. /west/w/westward/westwards/
5. /northeast/ne/
6. /northwest/nw/
7. /southeast/se/
8. /southwest/sw/
9. /up/u/
10. /down/d/downwards/
11. /in/inside/
12. /out/outside/
13. /all/everything/lot/
14. /it/them/him/her/
15. /me/myself/self/
16. /following/

PREPS
1. /but/except/

Be careful not to delete these or change them significantly.

In addition to these there are other verbs, nouns and prepositions that need to be present in order for a game to respond properly with the "inbuilt" pre-designed, default coding responses that have been constructed to automatically handle many basic player inputs.

Check out the "default.tab" database which is to be used when starting to build your game to see what words are already present and what words TAB understands or expects to be typed by the player.  

Synonyms are just words which mean the same as other words.
When you enter a word in the Vocabulary, and you subsequently enter a word (or words) which is (are) to be deemed the same - You must decide which of the words shall be nominated as being the KEYWORD. 

For instance if you decide to enter the verbs 'tie', 'fix' and 'fasten' as Verb number 20, you may decide that you are going to use 'tie' as the verb KEYWORD and will have 'fix' and 'fasten' as synoynm alternatives that can be typed.

You click on Verb 20 and then type in:

 /tie/fix/fasten/

 in the Edit field.

It is important that the Keyword comes first. Any synonyms can follow separated by a forward slash symbol /.

Click on [accept] button to accept your input entry.

You may find it helpful to keep a note of the keywords you have established as TAB only takes notice of keywords when it comes to process input commands.
By looking at the Vocabulary entries in a database you will be able to tell which are the keywords which TAB 'knows' and interprets. Basically, if you want your game to understand a particular word, then it must be present in the Vocabulary lists.

The purpose of the Deletions list is to instruct TAB to remove certain words from the player command(s) input string. You will find the Deletions on the Vocabulary Editor where you can see the words which will be deleted from a command phrase. These words are not part of the game vocabulary and thus must first be extracted from the input phrase before the command is decoded. You will note that some often used adjectives such as 'a', 'an', 'the' and 'some' are present. Thus, if the command 'get the large green statue' were to be understood the words 'the', 'large' and 'green' would need to appear in the Deletions list. It makes no difference to TAB which order the words appear in the list. As long as the word is in there somewhere then TAB will ignore it.

There is a limit of 500 verbs, 500 nouns, 200 Object Nouns, 100 Character Nouns, 200 prepositions and 500 deletions.

You can also [search] the Vocabulary for instances of words and [view] them in a TAB text viewer.

There are special embedding tag codes that can print a verb, object noun, character noun and preposition or their synonyms in textual output.
See the "language.txt" for more on that. 


GAME SETTINGS
=============

Initial game settings can be set up here:

Strength (0-500)
If strength were set to 10 and the player tried to carry objects which would make the total weight carried exceed 10 then the player would be informed with a suitable system message.

Carryable (0-200)
Informs TAB how many objects may be carried without the players hands becoming too full.
If the player tries to carry too many objects or too much weight the relevant system messages prohibiting him doing so will be displayed and another input requested. Note that the player could get round this problem by perhaps putting objects into a container which was carried or worn. You can, of course, change these values to suit your taste at any time during development of your game.

Start Room (1-500)
Tells TAB which room the game should start off in.

Window Title
Your game title, author, credit etc displayed on the Player window titlebar eg: "My Adventure by U. N. Known (c)2018"

Input Timeout (0-200)
Set this to a value in seconds eg: 30.
This means that if the player hasn't entered an input for 30 seconds then system message 'Time passes.' will be displayed, and the player will lose a 'turn' at the game.
0 = no timeout active.

Display Mode (1 or 2)
Must be set to 1 because this is the text-only version of TAB.

Colour Settings
These will take effect when an adventure is tested and run. From here you can set the defaults for:
Text Colour, Back Colour, Prompt Colour and Player Input Echo Colour

Set Password
Password protect your data to stop other TAB owners loading your game data in their copy of TAB. Always remember to record any password you use or you could get locked out of accessing your database in the Editor.
Remember this, if you have set a password the Editor will ask for it before allowing you access to the database.

Get Player Name
Invoke a dialog at the start of the game to get the player's name, surname and gender which can subsequently be referred to in game text.
with the %firstname%, %surname% or %fullname% embed 'tags' eg: "Hello %firstname% and welcome to the adventure!" 

Note: strength, carryable, timeout and color settings values can be changed in-game through special actions.



CODING - CONDITIONS AND ACTIONS
==============================

In the language.txt file there are lists of

parser conditions
object conditions
character conditions
flags conditions
sound and music conditions
miscellaneous conditions

In the "language.txt" file there are ACTIONS to deal with

flags
locations
objects
messages
characters
player name
score
turns
inventories
listing of objects/characters
exits
asking for player input
text formatting
sound and graphics
window FX
pausing game
ending game
changing the "it" noun
automatic routines
input timeout
saving/loading game position
transcript
quicksave/quickload  (similar to old ramsave/ramload)
undo (go back one move/turn in the game)
parser variable actions
character speech actions

There are also lists of %tags% that can be embedded in words conditions, conditions, actions and text messages.


HOW TO ADD SOUNDS TO YOUR GAME
================================

The Sfx directory" name on the "Game Settings Editor" should be set to the  directory name that holds all the sound files for the game enclosed in "/" slash characters -  so if you had a folder named:

sounds

it would be entered as below.

/sounds/

Acceptable sound file formats for the in-game sounds are: .mod, .aiff, .wav, .ogg, .mp1, .mp2, .mp3)

You can play a music or sample sfx by using the "playmusic" or "playsample" action commands.

For example:

playmusicmytheme.mp3

playsamplemysound.wav

See the sound actions in the "language.txt" file.


TUTORIAL AND CODING
===================

Since you have had a brief summary of the various adventure data editors maybe you wish to try a short example type-in game, which will be a useful exercise to gain proficiency in using TAB. Why not have a go at building it?

First Run the TAB Editor application (.exe file)

Click on the "Open Adventure" menu option.

Open the "default.tab" adventure datafile into the TAB Editor.

When it has loaded the name of the currently loaded database, in this case "default.tab", will be shown in the TAB Editor window titlebar. 

The "default.tab" database contains essential vocabulary words, system messages and pre-existing basic standard coding entries for your adventure.
It is a sort of 'skeleton', 'shell' or 'template' database which you use when first starting to write your game.
Once this has loaded into the Editor the other menu button options will become available to you and you can begin entering/deleting/amending data from within the various adventure Editors.

When you have finished your work session you can save your data using a unique filename
for example: 'myfirstgame'.

Next time you save an edited version of your data, simply overwrite the existing data with your new updated data using the same filename as before eg: 'myfirstgame'.

TAB will always remind you to save your adventure when you try to close/exit the program.

First of all enable the tooltips by clicking the [Tooltips Off] toggle button on the left hand side of the Main Menu so that it reads [Tooltips On].
They might be of assistance when entering data in the various Editors. If you can manage without them or prefer not to see the tooltips then set the button back to [Tooltips Off]. By default tooltips will be off when TAB initially loads.

The name of this game we shall call "The Sacred Quest of Dragoria" - so first of all select the "Game Settings Editor" button on the Main Menu.

If you are now in the Game Settings Editor, go to 'Window Title' and delete the entry text already present.

Now set the window title box text to instead read:

"The Sacred Quest of Dragoria" by <your name>.

Now to enter some more settings in the appropriate boxes:

Display mode should be set to 1 (indicating text-only)
**If using a Graphics version of TAB it should be set to 2 (indicating text + graphics)**

For this game set:
 
Player Strength to 7
Carryable to 3
Start Room as 1

Optional: Choose some new colour settings for your game.

Now click the 'Back' button to return to the Editor Main Menu.

Go to the Locations Editor

Delete the current Location 1 entry and insert the following text:

"You are at the edge of a large forest.  A narrow dirt track heads east into the trees." (without quote marks)

For the 'brief' description insert:

EDGE OF FOREST (can be upper or lower case)

For the exits: insert 2 in the 'East' editbox.

Ensure all other exit fields are reading 0.

Click the 'Back' button to return to the Editor Main Menu.

From the Main Menu enter the 'System Message Editor'.

In the bottom Introduction EditBox, delete the existing text and enter the following text:

"Another day is nearly over and you lie in bed anxious to get some sleep before your 6 am flight from Gatwick to Spain for your annual holiday.  To help you sleep you take a book off your bedside table and start reading a fictional work about the fabled Forest of Dragoria and a quest to discover ancient artefacts .... zzzzzz!"

Just to space out our text a little add a couple of blank lines by pressing the <enter/return> key 2 times at the end of the above text.

Click the 'Back' button to return to the Editor Main Menu.

Choose 'Save Adventure' from the Main Menu and save your game under the name 'dragoria'.

Select 'Test Adventure' on the Main Menu to start the TAB Player which automatically runs the current game loaded in the Editor.

Now you can view your window title, intro message and opening location with east exit.

Check your text for any errors.

To quit the Player by either typing in "quit" in the input textbox or closing the Window using the X button on the top right of the window titlebar.

Go to the relevant editors and amend any errors if necessary then from the Main Menu click 'Save Adventure' to save the changes you made under the same filename as before: 'dragoria'.

This completes the first step in building the example adventure....
 
Now it is time to enter some more locations for the "dragoria" game:

Reload your game "dragoria" using 'Open Adventure' if necessary

Select the 'Location Editor' button and type in the following locations

Click the arrow buttons at the bottom right of the Editor to move to higher/lower location numbers.

Location 2.
You are on a difficult and time consuming path, brushing through dense undergrowth and tangled creepers.
Brief description: FOREST PATH
Exits: east to 3 ; west to 1

Location 3.
You are at a small, dimly lit clearing. In the centre stands a small wooden hut. The ground here is quite soft.
Brief description: DIMLY LIT CLEARING
Exits: west to 2 ; in to 4 

Location 4
You are inside a dilapidated ancient hut. The place is uninhabited and a musty, obnoxious smell permeates the atmosphere.
Brief Description: RAMSHACKLE HUT
Exits: out to 3 

Check each entry carefully and then click on the 'Back' button to exit the Locations.

Select "Test Adventure" to start your game in the TAB Player. 

You should now see the first location, make sure the connections, east and west are showing. Enter 'e' or 'east' or 'go east' and you should end up in location 2, the forest path. Try out the exit directions to make sure the connections are working right through to Location 4 and back to Location 1.
When you are satisfied all is as it should be then QUIT the player by typing 'quit' or closing the Player dialog window to get back to the Editor.

This might be a convenient point to Save your Adventure again before continuing.
Remember the filename is "dragoria".

We will now enter some objects into our game. Objects can be static or dynamic. (You can also have 'hidden' objects - but more on that later)
Click the 'Objects' button to reveal the Object Editor and carefully enter all the objects in the game as follows:-

Object 1:
Description = an egg sandwich.
Message = The egg sandwich looks quite appetizing.
Noun = /sandwich/
Start Room = 5
Weight = 1
Size = 1

Now enter the following Objects:

Object 2.
Description = a small silver key.
Message = The silver key is very old. I wonder what it unlocks! 
Noun = /key/
Start Room = 0 (will not initially exist in game)
Weight = 1
Size = 1

Object 3.
Description = a spade.
Message = The spade is a useful digging implement.
Noun = /spade/
Start Room = 0
Weight = 4
Size = 4.

Object 4.
Description = a sharp knife.
Message = The knife is a handy weapon and is slightly bloodstained.
Noun = /knife/
Start Room = 6
Weight = 2
Size = 2

Object 5.
Description = a canvas rucksack.
Message = The rucksack is a canvas bag with two arm straps. It is quite roomy.
Noun = /rucksack/sack/bag/
Start Room = 502 (special location for player WORN objects)
Weight = 4
Size=3
Check the tickbox as Wearable
Check the tickbox as a Container.

Object 6. 
Description = a wooden chest.
Message = The chest is very large and has a small keyhole in front.
Noun = /chest/
Start Room = 4
Weight = 11
Size = 10
Check it as a Container

Notice we have constructed two container type objects, a rucksack (which can also be worn) and a wooden chest (which will prove too heavy to carry because it exceeds the player strength rating of 7 entered earlier...)

Now there is a special rule with container objects. The rule is that an object container must use the corresponding location number as its "inside". This means that you cannot use those locations for normal room descriptions in the game. Our containers, Objects 5 and 6 will therefore use Locations 5 and 6 respectively as their 'contents location'.
[Locations 5 and 6 are unused locations in this mini-game so that is OK] 

When you're happy with your entered objects click the 'Back' Button to exit to the Main window again. 

Get to the Editor Main Window again. 

Select the 'Vocabulary Editor' button.

In this Editor you will see the Lists of Verbs, Nouns, Object Nouns, Character Nouns, Prepositions and Deletions. You will notice that the Object Noun list contains the noun names of your objects, if it does not then you may have forgotten to enter them so you will have to go back to the Object Editor and re-enter any missing object details. 

When playing the game the player may use different words to describe the object he/she sees, like 'box' for 'chest', or 'sack' for 'rucksack'. So that is why we sometimes must enter some synonyms along with the keyword nouns...
So in the Object Noun Listbox DOUBLECLICK the mouse on

/chest/

 and it will appear in the Edit Vocabulary Field below. Now carefully amend the entry to read:
 
/chest/box/

 and click 'Accept' to update the list with your amended entry.

At this stage we may as well enter some 'Deletions' words. You have an 'egg sandwich' object but the object Noun is only called '/sandwich/'

To cover the possibility of the player referring to an object in this way we must inform TAB to disregard the adjective 'egg' and indeed any adjectives associated with any of the objects in the game.

So you can enter the word 'egg' into the deletions list, and that means that when you play the game, you can input things like 'give the egg sandwich to ????' and it will work ok, but if 'egg' was not in the deletions list it might say something like 'That's not possible!' or "Sorry, I don't understand 'egg' in that sentence".
Doubleclick blank entries in the Deletion listbox and add/accept the following individual words one at a time into the list: 

egg
wooden
canvas
small
silver
sharp

Go 'Back' to the Main Editor.

Now it is time to design a couple of NPC's. (non-player characters)
Click on 'Characters' button on the Main Menu to reveal the Character Editor

Ensure you are looking at Character number 1. (see arrow box number)

The first edit box is the 'Character Announcement Text' so enter in that box:

"Joseph the farmer is here." (without quotes)

In the larger Character 'examine' textbox enter:

"Joseph the farmer is a local yokel, and is a very strong, hefty looking man." (without quotes)

In the Character Noun box enter:

/farmer/joseph/

The Start Location for Character 1 should be set to 3

In the 'Name' editbox enter:

"Joseph the farmer" (without the quotes)

This textbox is specially for any alternative name text that will be used by the Character movement messages. For instance when a character enters or leaves a room or when it follows the player. By default the 'name' text can be set to 'The <noun>' where <noun> is the current noun KEYWORD for the Character. By changing this to "Joseph the farmer" it will ensure that TAB prints system messages like "Joseph the farmer goes east." instead of "The farmer goes east." 

Click the 'Male' Character Gender radiobutton to establish the sex/gender of the Character.

We will make a walk pattern that farmer will follow; so click the 'Walk' radiobutton and type it in the walk pattern editbox VERY carefully. It should look as follows:

walk=4,3,p,2,1,2,p,3

(Note very carefully the positions of the commas)

The 'p' in the above entry will cause the character to pause/wait a turn at its current location.

This walk pattern means at the start of the game the farmer will be in location 3. He will move in to location 4, will go out to location 3, pause a move, move west to location 2, west again to location 1, and then move east to location 2, pause a move, and finally move east to location 3 which was his starting room in the first place!
On the next turn the character will set off on the entire pattern again and will continue his travels ad infinitum.
Notice how a pattern was devised so that the character arrived back at location 3. (Character Start Room) When designing a walk pattern you must take into account the logical and valid directions which exist between locations... The responsibility rests with the author to implement a sensible pattern because TAB does not check to see if you are typing the right location numbers.

Now click the bottom right  arrow button to move to and edit Character number 2.

Enter the following data for Character 2:

Announcement text = A cat sits close by.
Message = The cat is a scraggy moggy, but looks quite friendly.
Noun = /cat/
Start Room = 2
Name Text = "The cat" (without quote marks)
Click the 'random' radiobutton. (The cat will move randomly) 
Click the 'it' radiobutton. (The cat is a creature and not a male or female human)

Exit Characters and go back to the Main Menu.

'Test Adventure' again...

Check that the farmer and cat show up and move around. Examine them. Try entering 'follow farmer' or 'follow cat' when they're around. To stop following them type in 'stop following'. Type 'inventory', 'inv' or 'i' to check you are wearing the rucksack. You should be able to remove, drop, get and wear it and also look in it... See if you can take the sandwich out of the rucksack and put the sandwich into the rucksack ok. Check that the wooden chest is visible in the old hut in the clearing.
The knife should be in the chest. Later we will cover locking/unlocking the chest and constructing a few puzzles and problems for the player.

If all is satisfactory, exit the TAB Player and save your updated "dragoria" adventure.

CODING EDITORS
==============
 
Now we come to the Editors that are at the heart of the TAB program and execute the main game control...

The SCRIPT 1 Editor is a special list of entries which consist of conditions and actions which are scanned by TAB after every location has been described in the game but BEFORE exits and/or objects visible have been printed.
TAB does all the entries in this table, providing they exist starting at earliest valid entry and continues to the end of the list.
Script 1 is useful for adding a message to a location text or for printing extra info to a location. It can also be used for other things too.

The RESPONSE Editor
This is a list of entries constructed to take care of input commands from the player. When the player types a command from within the game, the parser examines the phrase typed and extracts variables:

 v, n1/objn1/charn1, p and n2/objn2/charn2

i.e. the verb, first noun (be it an ordinary noun, object noun or character noun) any preposition and any second noun. (be it an ordinary noun, object noun or character noun)
The parser also removes any deletion words and devises a special string which is the KEYWORD string sentence equivalent to the input typed.
This information is then passed to the RESPONSE entries to find a match. So, TAB looks at each entry in turn until it finds one that corresponds. If it does then it looks at the conditions in that entry and if they are satisfied it carries out the actions in the entry in the order it meets them and then exits RESPONSE to look at the SCRIPT 2 entries.

The SCRIPT 2 Editor.
This list of entries, again containing conditions and actions, is called by the TAB immediately AFTER Response but BEFORE getting the next phrase of input from the player or before a new input is requested. It is also called after each input 'timeout' has expired.
As with Script 1, ALL the entries are done in sequence and the Conditions and Actions are looked at in turn to see if anything needs to be executed.
Script 2 provides for the computer's turn at the game and to inform the player of any events which may have happened such as a car crashing, a secret panel opening or a bomb exploding etc.
When TAB has scanned all the entries it makes a return to the parser for the next command or prompts the player for the next input.

You need to know a bit about what the entries in these Editors do; but in short they consist of 2 parts, part 1 is where you put the Conditions, and part 2 where you put in the Actions you want to take place.

For example you want to talk to someone, you have to show whether the Character is in the room, etc. those are the Conditions.

Following this are whatever action(s) you require to take place, for example a message to be shown stating what the Character says to you or does.

You will see what I mean when you type in some entries into Responses Editor shortly.

You will use these 3 Editors to insert all the entries which the game will be able to interpret, and to devise the problems and puzzles which the player will encounter on his journey through the realm of your fantasy world.

From the Main Menu go to the 'Response Editor'.

Examine the default entries present in the list. You will see that there are entries already provided in this list to take care of basic player commands such as 'getting', 'dropping', 'wearing', 'removing' objects and for commands such as 'inventory' 'wait', 'look' and the like. Spend a few moments examining this list. In fact all these Response entries already present are going to be necessary for the smooth running and execution of games, so it's best to keep these as they stand, and just add new entries as and when needed.

As you realize they are quite short sections of code. They will not be time consuming to insert and are quite easy to create and type in.
However, it should be borne in mind that you should construct these entries properly in the correct format, and using the rules which will be given, in order for your entries to function properly.
If you ignore the coding rules then doubtless your entry will not perform correctly and you may get an error report when you come to playtest your game. The error reports may indicate the entry list that is causing the error. If you find this happening then you must quit the game and go back to the Response Editor to put things right.

The format of each coding entry in the list must contain 3 special "tags" enclosed in square brackets like this:

[start]......[acts].......[end]

After a [start] tag you must enter the CONDITIONS that are needed to make the entry work.

The first CONDITION in a RESPONSE entry is always a "WORDS CONDITION"

If there are any other conditions required then use the # hash symbol to separate them.

When the entry conditions have been typed in you then type the [acts] tag.

After this you type in any ACTION commands required.

If there is more than one action then use the # hash symbol to separate them.

When the entry ACTIONS are finished you close the entry with an [end] tag.

[start]words_conditions#condition2#condition3[acts]action1#action2[end]

Roughly translated this means:

IF the words conditions match
AND
condition 1 is true
AND
condition 2 is true
THEN
do action 1
THEN
do action 2
THEN
Exit the Response list.

Type the following entries into the Response Editbox. If you scroll down the response list you should come to a marked section that tells you where to construct your coding entries.

Note that the [tags] and the WORDS CONDITIONS, CONDITIONS and ACTIONS must all be typed in lower case.

HINT: Copy and paste the entries below -  It's much easier. :)
Use the keyboard shortcut [SHIFT]+Insert or [CTRL]+V to paste them into the correct place.

==================================================
[start]unlock chest/unlock chest with key#here6#here2#closed6[acts]openobj6#cmessThe chest is now unlocked.[end]

[start]unlock chest/unlock chest with key#here6#opened6[acts]cmessThe chest is already unlocked.[end]

[start]unlock chest/unlock chest with key#here6#absent2[acts]cmessYou don't have a key![end]

[start]lock chest/lock chest with key#here6#opened6#here2[acts]closeobj6#cmessYou lock the chest with the silver key.[end]

[start]lock chest/lock chest with key#here6#closed6[acts]cmessThe chest is already locked![end]

[start]open chest#here6#opened6[acts]cmessOK.[end]

[start]open chest#here6#closed6[acts]cmessYou can't. it's locked.[end]

[start]close chest#here6#opened6[acts]cmessOK.[end]

[start]close chest#here6#closed6[acts]cmessYou can't. It's already closed.[end]

[start]eat sandwich#here1[acts]destroy1#cmessYum Yum... You greedily consume the egg sandwich.[end]

[start]eat sandwich#absent1[acts]cmessYou don't seem to own a sandwich!#done[end]

[start]dig/dig ground/dig with spade/dig ground with spade#here3#room=3#objloc2=0[acts]create2#cmessYou dig and uncover a small object...[end]

[start]dig/dig ground/dig with spade/dig ground with spade#here3[acts]cmessYou dig around for a bit but uncover nothing of interest.[end]

[start]dig/dig ground/dig with spade/dig ground with spade#absent3[acts]cmessYou have no digging tool.[end]

[start]give sandwich to farmer#here1#charpresent1#flag1=0[acts]destroy1#create3#flag1=1#cmessThe farmer gratefully accepts your gift. He drops a spade he was carrying and eats the sandwich hungrily.[end]

[start]give %objn1% to farmer#charpresent1#objlocn1=here[acts]cmessThe farmer politely refuses your gift.[end]

[start]give %objn1% to cat#charpresent2#objlocn1=here[acts]cmessThe cat ignores you and eyes you suspiciously...[end]

[start]talk to farmer#charpresent1#flag1=0[acts]cmessThe farmer greets you cheerily and comments on the fine weather. "I seem to have mislaid my lunch box and I am so hungry" he exclaims.[end]

[start]talk to farmer#charpresent1#flag1=1[acts]cmessThe farmer chats a while and wishes you good luck on your quest.[end] 

[start]talk to cat#charpresent2[acts]cmessThe cat stares at you in amazement![end]

===========================================

By the way, If you don't like to type coding entries into the Response Editor manually you can elect to construct your coding entries with a text editor that has full editing facilities such as eg: Notepad, then you can simply copy and paste them into the the TAB Response Editor - or save them as a file and load the file into the Response Editor through the file dialog that appears when you press the button: "Load Responses". Very Handy. (Same thing for the Script 1 and Script 2 coding Editors)

The [Find Text] button is handy for searching and highlighting word(s) and phrases in the list so that you can more easily locate and edit particular code entries. Repeated button presses with the same text typed in the Editbox is useful for finding all occurrences of your search criteria.

Exit the Response Editor.

Click the Script 2 button to open that Editor

Type or copy and paste these entries to somewhere near the top of the Script 2 Editbox
Use the keyboard shortcut [SHIFT]+Insert or [CTRL]+V to paste them in.

================================
'sets the chest to be initially locked 
[start]flag2=0[acts]closeobj6#flag2=1[end]

[start]flag3=0#carried4[acts]objloc4=1#score+20#flag3=1#cmessAs you touch the knife it vibrates in your hand. An unearthly voice shatters the silence. "If thou wouldst claim the Sacred Knife of Dragoria and use its mystic powers then thou must first possess it three times."
A blinding flash of light causes the knife to disintegrate in a shower of sparks![end]

[start]flag3=1#carried4[acts]objloc4=6#score+20#flag3=2#cmessAs you hold the knife the strange voice returns - "Once more bold seeker thy aim to own this legendary prize is thwarted. Ha ha ha.."
The knife jumps out of your hand and spins in the air with increasing rapidity and vanishes in a cloud of smoke! Phew!![end]

[start]flag3=2#carried4[acts]objloc4=5#score+20#flag3=3#cmessThe knife seems to have a life of it's own!! Invisible hands seem to repeatedly raise and slash... raise and slash in a frenzied attack upon you. You struggle to protect yourself against the rain of blows!
Suddenly the knife has disappeared again and you realise the attack was just an illusion.[end]

[start]flag3=3#carried4[acts]score+40#cmessHaving discovered the knife once more, a fanfare sounds in the distance. A Psychic message from the Guardian of the Knife unfolds in your mind - "Congratulations, thou art chosen as worthy to own this famed treasure and control it's mystic powers."

The piercing tones of your 6am alarm call bring you to waking reality.
The adventure is over. You have solved the game.#score#pause6#gameover[end]
==================================

Go 'Back' to the Main Editor.

FINAL ENTRIES

Go to the Vocabulary Editor.

Add the following individual words entries to the VERB listbox:

/unlock/
/lock/
/open/
/close/shut/
/dig/
/eat/

Add the following word entry in the ordinary NOUN listbox:
/ground/floor/soil/

Go 'Back' to the Editor Main Menu.

Save your adventure - "dragoria" again...

This should have completed the short game, and you can 'Test Adventure' from beginning to end.

To win and solve this little example adventure, the player must find and possess the knife 3 times.

The "tutorial.tab" database in the ADVENTURES TO PLAY directory is the same as the above tutorial.

Remember There is a 'language.txt' file which documents the conditions and actions language. These exist to make the task of adventure authoring a little simpler and once you understand them you'll be incorporating your own designer entries into your game with consummate ease.

If you don't wish to build this example now, or are just curious as to the final result, you can check out the finished database:
"tutorial.tab" in the ADVENTURES TO PLAY folder.

NOTE: Whenever you test a database from the Editor using "Test Adventure" a special file called "recover.tab" is created in the TAB main directory.
This is always a copy of the last database run by the TAB Player. So if you accidentally forget to save after testing when exiting the TAB Editor you can still access your work by loading "recover.tab" and then saving it in the normal way - but remember that "recover.tab" is overwritten after each "Test Adventure".

Diagnostics:
To invoke a diagnostics dialog window, type in and enter "dx" at the input prompt (Editor version of TAB only)
Some basic DIAGNOSTICS to help when playtesting in the TAB Editor.
Simple changes that can be made to move objects, alter flag values, change rooms, change weights of objects, alter turns, change carryable limit and move characters to different locations to help check and test things more quickly.

I hope you have enjoyed creating or playing the small example game, but I think some explanations are needed regarding some of the Response and Script 2 coding entries which were devised to create the puzzles.

Let us analyze SOME of the conditions and actions used in the coding entries to discover their purpose and effect...

CONDITIONS "openedX" and "closedX" will be true if container object X is open or closed respectively.

CONDITION "hereX" is true if Object X is carried or worn by the player or in the player's current location. ("absentX" is its opposite condition)

CONDITION "room=X" will be true if the current room = X.

CONDITION "objlocX=Y" is true if the current location of object X is room Y.

CONDITION "objlocn1=here" checks that whatever OBJECT noun was typed as the first noun in the phrase is present in the current room or carried or worn by the player.

CONDITION "charpresentX" is true if Character number X is present in the player's current room.

ACTION "closeobjX" ensures that the object container contents cannot be accessed; neither will its contents be listed if the player tries to "look in the <container>". In other words it is "locked".

ACTION "openobjX" simply clears the container object status to unlocked/open. The contents of the container are now viewable by "look in <container>" or in an inventory listing if the container is carried.

ACTION "cmessX$" (custom message) simply prints text to the adventure window eg: cmessI am a custom message.

ACTIONS "createX" and "destroyX" create an object in the current room or destroy/remove an object to location 0. (does not exist in the game)

ACTION "done" stops processing of any further commands that may be waiting to be dealt with. It is normally the last action in a Response entry.

ACTION "score" prints player's current score and turns taken..

ACTION "score+X" increases players score by X.

ACTION "pauseX" halts the game by X seconds.

ACTION  "gameover" ends the game and asks the player if they wish to play again or quit using a standard dialogbox.

Flags
====
Also used in the tutorial game were flag conditions and actions..
There are 500 user flags that can be used by authors.

Flags have many uses but their main use is to tell TAB whether a thing has been done or not. eg: "flag15=1" could be used to indicate that a gate was open. "flag15=0" could indicate that the gate was closed. You may find it handy to keep a personal record of the flags you use.

Flags are very useful when devising the puzzles and problems which must be solved in a game and their values can be altered to show that a particular obstacle has been successfully overcome. The simplest flag condition is "flagX=Y" which checks that flag X holds a value of Y, and the simplest flag action is "flagX=Y" which sets flag X to contain a value of Y. There are other flag conditions and actions which are useful as well.
TAB also allows you to refer to a flag value in a cmess action. eg:

cmessThe number %flag16% was inscribed on the wall.

TAB would convert the contents of flag 16 and alter the message to maybe:
"The number 26 was inscribed on the wall." depending on the number held in flag 16.

Normally TAB will print the location text, exits and list objects in response to the command 'look' or when movement is accomplished via a direction noun such as 'north' or 'go se' etc.

However, sometimes you may wish to force TAB to do the location describe because of an action which moves the player to a different room and you may want to inform the player just where he is and what he can see in the new room by printing the relevant info.

For example, suppose the player found a 'magic lamp' and you had a RESPONSE entry to deal with the player 'rubbing the lamp'!
When the player rubs the lamp he may be engulfed in a swirling mist of light which clears to show the player has been transported to a new room!
To ensure that the new room is described as normal - add a call to the 'desc' action. For instance:

[start]rub lamp#objloc1=501#flag20=0[acts]mess301#room=25#flag20=1#desc[end]

If the lamp is carried and flag 20 is equal to 0 then print Message 301, change the ROOM to 25, set flag 20 to 1 to show this puzzle has been done, and describe the room, exits & contents.

The same effect could be achieved using the 'goto' action eg:

[start]rub lamp#objloc1=501#flag20=0[acts]mess301#flag20=1#goto25[end]

Action 'gotoX', where X is a location number, puts the player in the stated room and AUTOMATICALLY describes it.

TAB allows you to create entries for items referred to in location or message texts that are not classed as true objects (do not exist in Object Editor) eg:

Location Text:
"You are in a dark, dank basement. The sound of dripping water punctuates the ominous silence. A cupboard stands in the northwest corner of the room. It is icy cold in here."

The importance of the cupboard is not emphasized here, unlike a cupboard OBJECT which would be listed under the 'Also Visible:' system message.
It would be up to the player to determine or work out if the cupboard had any significance in the plot by examining it and so on...
To allow interaction with these 'hidden objects' just create an ORDINARY noun keyword in the Vocabulary Noun List together with any relevant synonyms and then create some Response entries eg:

[start]examine cupboard#room=4#flag9=0[acts]cmessYou search the cupboard and find a spanner.#objloc3=room#flag9=1[end]

[start]examine cupboard#room=4#flag9=1[acts]cmessYou search the cupboard again but find nothing.[end]

You might also create entries for dealing with 'room' and 'basement'
eg:

[start]examine room/examine basement#room=4[acts]cmessThat`s just background scenery. Nothing special.[end]

Use of hidden objects can make a game more difficult to solve and the player is required to pay attention to everything in the text so as not to miss finding, discovering items or clues..

You may have already noticed that you can embed codes to cause the printed text to be formatted in bold, italic, underline or strikeout or left, center or right aligned. You can also have messages output in a different font and fontsize. You can also control  the color of the text and highlight bits of text and emphasise it by making it stand out...

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 might or could 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#......

You have to ensure the words you use are KEYWORDS and of course 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. 

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: Script2 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]

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'  

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 spare 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]

A couple of 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. 

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]
  
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=northwestto18#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 keywords within the 'connect' action.   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=northwestto0#flag30=0[end]

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

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 with a tick.
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.'
Object 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=501#flag25=1[end]

rem: note found if tree searched in room 13 and placed in player carried location (501) 

[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:

[start]examine 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 inspection 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]

TAB has flag actions which can be used 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!#score#pause5#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.

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]flag30=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]

gameover - end game with dialog box options to Quit or Restart

endgame - end game with options: "Would you like to (Q)uit, (R)estart, (L)oad a saved game or (U)ndo?"
and then waits for a user keypress of Q, R, L or U...
NOTE1: If using action "endgame" in a coding entry then "undo" MUST be enabled/active in order for keypress option: "(U) Undo"  to work correctly.
(Undo is automatically enabled at the start of a game)
Always allow "undo" and do not allow players to change the status of undo if using an "endgame" action. 

In the dwarf example coding 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.

TAB allows you to create Long Nouns and Long Verbs in Vocabulary word entries.

What is a long noun?

It is a type of noun (ordinary, object or character noun) that can have extra word(s) that are joined to it using a separator symbol making the TAB parser think that it is a single word...
For this separator symbol I`ve chosen: "¯"
which can be obtained by holding down the left ALT key and typing 2,3,8 on the numeric keypad then releasing the ALT key to get the ¯ symbol.

Example LONG NOUN KEYWORDS:

/large¯wooden¯crate/

/tiny¯ornate¯earring/

/cracked¯decorated¯china¯pot/

As you can see long nouns are not limited to 2 words but can have more!
In practice though they will mostly consist of 2 or possibly 3 words
depending on the textual description for the normal, object or character noun.

Normally any adjectives or words describing objects had to be placed into the Deletions list to enable these words to be understood from the input command(s) by the parser... Now this is no longer mandatory. Very, very handy because the author may want to use some of these words for other objects in the game.

Long noun object keywords will be printed by TAB in the default system messages or for the n1 and n2 variables in "cmess" actions
eg:

"You now have the tiny ornate earring."
"You drop the gold key."
"You put the tiny ornate earring into the cracked decorated china pot."
etc.. etc..

and the long noun keywords will also be printed in an inventory listing or a container contents listing too.

A long noun keyword (probably consisting of 2 or 3 words) is still a KEYWORD and must be entered properly in the RESPONSE words conditions as usual in the correct place eg:

[start]press small¯red¯button#room=1#flag3=0[acts]....etc.etc....[end]

SYNONYMS can be Long Nouns as well. I will call these LONG SYNONYMS. eg:

/tiny¯ornate¯earring/ornate¯tiny¯earring/tiny¯earring/ornate¯ earring/earring/

/book/tattered¯black¯book/tattered¯book/black¯book/

/slender¯spruce¯ tree/slender¯ spruce/slender¯ tree/spruce¯ tree/spruce/tree/

The second example (book) shows you can have long synonyms even for one word KEYWORDS.

There are a couple of important rules regarding long nouns and long synonyms:

1) Long synonyms for Long Nouns must not contain MORE words than that
contained in the long noun keyword.

Example Noun and synonyms:

/small¯pocket¯radio/small¯radio/pocket¯radio/radio/ = CORRECT FORMAT

/small¯radio/ small¯pocket¯radio/pocket¯radio/radio/ = INCORRECT FORMAT

/blue¯teacup/blue¯cup/cup/ = CORRECT FORMAT

/decorated¯pot/cracked¯decorated¯pot/pot/ = INCORRECT FORMAT

2) In addition to Rule 1 - Long synonyms must be entered in order by
placing the synonyms that contain the MOST words first down to the synonyms that contain the LEAST last. (descending order)

Example:
OBJECT NOUN KEYWORD: /small¯pocket¯radio/
SYNONYMS: /pocket¯radio/ small¯radio/radio/

would be entered as:

/small¯pocket¯radio/pocket¯radio/small¯radio/radio/

If you are using a single word KEYWORD and require long synonym
alternatives then Rule 2 only applies eg:

NOUN: /book/
SYNS: /tattered¯black¯ book/tattered¯ book/black¯ book/

entered as:

/book/tattered¯black¯book/tattered¯book/black¯book/

Because of all of this inputs by the player can be substantially longer but
can still be made to be understood by TAB...

Examples:

>examine the small pocket radio then put the tiny ornate earring into the
cracked decorated china pot

>put the ornate earring into the large wooden crate then turn on the small radio

ALL the default TAB Response entries will work automatically with these
long noun combinations too - so no extra complicated coding required....

CHARACTER Nouns can be long nouns and have long syns:

/rasputin¯clever¯mad¯monk/rasputin¯ monk/mad¯monk/monk/rasputin/

Since "the" is a deletion word the following input might work:

>give the small tricorn hat to rasputin [the] clever mad monk

Incidentally, you can also have LONG VERBS and have LONG SYNONYMS with them also!

/get/pick¯up/

/remove/take¯off/

/wear/put¯on/

/i/get¯i/inventory/inv/

/carefully¯examine/carefully¯exam/carefully¯x/


ADVANCED TAB CODING
====================
All CONDITIONS can be preceded by the lower case prefix "or_" to cause TAB to go into "OR" checking mode in a coding entry

For example:

Script 2 Entry:

[start]or_room=1#or_room=52#flag1=0[acts]cmessYou are in either room 1 or room 52 and flag 1 holds a value of zero!![end]

Roughly translated this reads:
IF the player is in room 1 OR the player is in room 2 AND flag 1 is equal to 0 THEN print the custom message: "You are in either room 1 or room 52 and flag 1 holds a value of zero!!" THEN go to look at the next Script 2 entry if there is one below it.
If the entry conditions are not true then the entry is skipped and the next entry is looked at.

Special RESPONSE EDITOR WORDS CONDITION:

%_%  - will cause TAB to do the entry providing ANY VALID words are typed

Example Response Entry:
[start]%_%#room=5[acts]cmessI am printed when the player types ANY valid phrase of input providing the player is in room 5 and no other response entries have triggered before me![end]

A very powerful and useful addition to coding CONDITIONS is the ability to cause TAB to briefly jump out of conditions and do a specified action before returning to continue checking any further conditions in a coding entry...

To invoke this requires a special prefix "call_" + the name of any valid action.
"call_" gives the ability to execute any of the action commands during condition processing before the [acts] tag in a coding entry.

A simple example:

[start]room=3#flag4=2#call_cmessI am a message to output.#turns<16[acts]mess12[end]

A custom message will be printed if the room is 3 and flag 4 is equal to 2
whereas Message 12 will only additionally be printed if the turnscount is less than 16.

===

Similarly - A very powerful and useful addition to coding ACTIONS is the ability to cause TAB to briefly jump out of ACTIONS and check whether a specified CONDITION is true before returning to continue executing any further ACTIONS in a coding entry...

To invoke this requires the special prefix "call_" + the name of any valid condition.
"call_" gives the ability to execute any of the conditions during action processing after the [acts] tag in a coding entry.

A simple and similar example:

[start]room=3#flag4=2[acts]cmessI am a message to output.#call_turns<16#mess12[end]

A custom message will be printed if the room is 3 and flag 4 is equal to 2
whereas Message 12 will only additionally be printed if the turnscount is less than 16.

The "call_" tags can be used in Response, Script 1 and Script 2

===

The "ELSE" action.

#else# - An extension to TAB coding. Allows MULTIPLE conditions and actions in a single code entry.

Example Response Entry Format:
[start]words conditions#condition#condition[acts]action#action#else#condition#condition[acts]action#action#else#condition#condition[acts]action#action#else#[acts]action[end]

You can still use the or-checking syntax ( "or_" prefix on conditions) with #else# too.

Example Response Entry Format: 
[start]words condition#or_ condition#or_condition[acts]action#else#or_condition#or_condition[acts]action#else#[acts]action[end]

Example Response Entry:
[start]tie rope to tree#or_room=5#or_room=56[acts]mess39#else#room=17[acts]mess40#else#[acts]mess41[end]

===

The "jump" action command.

The "jump" action can jump over blocks of code in Response, Script 1 or Script 2 (or Character Speech) coding entries to a named LABEL further down the table.

There must be a colon (:) at the end of the label name. 
The label name does not need to be capitalised and can be numeric or alphanumeric. 

Example Response Entry:

[start]push %n1%/push %objn1%/push %charn1%[acts]jumpPUSH-CODE[end]

'if player types  verb "push" + any valid noun jump over subsequent code until reach the label PUSH-CODE

........
........
........ lines of code
........
........
........

PUSH-CODE:
Continue processing conditions and actions from here after the "jump" to label PUSH-CODE
All entries regarding 'pushing' things go below...
[start]push button#room=1#flag20=2[acts]flag20=3#cmessYou push the button...etc[end]

"jumpLABEL" is very handy for jumping over or bypassing blocks of coding entries to access other entries more quickly.
Will be mainly used in Response Editor.

Special Action:

#updatecommand# 

This ACTION updates or CHANGES the player's typed input command to be the KEYWORD string sentence equivalent of the parser variables set by the parser variable actions in the current coding entry prior to the "updatecommand" entry...

PARSER variable ACTION COMMANDS are:

objn2=objn1
objn1=objn2
charn2=charn1
charn1=charn2
n2=n1
n1=n2
n1=X
n2=X
p=X
objn1=X
objn2=X
charn1=X
charn2=X

x = valid number

Usage: just before a "jump" action is executed.
eg: .....#updatecommand#jumpPUSH-CODE[end]

An example of "updatecommand" action in use is in "char_commands_demo.tab" Response entries (giving object to character)

There are actions for changing the current "it" noun to a different noun class: either an ordinary, object or character noun:

itnoun=n1
itnoun=n2
itnoun=objn1
itnoun=objn2
itnoun=charn1
itnoun=charn2


CHARACTER SPEECH COMMANDS
============================
The "Char. Command Editor" is accessed by a button on the Character Editor and contains entries similar to the coding entries in RESPONSE except these speech responses are for commands understood by the Characters. (1-100)

All you have to remember is that if there is a command (coding entry) that must be recognized and acted on by a CHARACTER then it must be listed in the "Char Commands" coding list as opposed to the normal PLAYER responses in the Response Editor. 

Not all games will use the optional character commands facility - so in those cases there will just be a couple of "default" entries, which you may already discovered in the "default.tab" datafile.

Character speech commands are simply commands that follow an input command by the player that begins:

> say to <character>,
> say <character>,

or simply

> <character>,

That is how they are differentiated and interpreted as a non player character (NPC) command rather than a normal player character command.

Included with TAB is a database called “char_commands_demo.tab” which demonstrates giving commands and orders to Characters.

The default entries allow gameplayers to command ALL characters to get, drop, wear and remove items, follow you, stop following, go in a direction, get objects out of containers, put objects into containers, get all, drop all, wear all, remove all, get all out of a container, drop all into a container, talk to another character...

Also you can:

>say to <character>, hello
>say to <character>, inventory (or ‘i’),
>say to <character>, wait

The adventure player can also give objects to characters and also ask a character to give you object(s) which they possess.

You can even command them to give an object to another character!

EXAMPLES:

>say to farmer, hello
>say farmer, get the knife
>jim, go north
>say to bill, put the knife into the box
>farmer, inventory
>say to farmer, get all
>say to farmer, drop the lamp
>say to farmer, talk to <character>
>say robot, follow (or; follow me)
>say robot, stop following (or; stop following me)
>jim, give knife to bill
>say to bill the policeman, give everything to me
>say to joseph, go se
>say to robot, take everything out of the box
>say to joseph the farmer, take everything except the knife out of the box
>jim, drop all but the lamp
>say to farmer, give the lamp to me

If the character is not in your location/room when you give a command to one then of course you will be told so; likewise you will be informed if the character is unable to carry out your command for any reason.

You can even tell a character to perform multiple commands! eg:

>say to <character>, go north and get the box then south and give the box to me

>say <character>, get all but the knife then go north and give everything to jim then go south and follow me

The characters understand it/them/him/her so you can type:

>say to smith, get lamp and give it to jones

The characters understand the ‘again’ or ‘g’ command:

>giant, pull lever,g,g

Finally the player can give items to characters:

>give rope to smith

>give all to randles then say to smith, give all to randles

Each command carried out by a character will cost 1 turn of the game. If for any reason the character does not understand a command or cannot execute a command, you will be informed so and the character will cease to act on any possible further command instructions given in that input.

Below I list the DEFAULT TEXT LISTING which can be copied to replace any text in the Char Commands Editor of a default database so as to allow this functionality -

===============================
DEFAULT CHARACTER COMMANDS
===============================
This list is executed by TAB after a "say to <character>, <command>" player input. By default commands can be carried out by ALL characters.

The first entry checks if any commands were given to a character
'===============================
[start][acts]cmessYou did not type in any commands for %speechname%.[end]
'===============================
Entries below this can adjust "speech" variable
Then do the speech entries
'===============================

dospeech:

First check that speech character is in current room
'================================
[start]%_%#speechcount=1#charabsent%speech%[acts]cmessSorry, %speechname% is not here!#done#else#speechcount=1#charpresent%speech%[acts]sysmess86#jumpdospeech2[end]
'================================

dospeech2:

[start]hello#charpresent%speech%[acts]cmess%speechname% says: "Hello".[end]

[start]examine %objn1%#or_objlocn1=%speechworn%#or_objlocn1=%speechcarr%#or_objlocn1=charloc%speech%[acts]%speechname% examines the %objn1%.[end]

[start]go %directn1%#invalidcharmove[acts]cmess%speechname% wasn't able to go %directn1%.[end]

[start]go %directn1%[acts]pattchar%speech%=static#movecharacter[end]

[start]i#charpresent%speech%[acts]charinv%speech%[end]

[start]get %objn1%#objlocn1=charloc%speech%#objn1notstatic[acts]cmess%speechname% picks up the %objn1%.#objlocn1=%speechcarr%[end]

[start]drop %objn1%#objlocn1=%speechcarr%[acts]cmess%speechname% drops the %objn1%.#objlocn1=charloc%speech%[end]

[start]wear %objn1%#objlocn1=%speechcarr%#objn1wearable[acts]cmess%speechname% wears the %objn1%.#objlocn1=%speechworn%[end]

[start]remove %objn1%#objlocn1=%speechworn%[acts]cmess%speechname% removes the %objn1%.#objlocn1=%speechcarr%[end]

[start]talk to %charn2%#charpresentn2#charn2=%speech%[acts]cmess%speechname%: "Are you asking me to talk to myself!?"[end]

[start]talk to %charn2%#charpresentn2[acts]cmess%speechname%: "Hello %charname2%."
%charname2%: "Hello yourself %speechname%."[end]

[start]give %objn1% to %charn2%#or_objlocn1=%speechcarr%#or_objlocn1=%speechworn%#charpresentn2#charlocn2=%speechloc%[acts]cmess%speechname% gives the %objn1% to %charname2%.#objlocn1=carrcharn2[end]

[start]give %objn1% to me#charpresent%speech%#or_objlocn1=%speechcarr%#or_objlocn1=%speechworn%[acts]cmess%speechname% gives the %objn1% to you.#objlocn1=501[end]

[start]give all to %charn2%#charpresentn2#anyobjs%speechcarr%#charlocn2=%speechloc%[acts]all%speechcarr%#cmess%speechname% gives the %objn1% to %charname2%.#objlocn1=carrcharn2[end]

[start]give me %objn2%#charpresent%speech%#or_objlocn2=%speechcarr%#or_objlocn2=%speechworn%[acts]cmess%speechname% gives the %objn2% to you.#objlocn2=501[end]

[start]drop all#anyobjs%speechcarr%[acts]all%speechcarr%#cmess%speechname% drops the %objn1%.#objlocn1=charloc%speech%[end]

[start]get all#anyobjscharloc%speech%[acts]all%speechloc%#cmess%speechname% picks up the %objn1%.#objlocn1=%speechcarr%[end]

[start]wear all#anywearable%speechcarr%[acts]speechwearall[end]

[start]remove all#anyobjs%speechworn%[acts]all%speechworn%#cmess%speechname% removes the %objn1%.#objlocn1=%speechcarr%[end]

[start]give all to me#charpresent%speech%#anyobjs%speechcarr%[acts]all%speechcarr%#cmess%speechname% gives the %objn1% to you.#objlocn1=501[end]

[start]give me all#charpresent%speech%#anyobjs%speechcarr%[acts]all%speechcarr%#cmess%speechname% gives the %objn1% to you.#objlocn1=501[end]

[start]follow/follow me#charpresent%speech%[acts]cmess%speechname% agrees to follow you...#pattchar%speech%=follow[end]

[start]quit following/quit following me#charpresent%speech%[acts]cmess%speechname%: "I will no longer follow you then."#pattchar%speech%=random[end]

[start]wait[acts]cmess%speechname%: "I will wait here then."#pattchar%speech%=static[end]

[start]get %objn1% out %objn2%#objn1<>objn2#objlocn1=contobjn2#or_objlocn2=charloc%speech%#or_objlocn2=%speechcarr%#or_objlocn2=%speechworn%#objlocn2=container#openobjn2[acts]cmess%speechname% takes the %objn1% out of the %objn2%.#objlocn1=%speechcarr%[end]

[start]drop %objn1% in %objn2%#objn1<>objn2#objlocn1<>contobjn2#or_objlocn2=charloc%speech%#or_objlocn2=%speechcarr%#or_objlocn2=%speechworn%#objlocn2=container#openobjn2#objlocn1=%speechcarr%#objn1fitsintoobjn2[acts]cmess%speechname% puts the %objn1% into the %objn2%.#putobjn1intoobjn2[end]

[start]drop all in %objn2%#or_objlocn2=charloc%speech%#or_objlocn2=%speechcarr%#or_objlocn2=%speechworn%#openobjn2#anyobjs%speechcarr%[acts]all%speechcarr%#cmess%speechname% puts the %objn1% into the %objn2%.#putobjn1intoobjn2[end]

[start]get all out %objn2%#or_objlocn2=charloc%speech%#or_objlocn2=%speechcarr%#or_objlocn2=%speechworn%#objlocn2=container#openobjn2#anyobjscontn2[acts]allcontn2#cmess%speechname% gets the %objn1% from the %objn2%.#objlocn1=%speechcarr%[end]

' entries dealing with words not understood

[start]?[acts]cmessSorry. %speechname% did not understand "%?%" as a verb.#done[end]

[start]%v% ?[acts]cmessSorry. %speechname% did not understand "%?%" as a noun in that sentence.#done[end]

[start]%v% %n1% ?/%v% %objn1% ?/%v% %charn1%  ?[acts]cmessSorry. %speechname% did not understand "%?%" in that sentence.#done[end]

[start]%v% %n1% %p% ?/%v% %objn1% %p% ?/%v% %charn1% %p% ?[acts]cmess%speechname% didn't understand "%?%" as a noun in that sentence.#done[end]

[start]%v% %p% ?[acts]cmess%speechname says: "%?% - it's not in my vocabulary as a noun."#done[end]

'====last entries======
[start]%_%[acts]cmess%speechname% didn't seem to be able to carry out your last command...#done[end]

[start]%anywords%[acts][end]

===============================
END OF DEFAULT CHAR COMMANDS
===============================

Also the following coding entries may need to be added into the normal RESPONSE Editor entries to allow giving items to Characters...

======
GIVE CODE
======
[start]give %charn1% %objn2%#charpresentn1[acts]objn1=objn2#objn2=0#charn2=charn1#charn1=0#p=3#updatecommand#jumpgivecode[end]

givecode:

[start]give %objn1% to %charn2%#charpresentn2#objlocn1=501[acts]cmessYou give the %objn1% to %charname2%.#objlocn1=carrcharn2[end]

[start]give all to %charn2%#anyobjs501#charpresentn2[acts]all501#cmessYou give the %objn1% to %charname2%.#objlocn1=carrcharn2[end]
================
END OF GIVE CODE
================


Multi-part games:

There is a special TAB action called "link" which can be used to automatically load and run another TAB datafile from the source directory.
This is useful if a game is quite large and has been split into 2 or 3 discrete parts or databases eg:

[start]flag54=1[acts]cmessCongratulations you've solved Part 1!#pause5#cleartext#cmessLoading Part 2...#keypress#linkpart2.tab[end]

MAKING A STANDALONE GAME
=========================
When your text adventure game is complete make a new empty folder for your game and rename that folder eg:

MyGame

Into this folder place a copy of the TAB_PLAYER.EXE application

Also place in this folder a copy of your finished game database eg: 
mygame.tab

Rename the copy of the TAB_PLAYER.EXE file to something more suitable 
eg: MyGame.exe

Rename your finished game database from "mygame" to "autorun"

That's it.

Congratulations. You now have a folder with a standalone version of your game that will run when MyGame.exe is started.

If you're using gfx, sfx, or icons you may need to add separate folders within your MyGame folder.

You can also include a "readme.txt" file and intro splash graphic too.

It is also possible to embed a finished final version of a game database ("autorun.tab") into a game executable. This will prevent anyone loading it into a text editor or wordprocessor and makes your data more secure against cheating.
Contact me for details if interested.



DISCLAIMER:
===========
The TAB software is provided 'AS IS' without warranty of any kind, either expressed or implied. By using it you agree to accept the entire risk as to the quality and performance of the program.
This software is not guaranteed to perform properly on all systems or under all circumstances. The author assumes no responsiblity for errors or damages that may occur from the use of this software.