Introduction

Before discussing how to use Task Commands, it would be pertinent to understand what Task Commands are. That understanding first begins with a discussion of Interactive Fiction.

Interactive Fiction (IF) is so titled because the participant determines what events transpire in a fictional story through some method of direct interaction. The method depends on the type of IF. In IF novels, the reader is guided through the fictional story by various stopping points in the novel which allow the reader to continue by selecting from several choices which lead to different pages in the novel. There are also IF games ranging from board games to computer games.

The type of IF computer games available are numerous, but can basically be divided into two important categories, depending on the type of interface: text-interfaces and graphic-interfaces. In text-interface games, the player interacts with the game by entering textual commands. In graphic-interface games, all interaction occurs through use of the mouse. Graphic-interfaces usually have a very limited number of commands which are chosen by cycling through various menu items or buttons, then selecting the graphical object to invoke that command upon. Text-based games, on the other hand, use numerous commands in various combinations, and are limited only by the creator and plot of the adventure.

Adrift is a text-based system. This does not mean Adrift does not support graphics. In fact, graphics can be used with almost any aspect of Adrift, as well as sound. But the interface in which the player interacts with Adrift is text-based, meaning that the player must type in a word or phrase to move through the fictional story. Why is it important to know this? Because text-based systems require the infamous parser. In order for the adventure to understand the many sentences and phrases which the player types, it has to have a way of interpreting what the player wants to do on a computer's level. The parser is that part of text-based interfaces that translates the player's text into something the adventure can understand and follow.

The Adrift Parser

The parser in Adrift is basically the engine in Adrift Runner, and it accomplishes many things. Once a player enters a command into the interface (by typing a word or phrase), the parser's job begins by parsing out those words which the adventure understands. The remaining words are discarded. Next, the parser will try and interpret what the player wants to do by looking at the order of the words, then comparing each word to a reference. This reference lists all the words and commands which the adventure understands. It tells the adventure what the player wants to do if a particular word is used in a particular order, and in combination with other words. If the parser successfully interprets the desired action, then the action will be executed and the adventure continues. If not, the parser will alert the player by responding with a phrase such as "I don't understand what you mean."

If you think that the parser's job hinges on this "reference" of commands, you would be correct. But what is this "reference"? Really, the reference is a complicated inter-working of computer checks and statements, which begins with a list of recognized words, known as System Commands. But, these System Commands are only the basic, default commands built into the parser engine (Adrift Runner). The list of commands can be further extended by the creator of the adventure. Task Commands is the name given to the extended list of commands, and together with the System Commands, they make up the basis for every interaction between the player and the adventure.

Definitions

System Commands

Adrift Runner has a built in set of default commands which the parser engine will always understand (assuming that the player uses them in the correct way). These commands are known as the System Commands. For a reference of all the System Commands used in Adrift, please navigate to the Homepage and click on the Reference menu. System Commands cannot be added to or deleted, but they can be overridden using Task Commands.

Task Commands

Task Commands are those commands created by the author of an adventure. They can be used in conjunction with the default System Commands, or they can be used to override certain System Commands. They are created in the Task dialog box of Adrift Generator and are tied to the performance of a specific task or set of tasks. These tasks determine what will occur next in the adventure.

Creating Task Commands

Let's say, for example, that you want the player to be able to dig a hole in the ground. You, as the creator, would need to make a task which the player can access by typing in a certain command, a Task Command. First, create a new Task by (1) selecting Create - Task, (2) by clicking the Create Task button, or (3) by right-clicking in the Tasks window and selecting Add task. The Task dialog box appears with several options. This tutorial will only discuss those options relating to Task Commands.

Notice the first section under the Description tab, called "What the user must type". This is where you enter every Task Command you want to associate with this particular Task. In our example, we are digging a hole in the ground, so we need to think of every command the player might type to accomplish this. It is important to think of every possibility, because there is nothing more frustrating as a player then trying to accomplish something in an adventure and not being able to because you aren't using the same phrase that the creator thought of.

Each of these commands would be entered into the "What the user must type" list. You can enter up to a maximum of 25 commands. Of course, there is a way to phrase commands so that only a few commands will accommodate all these possibilities. The section Phrasing Commands will discuss this in more detail.

Now, enter a "Message upon completion" and set which room(s) the Task is allowed to run in. For example, you probably wouldn't want the player to be able to dig a hole in a second floor bedroom. Save the Task and your adventure. Congratulations! You have just created your first set of Task Commands. The player can now use something other than the normal System Commands to manipulate events in the fictional story you have created.

Phrasing Commands

The most important part of creating Task Commands is how to phrase the command. If you phrase the command too restrictively, then the user may never be able to execute the Task. If you phrase the command to broadly, then the user may accidentally invoke the Task when they meant to do something else. To make it even more difficult, you also want the player to be able to structure his commands as much like a sentence as possible to prevent the adventure from seeming so "computer-like". Finally, you as the writer want to accommodate all the possible phrases the player might type with as few Task Commands as possible. With each of these things in mind, the following are some guidelines to consider.

First, limit each Task Command to the necessary keywords. If you are digging a hole in the ground, the only words you really need in the Task Command are "dig ground".

