***A Beginners Tutorial to Using the Quest Development Kit***

Note: This tutorial has been copied from the original PowerPoint Tutorial. While all effort has been made to filter out the need for screenshots, some references to non-existant pictures may still be included.

- CREATING A NEW FILE
Before you can begin working on your game you will need to create a new file. There are two ways to do this: You can either just create a new game from scratch or you can use the QDK Wizard. Later on the wizard will become only an annoyance, but for now it will help you start. First run QDK.exe, the Quest Development Kit. Next select ‘New Game’ from the File menu or click on the new game icon (the one that looks like a piece of paper with one corner folded slightly). Unless you’ve changed your default options the QDK Wizard should appear (You can turn it on or off in the options box under the Tools menu).

Here there are three fields. You can click in them and type anything in them you want. The first is the game’s name (which will be displayed while playing the game), your name (which can be displayed while playing the game) and where you will save the game file. Don’t fret too much if you can’t think of a name now, or if you aren’t sure whether to abbreviate your name or not, since you can change these again after creation.

If you have any extra libraries in your Quest folder you will now have an opportunity to include them in your game. Libraries can add more common features and options to Quest without having to be coded in. The most popular and common library is TypeLib, which has popular features such as scenery, readable objects, containers and more. For the most part libraries have advanced options you won’t need yet, and you can always add them to your game yourself!

If you want to include a library you can click on the square next to it to select it. A list of libraries you have will be displayed, along with a brief summary by the author. You don’t have to have any libraries, and if you change your mind you can add them in later too. For now it’s probably best not to choose any and just click Next.

Now you have to opportunity to add some rooms to your game. Don’t take this too literarily though, Quest’s ‘rooms’ can be anything from a metre wide passage to a kilometre long stretch of road! It’s just a location where your character will be. Type the name of the room in the box and click add. Do this for all the rooms you want, but don’t stress if you can’t think of them all now, as you can create new rooms at any time. Once you’ve added some rooms you can tick one box next to a room: that will be the room the player starts the game in.

The wizard will now end, allowing you back to the normal screen, which should now show your game’s name at the top of the screen and your rooms along the left of the screen.


- GAME PROPERTIES
Since you’ve just begun a new game, now might be a good time to edit the game properties. Some of these are just general settings that don’t effect the game too much, others are vital to the game! For now we’ll just look at the simple ones. Go to the Game menu and click on Properties.

In the first tab ‘Game information’ you can edit the information on the game that is displayed when the player types ABOUT. The name of the game, name of the author and starting room are all displayed here. You can also enter the game version, copyright information, and if you have upgraded to Quest Pro enter extra information about your game.
The tabs Script and Global Settings will be dealt with later, but you can choose the Display tab to change the default font and colour for your game. Some people have different opinions, but I personally think it is best to leave the default font as it is. You can change it if you want though.


- ROOM PROPERTIES
Now the game itself is set up the first thing to do is set your room’s properties. To do this highlight the room you want to edit, then click the large ‘Edit Room’ button on the bottom of the screen.

To the left is the most simple tab of the properties. The name and alias sometimes causes confusion, so here’s what it is. The name of the room is the internal name for the room, while the alias is what is seen by the player of the game. These can be the same, and if left blank the alias defaults to the object name. The reason is that sometimes a game will have several objects that are displayed the same (eg. three ‘street’ rooms) but must have different names. The same applies to objects.
The prefix is displayed before the alias when using the LOOK command to avoid grammar errors. A message of “You are in house.” looks bad, but setting the prefix to ‘a’ will provide the message “You are in a house.” The description type can be changed, but it’s probably best to leave it as it is unless you know what you are doing. The large blank area is for typing the room description to be displayed when looking or entering a room. The description prefix changes the text before the description from the default “You are in " to whatever you type. You’ll need to type a ‘:’ where the description will go. For example, if the Name was 'Dark cavern', the alias was 'cavern', the prefix was 'a dark scary', and the descript was 'you are lost in'. Quest was display: 'You are lost in a dark scary cave.'

