Skip to content

Tasks

At the bottom section of the Quest asset there's the Tasks Hierarchy panel, which controls the logic behind the Quest.

Quest Tasks Hierarchy

What is a Task

A Task is a node that can contain a series of Subtasks, which in turn may contain other Subtasks.

The two buttons at the left of the top toolbar allow creating a new Task: The left one creates a Task node as a sibling of the current selected one, while the right one creates a child Task.

The right button toggles the Task Inspector tab, which allows to edit the currently selected Task details.

Drag to move Tasks

You can hold the left mouse button over a Task and drag it somewhere else to reorganize your Tasks

Task States

A Task can be in one of the following states at any given time:

  • Inactive: The default state.
  • Active: An active task is currently being executed and can transition to a finished state.
  • Completed: The task has been successfully resolved.
  • Abandoned: The task has been abandoned, with similar effects to the failed state.
  • Failed: The task has been failed.

Tasks Transitions

A Task can't transition to and from any state. Instead, there's a set of rules that define those.

  • An Inactive Task can only transition to an Active state.
  • An Active Task can transition to either Inactive, or to any finished state.
  • A Finished state can only transition to an Inactive state.

Finished States

A Finished state means either Completed, Abandoned or Failed.

Switch to an invalid State

If an Inactive task tries to change its state to Completed, the command will be ignored because only an Active task can be completed.

Task Anatomy

To modify the properties of a Task, select it from the Tasks Hierarchy and reveal the Inspector on the right side by clicking on the top-right button of its toolbar.

Task Details

Settings

The Completion mode field determines how this Task is completed, if it has any subtasks.

More Information

More information about Subtasks at the Running Subtasks section.

The Is Hidden field determines whether this particular task should be considered as hidden. This is used to skip displaying a particular task-line in the UI.

The Name and Description fields are also used by the user interface to communicate the information about this particular task.

The next fields, Color and Sprite, are optional and can be used to customize the appearance of different tasks.

Using Sprites for Tasks

For example, it may be desirable to display a different icon on the HUD depending on the task at hand. Some investigation tasks might display a magnifier, while an assassination task could display a skull icon.

Counters

The Use Counter allows to define a task as a countable one or not. The options available are None, Value and Property.

No Counter

By default, a task is set to None by default. This means that the task must be completed using the Complete Task instruction. However, tasks can also include a counter that automatically completes the quest when the value and the counter become equal.

Example of Counter task

The most common example of a Counter task is when an NPC asks the player to kill a certain number of enemies. The counter would be the amount of enemies to kill, while the value would be the enemies killed so far.

As soon as the value and the counter are the same, the task is automatically completed.

Value Counter

This option displays a single Count To field, which is the value to reach in order to complete this task.

Task Counter type Value

Kill 5 boars

For example, if an NPC tasks the player to kill 5 boars, the Count To field would be 5. The starting value is zero at the beginning, and can be changed using the Task Value instruction.

In this case, the instruction would increment in +1 the value of the task, automatically completing it after defeating 5 boars.

Property Counter

The Property option is a bit more advanced, and allows to also count up to a certain amount in order to automatically complete the task, but the value is synchronized with a dynamic property.

Task Counter type Property

The Count To field, just like in the previous option, defines the desired value to reach.

The Value From field is a dynamic property that allows to choose the source from which the current value is taken. For example, a Global Variable.

From other Game Creator modules

This option allows to seamlessly combine Quests with other Game Creator modules. For example, a quest giver may ask to collect a certain amount of Potions, which is defined as an item in the Inventory module. The Value From, in this case, would be the amount of Potions.

The Detect When event is used to determine when the synchronization should be executed. For example, if the dynamic value comes from a Global Name Variable, the detection should be set to run when a global variable changes.

Follow-up with the Inventory module

Similarly, if we are using the amount of a particular Item of the Inventory module as the value of a counter task, the detection should be set whenever the Bag component changes.

Instructions

A Task, just like a Quest, has a collection of Instructions that can be executed whenever a task changes its state.

  • The On Deactivate is executed when a task changes its state to Inactive.
  • The On Activate is executed when a task changes its state to Active.
  • The On Complete is executed when a task changes its state to Completed.
  • The On Abandon is executed when a task changes its state to Abandoned.
  • The On Fail is executed when a task changes its state to Failed.

Running Subtasks

A Task that has one or more child Subtasks will be automatically Completed, Abandoned or Failed, depending on the value of its Completion field.

Tasks Completion Options

Subtasks in Sequence

This type of Task activates the first Subtask as soon as it is activated, leaving any subsequent subtasks inactive.

Subtasks in Sequence

When the Subtask is completed, the next sibling task is activated. This is repeated until all Subtasks are completed, at which point the Task is automatically completed too.

If any Subtask is abandoned or failed, the Task is also abandoned or failed, respectively.

Use case

Running a series of tasks in order is the most common type. For example, a quest-giver asking to find its Magic Sword and return it to them. In this case, finding the Magic Sword would be the first subtask, and completing it would activate the second subtask: returning the item to the quest-giver.

Subtasks in Combination

This type of Task activates all Subtasks as soon as it is activated.

Subtasks in Combination

These Subtasks can be completed in any order, and as soon as all of them are completed, the Task will also become completed.

If any Subtask is abandoned or failed, the Task is also abandoned or failed, respectively.

Use case

This type is mostly used during investigation segments: The player arriving at a crime scene and having to investigate multiple clues, in any order. For example, talking to a witness, investigating the footprints and doing a preliminary autopsy on the victim. After all these subtasks have been completed, the task will be completed too.

Any Subtask

This type of Task activates all Subtasks as soon as it is activated.

Any Subtask

As soon as any Subtask is completed, the Task will automatically be completed too and leave the rest of the Subtasks as active.

Because it only requires a single Subtask to be completed in order to complete the Task, the Task won't be abandoned or failed unless there are no other inactive Subtasks.

Use case

This type is used when making branching decisions where completing one subtask determines a different path than completing another subtask. For example, killing a targeted enemy or sparing its life. Once a decision has been made (aka a subtask has been completed), it locks the player from doing the other one.

Manual

This type of Task does not activate any Subtasks when activated.

Manual Subtask

If the other modes do not fit a particular quest flow, this one can be selected in order to customize each step, as it doesn't automatize any changes.

Use case

There aren't any particular use cases. However, if you want to take full control over when a task is completed (for example, despite its children subtasks not being completed), this might be useful.