Tasks

From ADRIFT 5 Manual Wiki
Revision as of 19:07, 22 April 2011 by Campbell (Talk | contribs) (Created page with "ADRIFT 5 resolves the problems created in v4, where you wish to override the standard commands (e.g. get/take/wear/push etc). All standard commands that used to be defined withi...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

ADRIFT 5 resolves the problems created in v4, where you wish to override the standard commands (e.g. get/take/wear/push etc). All standard commands that used to be defined within Runner, are now defined by General tasks within the ADRIFT Standard Library.

In ADRIFT 5 there are three types of tasks. All these tasks are identical in the way they perform, i.e. they all have restrictions, actions and output. The way they differ is how they can be activated. The tasks types are as follows.

General Tasks

General Tasks are the equivalent of normal tasks in v4. These allow you to define your own verbs, and accept any particular input from the player. You can use wildcards, and advanced command construction (ACC) as before. (New to version 5 - you can even use both together in the same command if you really wish). Due to the nature of wildcards, however, it is generally recommended that you restrict your use of them as much as possible. Most tasks should be possible to write using ACC alone.

You can have many more references in v5 than you could in v4. The following references have been defined:

%object%, %objects%, %object1-5%, %direction%, %character%,  %characters%, %character1-5%, %text%, %number% 

For example, the library task “Take objects from others” is defined with the following two commands:

[get/take/pick up] %objects% from %object2%
pick %objects% up from %object2% 

Each reference will automatically resolve to partial references. For example, if you have an object defined as

Article = “a”, Adjective = “large brown”, Noun = “bear”, “teddy”

You can then refer to “a large brown bear”, “a brown bear”, “a large teddy” etc within your command. "The" is always accepted as a direct article, so the command "the teddy" would also match.

If you mention a reference in one command in your task and you have more than one command, you must mention the same references in all the other commands.

Each reference must be unique within a command. So for example, if you wish to refer to more than one object, you must use %object1% and %object2%, rather than %object% and %object%.

Specific Tasks

Specific tasks are new to v5, and allow you to override general tasks with your specific requirements. You should find that the majority of your tasks can (and should) be created using Specific tasks, rather than General ones.

To override a general task, simply select the general task from the dropdown. Any references that were defined in the general task should be displayed as clickable links. You can then click on each of these to assign the specific items relevant to your overriding task.

When checking to see which task should run, ADRIFT will check all the general tasks to see what matches the player input. Once it finds a suitable task that passes all the restrictions, it will then check to see if there are any specific tasks for that general task. If so, it will check the additional restrictions on the specific task. It will also match any references that may be defined in the specific task.

Because specific tasks will only ever run if the general task it overrides passes it's restrictions, it is not necessary to repeat the restrictions of the general task on the specific task.

It is also possible to have a specific task based upon another specific task. If the original general task has multiple references, and you create a specific task which only assigns some of the references, that task will then become available to override for further specific tasks.

For example, say you have defined the general task:

Give %object% to %character% 

This task could give a default response of “%Character% is not interested in %TheObject[%object%]%”. Say you wanted something particular to happen whenever you gave objects to a particular character. So you might create the specific task:

Give %object% to Campbell 

You could then give a different response, such as “Campbell thanks you for %TheObject[%object%]%, but graciously declines.” You may then want to have something specific happen when offering a particular object to Campbell. So you might create a specific task based on the above specific task such as:

Give money to Campbell 

With response “Campbell’s eyes light up. ‘Ooh, thank you very much!’”

System Tasks

System tasks are tasks that can only be activated by task actions, or events. They are the equivalent of creating tasks in v4 and preceding the command with the hash (#) symbol. You can optionally run system tasks when the adventure starts by selecting the Execute Task immediately at start of adventure checkbox. This is useful for intialising variable and task values.

Summary

So in summary:

  • General Tasks – Allow you to create your own verbs
  • Specific Tasks – Run a general task with specific items
  • System Tasks – Tasks that can only be triggered from another task or event

Scope

Scope refers to where ADRIFT will look when you refer to an item. ADRIFT 5 has three levels of scope. These are Applicable, Visible, and Seen. Visible and seen should be pretty obvious. Applicable means it must match any task restrictions on the task creating the reference.

When you create a task that references an object or character, ADRIFT will check the scope to see which one you are referring to. So, say you create a task

eat %object% 

You may add a restriction that the referenced object must have a property ‘edible’.

So, say you create two objects, “a chocolate button” and “a large red button”, and give the former the property “edible”. If you then type “eat button”, ADRIFT will first check to find all objects that match the applicable scope. There are two buttons, but only one of them is in applicable scope, and so ADRIFT will automatically assume you mean the chocolate button. If the chocolate button didn’t have the edible property, neither buttons will match applicable scope, and so ADRIFT will look to see which ones are visible. If only one is visible, ADRIFT will assume that’s the button you are referring to. If neither are visible, ADRIFT will check to see which ones you have seen before. So if you have come across the red button in the game but not the chocolate button ADRIFT will assume you are referring to the red button. If, after all three levels of scope have been checked, there are still multiple possibilities, ADRIFT will prompt for disambiguation.