The next tab of the room properties is very important. It contains drop down menus for each of the directions of the compass, as well as up, down and out. For each direction you can set [not accessible], which means the player can’t go in that direction, a room name, which will move the player to that room if they go in that direction, or run a script, which we’ll deal with later. If you select a room a checkbox will appear to create a corresponding exit in the other direction. If ticked this will automatically create a way back from the other room. For example if you can go east from Dark cavern to Long passageway then it will create an exit west from long passageway to dark cavern too.

The third tab allows you to create a ‘go to’ exit. This will appear with the room objects on the side of the game (as well as in the room text) and works like a normal exit but with a different command (GO TO somewhere). You can create one by clicking the Add button then selecting or typing in the target room (and adding a prefix if needed eg. “You can go to THE house” instead of just “You can go to house”). A script can be added here too, but this will be dealt with later. The other tabs will be dealt with later.


- OBJECTS AND OBJECT PROPERTIES
Now that you’ve learnt how to add and customise rooms, isn’t it about time to add some objects? Objects are basis of your game. Everything from characters to items to scenery are all objects. To add a new object you must first select the room you want to object to start in, then click other Add button, the one near the middle of the screen under the items area (the right-hand side where the items are displayed). You’ll need to enter a name, then the properties box will appear (You can display it again like the room one, by clicking on the Edit Object button).

The amount of fields and options may seem intimidating but don’t worry, most of them are actually optional. The name, alias and prefix are the same as the room’s, and the suffix is the same as the prefix but is shown after the object alias when seen. Gender and article are to allow for proper grammar in the game and will default to ‘it’ when left blank. The detail box is for multiple items with the same alias: during the game a selection will pop up asking which one you meant, and will display the detail. The display type is shown on the object screen while playing next to the object alias, but has no effect aside from that. The other three boxes are messages for when you LOOK at, EXAMINE, or TALK to the object (or can run a script if you want). By clicking on Other Names you can choose other names that the player can use to refer to the item so they don’t have to type in the full name every time.

The other two tabs are used for more detail in objects. The Take tab can change the properties about whether you can take the object or not, what happens when you take it, and additional scripts relating to the gaining or losing of the item. For now just check the first or second circle if you want to item to be able to be carried by the player, or unable to be moved.

The interactions tab is the most important of the three since it contains information about how the object can be used and interacted with. These will be dealt with later on. For now just check either of the boxes if you want your item to be invisible (not displayed in the when looking, but still there) or unavailable (not accessible at all and is effectively not there until it is made available again). You may want to make scenery object such as trees both hidden and not takeable so you can only look at them.


- USING OBJECTS
Now that we know how to create and edit objects, how about using them? There are two ways to do this: the first is using an object by itself, the other is to use and object on another object. For now we’ll try using an object by itself by lighting and snuffing out a torch. This may sound simple, but we’ll need to learn to use both variables and simple scripting to do it!

To start with we need to go into our torch objects properties again. One there, click on the Interactions tab. Finally, click on the top button ‘Edit “Use” Details…’. This will open up use menus.

Left areas are where you can add objects that can be used on the torch, and objects the torch can be used on (there is a difference). At the bottom you can add a script for using the torch on anything, using anything on the torch, and using the torch on it’s own. Click on Use torch (on its own) then click the Edit button under the blank script area. The script editor should appear. You’ll be using this a lot, so I’ll cover the basics now.
By the way, you can also set what happens when using an object by itself through Game Properties, by clicking on the Edit Useable Objects in the Global Settings tab.


- THE SCRIPT EDITOR
This is the basic script editor screen. It looks empty now, but all the script you add will be shown here. You can click Add command to add a script command, or Add conditional to add an IF script. The IF is very important in determining what happens when something depends on something else. For using the torch we’ll first need to see if the torch is already lit or not, so click on Add Conditional.

Conditional script checks to see if something is true (or not true) and then runs a script if it’s true. The top field is where conditions are added. In this case we need to check to see if the torch is lit or not. The middle field is where the script goes that occurs if the conditions are true. The bottom field is optional script that will run if the conditions are not met. To add a condition click the Add button.

