Tasks are missions (or quests) for the player to do and to progress in the game. In Story Framework they’re part of the task queue, which in turn is part of the inventory manager. We can add tasks to the queue, which when active can be later completed or failed. We must implement the “reaction logic” to these events ourselves, but Story Framework gives us the platform to tap into it.
Let’s take a look at some examples.
Creating Tasks
Let’s say I have an NPC who will give me (the player) a mission as part of a dialogue. In this example, we talk to The Professor, who would like us to procure a bone that’s hidden in a museum. When we find it, we can return to him and tell him we have it, completing the mission.
We can use one response to start the mission and add the task to the queue that way, and another response can call the completion of the active task. Here’s what this might look like in our custom NPC blueprint:
We’ve already seen how to react to custom events in my previous article about dialogues, but this is a good recap: by tapping into On Dialogue Reply event (part of the SFInteraction Manager), we can call a new custom event (Add Task Bones) that will Switch on String, each option being the response we want to test. Anything untested will not trigger any custom logic by default, but can be hooked up via the Default pin.
To create the task, we’ll grab a reference to the SFInteraction Manager and use Add Main Task to Queue with all our task info. The easiest thing for data entry is to promote this to a variable and populate it with default values. If a timer value is added, the player will see a countdown clock and has limited time to complete the task, or else it will auto-fail. Leaving the timer at 0 will give unlimited time.
Completing a Task
Let’s say our player collects the bone and gives it to the NPC, who will bring up an option to let us turn the bone over, thanks to a consequential tag. If this was indeed the active task, we can use Complete Current Main Task. This will move the next possible task up in the queue to become active, replacing the task that’s displayed at the top right of the screen. Alternatively, if there are no further tasks, the message will disappear.
If the player can start multiple tasks and we want to check that the Professor’s response is indeed completing the correct task, we can check this against the Task Header. Here’s the bottom branch of our Switch from above:
We grab the current (active) task, split its pins to extract the Task Header (Bone Collector in this case), then compare it with another Switch statement. Only if the current active task is indeed the one given out by the Professor earlier will the completion happen (or else the Default pin fires).
Failing a Task
If something was not successful, we can mark a task as failed. It’s as easy as this:
Updating a Task
Perhaps unforeseen circumstances demand a task in progress to change halfway through. This can be done with the Edit Target Main Task in Queue node.
This can change all aspects about the current task, which in turn will be updated at the to of the screen for the player to see. If you update the Task Header, make sure to implement the changed name in another check or else the previous task will never complete.
Accessing the Task Queue
Maybe you want to display a list of all upcoming tasks, or show the player all the good things they have already completed. Although memoirs and journal entries are much better ways to do this as they’re already built-in to Story Framework, we can access past and current tasks like this:
There’s also a convenient Find Task in Queue by Header function that can be used to find a particular task.
Amending the Task Structure
If you feel the need to amend a task itself with additional variables, feel free to add items to the structure TaskInfo_S (under StoryFramework – Core – Blueprints – Structures).
A good example would be to store if a task was started, completed or failed with a custom ENUM, or award a score based on how well the player has performed a task. This would make it easy to keep track of tasks at the end of the game.