Quests

Design parameters

The quest system is a game instance subsystem, meant to be interacted with from anywhere, but primarily inside a Flow graph.

The quest system has the following requirements:

  1. Serialization

  2. Reusable components to create complex and consistent game behavior.

  3. Multi-world travel with no data loss.

  4. Simple to use and easy to follow design process.

  5. Even though I don't plan on having thousands of quests, it has been designed with such an extreme case in mind.

  6. Majority of the system runs on soft references, quests can be progressed and so forth without ever loading the quest data assets.

The components that build a quest are the following:

  • The subsystem

    • All functions and data is designed to live inside the quest subsystem.

    • All functions are static to have cleaner code.

  • The quest itself

    • Quests can be failed.

    • Quests can have requirements.

    • Quests do not have rewards. Rewards should be selected/granted through UI and other Flow nodes that can easily be connected to the Completed pin on the quest node.

  • The task to complete the quest

    • Some tasks can be optional. Technically all tasks can be optional, it is up to your system to call "Complete Quest" if you make every task optional.

    • Tasks can be failed.

    • Tasks can use instanced objects for their requirements and fail conditions.

  • Flow nodes

    • Quests and tasks are meant to be designed inside of the quest node, then if you need to listen or progress a task, you use the appropriate nodes. You can look inside these nodes to see how they interact with the quest system.

  • (Optional) Link the quest to a quest chain.

    • Chains have "stages", where each stage requires the stages before it to be completed before you can move onto the next stage.

Flow interaction

The quest node will display the quest title, text, tasks and their required progress, and any chains the quest is a part of.

There are other nodes that will progress, listen to, or retrieve the current state of a quest or task.

Base Classes

  • QuestSubSystem - Game instance subsystem that handles and stores all quests. Majority of the functions you will be calling can be found in this class.

  • DA_Quest - The asset that defines your quest and its tasks, requirements, fail conditions, rewards and other data.

  • DA_QuestChain - The asset that defines a chain of quests and their stages.

  • FN_ListenToTask - Listens to a quest tasks progress.

  • FN_ProgressTask - Progresses a task by a set amount.

  • FN_Quest - The quest node. This is customized to show the quest title and its tasks inside the node.

  • O_TaskFailConditionBase - Base class to create fail conditions for tasks.

  • O_TaskRequirementBase - Base class to create requirements for a task.

Dev tools

  • A ImGui debugger can be found on the ModularityPractice repo, but I will slowly be replacing this debug tool with Cog in the future.

  • You can use the SetQuestState console command to forcibly set the state of a quest, which greatly helps game testers jump to certain parts of the game. The ImGui debugger is much more efficient at this.

Known bugs:

  • The StartQuest node might cause crashes when in standalone mode. This crash does not happen in packaged builds.

  • All quests should ideally be inside the players root flow, preferably as a sub graph. This is to simplify serialization and restoring the graphs. Since the subsystem stores all the data, you only need to worry about placing checkpoints in the correct locations to restore the graphs to the correct state.

  • It is advised to keep quests either in their own graph, or a set of quests (within the same quest chain, or if this group of quests are highly related to one another) in their own graph. For example, the tutorial might be a series of quests. If it's a quest chain, then they should be in a shared graph. If you aren't using a tutorial quest chain, then this is an example of a group of quests being relatable enough that they deserve to be in a shared graph. If you are using the quest chain system, then its rare that a set of quests are relatable enough that they deserve to be in the same graph, AND are not part of the same quest chain.

Change log

1.3

  • Added console command for forcefully setting a quest state.

  • Added quest chains.

  • Quest node now displays any quest chains its related to at the bottom.

  • Quest node will now update when the data asset has any property changed.

  • ImGui debugger revamped.

  • Added a EditorScriptingTools widget to modify the quest data asset in the Quest node's details panel.

1.2

  • Quests are now stored in a TMap

  • Removed support for dynamic tasks. This was just complicating QA.

  • All the subsystem functions are now static.

  • Rewards have been removed, should be handled through UI and/or flow nodes.

1.1

  • Quest component changed to subsystem.

  • Added Vislog support.

  • Added EditorAssistant support.

  • Custom thumbnail for quests added.

  • FE_CommonData has been split into two for dialogue and quests.

  • Tasks now use instanced objects for conditions and requirements

Last updated