The condition editor is where you select a condition. You can choose from ten different conditions, each with various checks. To the left you can choose to tick NOT, meaning the conditional script afterwards will run if this condition is not true. For multiple conditions using AND means they must all be true, while using OR means only one of the conditions needs to be true. For now we need to check if the flag ‘torch lit’ is set or not. A flag is basically like a real flag. It can be up (on) or down (off). In script you can set a flag on at times, and off as well. So far there has been no flag set, but this flag will be set later. What the whole thing is basically doing is saying “If the torch is lit then…” Next we click OK. The conditional script screen should now show this condition ("the flag "torch lit" is set") in the top section.

Now that we have a condition we can add some script. Clicking on the middle Edit button will bring up another blank script editor. Now click on Add command to add some script.

This is the Script Command Editor, possibly the most used function of QDK. To left you can choose the command you want to perform, and to the right customise that command. You can choose from Print (change screen display), Game Control (runs various scripts, functions and menus), Objects (change objects various properties), Rooms (move the player and edit room exits), Inventory (give or take an object from a player), Variables (set variables and flags), Finish the game (ends the game one way or another), Pictures & Sounds (show pictures and play sounds), Help window (display text in a pop-up box), Timers (edit timers) and Other (miscellaneous commands that don’t fit into the other categories). You’ll want to explore all these some times, but for now we’ll just choose ‘Print a message’ from the print category. This will print the text to the right on the game screen.

Now we’ll add a second command: ‘Set a flag off’ from the Variables category. This will set the previously mention flag off, so the script wont run a second time when using the object unless the flag is set back on! To the right is the script editor after: You’ll notice you can now see the two commands. You can click remove to remove one, edit to change one, or move up and move down to change the order the commands are run (this is very important sometimes!) Now click OK to be back to the conditional script.

In the conditional script check the box next to Else to allow the else script. This script will fire when the if condition is not true. Click on edit to add some script for that. To the left is what the box looks like after adding some script to the Else as well. The script is very similar, except this time we turn the ‘torch lit’ flag on and print a different message. By clicking OK a few times, your first section of script is finished! What this script will do is when you use the torch it will light it, and if it already lit it will snuff the torch out. This may seem like an over-complex system, but you’ll get used to it in time.


- USING OBJECTS (CONT.)
Now we’ll return to the other way of using objects: on each other. We already have a scroll object from earlier, why not add a script for using the torch on the scroll? The obvious thing would be for the scroll to burn, so we’ll do that. First in the ‘Use Details…’ section click on the Add button next to the ‘Objects that (item) can be used on’ area. Select the object you want to be able to use the item on (the scroll in this case) and it will be added to the list.

By clicking the left edit button you will go to the script editor again. You’ll need to add another IF condition, checking for the ‘torch lit’ flag again. As mention earlier, an inaccessible object is basically gone, destroyed or whatever so that it can’t be seen or interacted with during game play. To make an object accessible or inaccessible you can use a command in the Script Command Editor under the objects category. Some good code would be: "If the flag "torch lit" is set Then (print "The flame burns the scroll to ashes."; Make "Old scroll" inaccessable) Else Print ("You need to light the torch before you can burn anything!"". This code will burn and destroy the scroll, but only if the player has already lit the torch.


- THE TEXT BLOCK EDITOR
Now you’ve learnt how to create and use objects it is possible to write a full game! However such a game will be simple, and not much fun to play. From now on this tutorial will guide you and give you hints of performing many common tasks that increase a games fun. The first of these is customising various text that appears in the game. This will make your game more interesting to play and less repetitious for people who play many different Quest games. To do this select the first choice from the Text menu at the top of the screen, Text Blocks.

The Text Block Editor allows you to customise message for the intro (which is displayed at the start of your game), win (which is displayed when the player wins the game) and lose (which is displayed when the player looses the game). To edit one simply choose it from the drop down menu and type the message in the space provided. You can use the top buttons to add new message blocks (the default message blocks can not be deleted or renamed). These are for large amounts of text displayed multiple times (or even just once) during the game, and can be shown through the script command ‘Display a text block’ under the Print category.