Second, to accommodate for other phrasing the player might use, add appropriate additional commands, such as "dig hole", "dig dirt", "dig down" or simply "dig".

Third, make use of the wildcard feature to enhance the realism of the game and to accommodate for an almost limitless number of possible phrases. A wildcard is denoted by an asterisk (*) and is used in two primary ways:

Attached Method. Attach an asterisk to a word to extend the functionality of the word. For example, to allow for both singular or plural, you might use a command like "take dish*". This command would then work regardless of whether the player typed "take dish" or "take dishes".

Detached Method. Include an asterisk as a separate character to accommodate for additional words the player may use. These words will ultimately be discarded by the Adrift parser, but they make the adventure more realistic. Using our digging example, you would enter the command:

* dig * ground *

Note the spaces between the asterisks and the words (there should be no space at the very beginning or end). Now, our digging task can be invoked by any of the following entries by the player:

"dig ground"
"dig in the ground"
"dig hole in ground"
"dig hole in ground over here"

And believe it or not, even this phrase will work:

"please use the rusty shovel to dig a large
hole in the hard ground over by the pool of milky water"

You can see how valuable a wildcard can be! Generally, you can always use wildcards around all your words in a command. Be careful to double-check the possibilities though. For instance, * pick * club * will move the object "club" to the player's inventory when the player types "pick club". But that doesn't make sense. The correct way to get the club is to say "pick up club". So, the correct Task Command would be * pick up * club *. Notice there is no asterisk between "pick" and "up" because they should always be used together in this situation.

Coming up with the correct Task Command takes a lot of thought. It's probably one of the most challenging aspects of Adrift concerning both realism and functionality. A good adventure writer makes it a priority to use appropriate commands in the most effective way, while still contributing to the realism of the game.

Overriding System Commands

When creating any kind of complex adventure, a writer will inevitably ask the question "Can I change the default response for a specific command?" The answer to this question is YES! And the process is called "overriding a System Command". The important thing to remember is that you are NOT redefining the System Command you are overriding. You are merely replacing it for a SINGLE task at a GIVEN MOMENT. What does that mean? It means you are telling the Adrift parser to use your Task Command instead of the default System Command only when the player types the command in a specific location and under specific circumstances. If the location and circumstances don't meet the requirements to execute the Task, then the default System Command will be executed as usual.

To override a System Command, simply use the command in one of your Tasks as a Task Command. Generally, it is relatively straightforward. For example, one of the default System Commands is "jump". Let's say we don't like the default response for "jump" and we want to change it. To do so, we need to create a Task for jumping with a Task Command "jump" and a message such as "Whoopee! If only you had a jump-rope!" Now, when the player types "jump", the response will be the one we just created instead of the default response.

Unfortunately, it's not always that easy. There are many things which can prevent you from successfully overriding a System Command. Each of them is outlined in detail below:

Unspecified Room. Not specifying the correct room (or any room at all) is one of the most common reasons a System Command is not successfully overridden. When you first create a Task, no rooms are selected by default. You need to set the location your Task should override the default. Sometimes, you may always want the System Command to be overridden. In this case, you would select "All Rooms". Otherwise, select the applicable room(s).

Task Restrictions. Though Task Restrictions will not be discussed at length here, it is important to note they can cause problems overriding System Commands in two ways. First, if the restrictions on a Task are not met, then the parser falls back to the default System Command. To get around this, you will sometimes need to create two Tasks. One where the restrictions are satisfied and one with no restrictions. Then, if the player fails to meet the restrictions when they type in the command, the parser will fall back on the other Task because it has no restrictions. The second way Task Restrictions can cause problems is simply wording them incorrectly. Go back and make sure your restrictions are written correctly and in the correct order (order determines which restriction is analyzed by the parser first).

Incorrect Task Command. Make sure you have (1) spelled the command correctly, and (2) correctly named any objects associated with the command. For instance, if the object is a "red ball" and you just type "ball" in the Task Command, then the parser will default to the applicable System Command.

Multiple Task Commands Required. This is the second most common problem with overriding System Commands. Generally, this happens with the "get" command. Adrift actually uses three (3) commands to move an object to the player's inventory: get, take and pick. If you don't place all three of these in your Task Command, then the parser will default to the System Command for "get". In other words, include the following for any type of object retrieval (the asterisks are not required, but add to game realism):

* get * <object> *
* take * <object> *
* pick * <object> *

Abbreviations for Commands. Don't forget that some commands have abbreviated commands associated with them. For example, "north" can also be invoked by "n". That means that both are required in your Task Command to successfully override the System Command. Some commonly missed ones are:

all directions (n, s, e, w, ne, se, etc.)
inventory (i, inv)
look (l)

Repeating Task. This is another kicker. When creating your Task, don't forget to select the Reversible tab and check Repeatable Task. If you don't, then the first time Adrift checks the restrictions in your task is the only time the Task will run. So, if the restrictions fail, then the Task will never be considered by Adrift again. Checking the Repeatable Task box will ensure Adrift looks at this Task everytime it might apply!

If you look at all these possibilities and still cannot successfully override the System Command, you may want to have someone else take a look at your TAF file. Often, a second eye can see something you didn't.