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:
Serialization
Reusable components to create complex and consistent game behavior.
Multi-world travel with no data loss.
Simple to use and easy to follow design process.
Even though I don't plan on having thousands of quests, it has been designed with such an extreme case in mind.
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.
Recommended design pattern
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