- CHANGING STANDARD MESSAGES
Next, try choosing the second option from the Text menu, Standard Messages. This allows you to change the default messages for taking objects, dropping objects etc. as well as the error messages.

Up the top are the things that will produce a default message. To change the default select a Message for and you will see the default message in the middle box. In the bottom you can type whatever you want the default to be. By clicking the Copy button the default message will be copied into the Message to display box. If you leave the box blank then the default will be used.

- SYNONYMS
Finally choose the third option from the text menu, Synonyms. This function allows the player to add multiple synonyms for the default commands (or your own commands, but these will be discussed later). What this means is that the player does not have to type the default command (say, TAKE) but they could type in similar words (eg. GAIN, OBTAIN, PICK UP) and have it perform the same effect.

The synonym menu will be blank to start with, so click the add button to add a new one. Type the command into the button …to: box. Now click on the Add synonym button. A box will pop-up for you to type the new word (or phrase) that will do the same thing when typed in by the user. These will show up in the top box. Click OK to finish.


- TEXT FORMATTING
Another way to make the text look more interesting is to format it. By default the text displayed is dull and boring, but by using text formatting you can make it look more interesting. You can do this in any place where text would be displayed. A full list of these can be found in the QDK manual, but some of the more commonly used ones are: |b to turn bold on, and |xb to turn it off. |u to turn underline on, and |xu to turn it off. |i to turn italic on, and |xi to turn it off. |cb, |cr, |cl, |cy and |cg to change the colour of the text to black, red, blue, yellow or green. |s?? To set font size (insert 00 for default). There are others too, but less used.

What follows is a transcript from an example game with different customised messages. It sounds much for fun to play doesn't it?
(italics)There is (bold)blackness(bold off)...
There is darkness...
There is (red)pain...(black)
You open your eyes and look around. Your head aches and you can't remember how you got here. The last thing you remember was being chased down the street by a thug... After a few moments your visions returns fully and you find yourself in some kind of cave.

You are lost in a dark scary cavern.
There is an ancient scroll written in english and a torch here.
You can go east or west.
The cavern you are in is very small and dark. Around you water drops eerily down the damp walls and what little light there is bounces of strange crystals imbedded in the walls.

> Take torch
You put it in your backpack.

> Pur torcj on ground
Er... what?

> Pur torch on ground
You place it carefully on the ground

/End transcript


- CUSTOM COMMANDS
Aside from interesting text, another thing that can make your game a lot better are custom commands. No matter how good the messages are, it does getting boring having to USE everything. Do you go up to someone and ask them to go use a book? To use a sandwich? No, so why should your players have to? By adding custom commands you can both increase the vocabulary of the game and ease of use for players, and allow multiple ways to use objects. To start with lets try adding a READ command so that we can read the ancient scroll mentioned earlier.

First you’ll need to go into game properties again (that’s Properties under the Game menu). Select the last tab, Global Settings. Here are some of the more complex settings for you game including custom commands. Click on the Edit Custom Player Commands button. You’ll see another empty box with buttons on the side. Click on the Add button to add a new custom command.

First you type the command in the top box. If you want to have several commands do the same thing then you can type a ‘;’ symbol and a space, followed by another command to do the same thing. Ignore the two buttons bellow, I’ll explain them later. By clicking on Edit you can enter the script that will run when the player enters this command. The script shown will first check that the player has the scroll, then display some text which contains a vital clue to solving a future puzzle. This is all fine, but what if you want this text to be displayed at other times, say when someone has ordered you to read it, or if used as one of a series of choices (more on that later) at some other point in your game? Typing in the text again is both inefficient and unnecessarily increases you game size without adding to it at all. This seems like a good time to learn about procedures.


- PROCEDURES AND FUNCTIONS
Procedures are simply sections of script that can be used at different times during your game. They have the advantage of keeping file size down, being quicker to do once than creating the same script several times, and can be edited quicker than searching through custom commands, object uses or other places where the script might be. A procedure can be run through any script by using the Run a Procedure command under Game Control category. To create a procedure click on Procedures under the Script menu. A list of procedure will be displayed, but it’s probably still empty for now. Click on Add and you will be prompted for a name for the script. This name is never shown in game, it’s just to refer the that script when you call it from a command. After that the familiar script editor will appear. All you have to do now is create your script as normal then click OK. Easy!

While where on the topic of procedures, now would be a good time to mention functions. Functions are very similar to procedures in terms of creating and running them, but they perform a slightly different task. Rather than printing text or changing objects they are used for calculating numbers or variables. In an RPG game for example you might have a ‘Damage calculation’ function that would decide the damage done to a foe using some variables, or in a Spy/mystery game you might have a ‘Evidence’ function that would calculate if you had enough evidence to charge a criminal, and return a variable as ‘Yes’ or ‘No’. There are also some built in functions in quest, which you can use at any time. You can check the manual for these, or some will be mentioned later on in the tutorial. There are many uses for both procedures and functions!


- CUSTOM COMMANDS (CONT.)
Now that we can create a procedure (or function if needed) it is easy to call it from a custom command. But creating a custom command for each thing you could read may seem ridiculously tedious… well you’d be right. The easiest way is to use variables in your custom commands. It’s time to look at the two buttons we skipped earlier. By clicking on them it will ask for a string variable name, and then insert it in the command. It’s probably quicker just to learn the different and type it in yourself.

let's take the example of a custom command 'read #@object#'. Who in their right mind would type that? Well, no-one. The hashes (#) around it means whatever the player types after read will be stored in a string variable. String variables contain strings of letters. There are also numeric variables which contain numbers, but we can’t use them here. You’ll find more about these soon. Now back to the #@object#. When using string variables in commands you can either place an @ symbol after the first hash or not. If you don’t use the @ then whatever the player types in stored in the variable. If you do use the @ however then the player must type in the name of an object or the command will fail. In addition the real name of the object will be stored in the variable instead of what the player actually typed in (the alias).

Now lets take a look at the script itself, (if "#object" is equal to "Old scroll" Then run the "read #@object" procedure Else print "You can't read that.") What the script is doing here is first checking if the object can be read by comparing if it is equal to a readable object name. More could be added each time you want a new object by adding a new condition and giving it an OR. It is important to remember when comparing a variable to something to put in the # or % symbols. The next part is a bit more confusing. The script is going to run the ‘Read #@object#’ procedure. First because there is an @ symbol now it is going to refer to the object’s alias rather than name… using the @ symbol will reverse the name/alias of what is stored if it is an object. Then it will run the procedure ‘read (something)’ where the (something) is whatever the object variable is now. So if the player where to read the scroll, it will run the read scroll procedure! This is confusing, so here’s a break down:

First the player types in ‘read scroll’. Since the player has the scroll object, the command is accepted. The object variable is set to the name of the scroll object, ‘Old scroll’. Next it checks to see that object variable contains the name of a readable object, the old scroll. It does, so then it refers to the variable’s object alias (scroll) and runs the ‘read scroll’ procedure. By using these you can create more complex scripts. This may seem difficult and hard to set up, but it does make adding more readable objects easier. There is another simpler way to do this, but it involved object properties and actions, which will be dealt with later.


- NUMERIC VARIABLES
Previously we mentioned string variables, and explain one reasonably difficult use for them. So now would be a good time to start learning about the different types of variables Quest supports. First we’ll look at numeric variables.

Numeric variables are used frequently in any good game. They store a numeric only, no words such as ‘one’ or ‘twenty-two’. Each numeric variable has a unique name that is used to refer to that variable (you can however have a string and a numeric variable with the same name). When you want to refer to a variable in a text block, a comparison or most other places where text is used you have to type the variable name with a percentage sign (%) on each side, with no spaces. Take care with script commands though, in some commands you don’t need the % signs (but it will say this on the screen). You can create a new numeric variable through a script command (set a numeric variable, under the variable category). If you try and use an undefined variable you will get an error usually, but if you try and increment or add to an undefined variable it will just default to whatever is being added. One useful note is that if a string variable contains only numeric data you can set it to a numeric variable directly.

Numeric variables are useful for things that need to be counted. If you wanted the player to have to try and open a door three times before it opened all you would need to do would be increment a numeric variable by one each time, and open the door once it was equal to three. You could use numeric variables for anything from the number of times a rock has fallen on the players head to the price of an item at a shop to a friendship rating with a goblin!


- STRING VARIABLES
As mention before, string variables are variables that can contain characters as well as numbers. They are similar to numeric variables otherwise, except they need hashes (#) around them, and if they refer to an object a @ symbol can be used to switch the name or alias (useful when you want to object name stored, but want the alias to be displayed in a block of text. Due to their nature there are several useful tricks that can be done with string variables as well.

The first trick has already been mentioned: use a string variable as part of a reference to something else (eg. running the procedure ‘read #@object#  or giving the object #object# to player). Another interesting use is to store a numeric variable name in a string variable, so you could compare a number to %#variable name#%! Also a string variable can be set by the player using a Other-category command ‘Enter next command into a string variable’.

Did you know that Quest creates it’s own string variables automatically? While playing Quest will store some things in string variables such as what room you are in (#quest.currentroom#), what the last command typed in was (#quest.command#) or the last object name (not alias) referred to by the user (#quest.lastobject#)? You can use these in various script commands for additional flexibility (you may want some things to only work in a certain room for example).

Some common uses of string variables include the character name, temporary variables in custom commands, the player having to type in a password etc.


- STATUS VARIABLES
Status variables are a special category of variables. They act like either numeric or string variables in comparing them, changing them etc. but have a useful property of always being shown on the game screen. Status variables need to be set up outside of a script command, by selecting Status Variables from the game menu. 

The first box ‘Name’ is where you type the name of the variable. Below you can select it to either be a numeric or a status variable. The shaded out line below that is only for multi-player Quest game, so don’t worry about it. The initial value is what the variable starts at. The display is what will be shown in the status area during game play. You can add an exclamation mark (!) where the value will be displayed, though you don’t have to (for example it may only displayed POISONED when you are poisoned, since the player doesn’t know how poisoned he/she is). If you tick the box below then nothing will be displayed when the variable is equal to 0 (this is useful for things like the aforementioned poison, or gold as shown to the right). You can also add a script to be run straight away (ie. before any other script commands are executed) when the variable changes. A simple example is (If %gold% is equal to "0" Then Print "Uh-oh, you're broke again."), in which the game will helpfully point out when you have run out of money.

Status variables are commonly used in some RPG-style games for health, magic, gold, status effects (like poison or burn) etc. They can also be used in puzzle-style games for a turn count or player score.


- OBJECT PROPERTIES
Remember the problem of an overly difficult reading custom command? Well now it’s about time we dealt with it. To refresh your memory: Checking to see whether the item was readable and then executing its individual procedure was long and confusing. In order to do this more efficiently we need to learn about object (or room) properties. First go to the scroll object (or any readable object for that matter) and click on the interactions tab. Now click on the Edit Properties and Actions button.

Each object can have a separate set of properties. Each property can act either like a flag or a string variable for that specific object. This property can be changed, compared and checked for in script commands and conditionals. To add a new property click on add, or just click on an old one to edit it. The name is simply the name of the property used to refer to in scripts. The value can either be left blank, in what case the property will have no value and just be like a flag, or a default value can be added, which means it will have like both a flag in that it can be checked for, and a string variable that can be compared. If you check not then the property is not set. It may seem useless but you’ll see why when we learn about types. (Also, to set a property off you need to set the property ‘not (something)’ on, which actually sets the something off). To refer to the property value you use the format #object:property#. If you need to use a string variable for the object or property (or both) then they will need to be surrounded by brackets (eg. #(object):price# ).

So how does this help our problem? Well now instead of a long list of IF object is something OR object is something OR… etc. we can now just check to see if the object has the property readable or not!


- OBJECT ACTIONS
Not only can objects have flags and variables attached to them, but they can also have various scripts attached to them. If you have a lot of procedures then this can save time trying to look for the read scroll one, since it will obviously be on the old scroll object. It also makes running a procedure based on a variable. But first to add an action.

To add an action to an object (or room) go to properties and actions, then choose the Actions tab. Clicking on the Add button will add a new action (again you can edit an old one by clicking on it). Type the name then click Edit. The familiar script editor will appear for you to add your script.

To run an object’s action you can use the ‘Run an object’s (or room’s) action script’ command in the objects category.

Now that you know how to add object properties and actions, it is easy much quicker and easier to create custom commands. Now the 'Read #@object#' script can be much simpler, just (If object has the property "readable" Then Run "objects"'s "read" action script Else print "You can't read that.") Notice how short and simple it is, but it allows for adding in new objects at any time easily. Actions can be used for other things too of course.


- OBJECT TYPES
Since you’ve learnt about properties and actions, it would be a good time to learn about object types. Object types are like object properties in the way they are added to an object (or, again, room) via the properties and actions display. However a type itself does nothing special (though it can be checked for, added and removed like a property). What a type does is automatically add a collection of predefined properties and actions to an object without having to add them all manually. 

To set up a new type of type, choose Object Types from the game menu. Once you add a new one you will be presented with what looks like a copy of the properties and actions display, however titled Edit Object Type. Here you can add properties, actions and even types that will be included in that type. Now if you go to the object you want and go to the types tab of the properties and actions display to add it. When you start playing the game, that object will now have all of the properties, actions and types associated with that type.

Using object types will save you some time, and also reduce file size (which is never a bad thing). An example of a place where object types would be useful is for edible items. The ‘food’ type may have the properties edible and destroyable (it could be checked for to make sure that important items aren’t destroyed), and an eat action that increases the player’s hunger a small amount and destroys the object. You could also add a poison food type that would automatically add the food type, but have a poison action that would reduce the player’s health when eaten!

- MENUS
You should congratulate yourself now, since you finally learnt everything needed to make a good game! However there are still some miscellaneous functions of QDK that have not been mentioned yet. This is because these don’t really fit with anything else, and because some people don’t think a text game should have non-text features. However some games do definitely benefit a lot from them, so we’ll take a look at them now. The first is the menu. A menu, when run from a script command, will pop up over the main screen in a new window with a prompt, and several selections to choose from. To create a menu, select Menus under the Script menu. Click add and you will the Menu Editor.

At the top of the editor you can type in the prompt that will appear on the menu when it appears. After that click Add to add a choice. Once you’ve typed in the text that will appear on the button in the menu the script editor will appear. Here you can add whatever script will be run when the button is pushed. If you don’t add any script the menu will still work and the button will just close the menu and do nothing. The other buttons should be fairly self-explanatory.

Menus becoming very tedious if used to often, but using them in situations where there are multiple things to do which would not be obvious is a good thing. A couple of good examples could be whether you wanted to pull, push, turn, or prod a loose rock you find, or another example would be choosing a topic of conversation when talking. They are also useful when the user must choose one thing from a serious of choices... Such as class-selection in an RPG, or who to accuse of murder in a mystery game.


- TIMERS
Timers are not used too often, since almost all text adventures are turn-based (ie. Nothing happens until the player types a command). However some excellent cross-genre games have had real-time elements in them. A timer will allow those elements to be implemented. To create a timer select Timers from the Game menu. Add and name your time like many other places, and you will be presented with the Edit Timer menu.

At the top type the name of your timer. The interval is how long it will take until the timer ‘fires’ and runs the script below. If the box is checked then the timer will start counting from the start of the game, otherwise you will have to turn it on via a script command.

Timers are useful for simple things like setting time-limits on solving puzzles. You may want to have a timer that lasts for twenty minutes or so, then kills the player from an earthquake if he's still inside the cave. Timer can also be used for things like day and night based on real time (where 1 minute would be an hour in the game for example, and short timers can make the player have to type quickly when faced with armed robbers! Having just one or two timers may just annoy players, but having a whole game with real-time events can provide an interesting and fun challenge!


- PICTURES AND SOUND
Another thing you can do to make your game more fun to play is to add pictures and sound. Beware that some people find pictures and sound annoying, but they add a lot to a game if used well. To display a picture in a pop-up window (pictures can’t be displayed in the main window for technical reasons) you can use several of the script commands in the Pictures & Sounds category, depending on what picture type it is (quest can display pictures with extensions of .gif, .jpg, .bmp, .ico, .rle, .wmf and .emf). The size of picture displayed, as well as a caption (if any) can also be specified. Pictures are good to add for thing that plain text can’t really show (or can’t tell without being too obvious about a hint), such as a map or a crossword puzzle. After all, a picture is worth a thousand words, and a thousands word takes a lot longer to type!

Sound and music can also be played under the same category. The supported files are .mid, .midi, .wav, .mod, .s3m, .it and .xm. You can specify the volume, whether the sound will loop or not, if quest will pause until the noise has played and stop the sound. Sounds can add more atmosphere to some scenes: the eerie dripping of the tap or the clash of two blades does wonders. Music can also add atmosphere if played in the background. It’s probably best not to really on the player have heard the sound though, since some people who don’t like sound may not have their speakers turned on.


- FREQUENTLY ASKED QUESTIONS
This final section of the tutorial can be skipped if you want, nothing new is covered here. This is simply a place for the most common tasks and questions. The question will be surrounded by *s so you can easily pick them apart and read only the ones you don’t know.

***How can I let the player look at himself to get information about what his appearance?***
There are two ways to do this. The most obvious way to create a custom command ‘Look at self’ or similar. Next add a script command to print a message. This message should contain string and numeric variables describing what your character is wearing, his stats etc. Adding a conditional to see if a flag is set, then printing more text would be useful. When your done the custom command script should be something like: Print “You are a charming young #race#, and are in #health# health. You are wearing #armour#, #gloves#, #shield# and wielding #weapon#. You seem to be carrying %gold% gold pieces.” If %poison% is greater than 0 Print “You are poisoned.” Where the #race#, #health# etc. had all been defined earlier. The second way is to create an object called ‘myself’ and make it invisible and un-droppable, then add a script to give it to the player at the start of the game. Then you could use objects on yourself and examine yourself as well.

***How can I make an event random?***
To make an event random you will first need to use the random function to get a random number. Set a numeric variable to $rand(x;y)$, where x is the lowest number and y is the highest number. Then just compare it in a conditional like you would for anything else.

***How do you add a turn counter?***
To add a turn counter you will need to use either a numeric variable, or a status variable if you want it to be always displayed. Either way go the Game Properties and then the script tab. Enter a script command under ‘After each turn’ that increments the variable by 1.

***How can I add a player’s health and money?***
For these you will need status variables. For money, set the initial value to 0 (unless you want the player to start with some money) and make sure it isn’t displayed when zero. To add a limit to how much money you can carry, add a short script that checks to see if money is over a certain amount, and if it is sets it back to that around, effectively limiting the player’s wallet size. To add the player’s health you’ll need to start it off as 100 (or whatever the maximum health is) and have it to still display when zero. Next add a script that checks to see if the player’s health is less than 0, and if it is prints a fitting message (you collapse from lack of health, or similar) and makes the player lose. Add another script to make sure the health doesn’t go over the maximum (be it fixed or a variable), and if it is then set it back to the maximum.


- CONTACT
This tutorial is finished, but is still being constantly improved on. If you have any comments, feedback, suggestions or questions please feel free to contact the author with the address below. For any questions regarding the Quest and QDK software itself please visit Quest’s website.

E-mail the author of this tutorial at: chrisames@westnet.com.au
Visit the Quest website at: http://www.axeuk.com/quest/index.htm


NB. Quest and QDK are copyright to Axe Software and were designed and developed by Alex Warren.