Creating a Modular Quest System to help drive design and improve workflow

The goal in designing the quest system for All Flocked Up! was to keep possibilities as open as possible while creating a simple and dynamic workflow. The 5 core objective types included were aimed to cover as wide of a range of possible quest mechanics. These types include Interact, Attack, Collect, Location, Timer.

Quests are broken down in “Stages” and “Objectives”. Each quest can have multiple Stages and each stage can have as many Objectives as needed. Each Stage and Object can have their own rewards given (Experience, Item Rewards, Currency Rewards)

The Data Table is comprised of a collection of data compiled by the S_QuestDetails, S_StageDetails, and S_ObjectiveDetails structs. Adding a quest to the data table requires a QuestID, which is essential for determining when to progress through stages/objectives and populating the UMG widgets with quest details.

Quest Givers can be created as a child class of the BP_QuestGiver, allowing for a range of quest giver actors with various mesh. Interacting with any quest giver will take the QuestID associated to the QuestGiver and pull the corresponding row’s data to dynamically generate the UI. Upon Accepting the quest, an entry will be made in the Quest log . In the quest log the player is able to select the quest from either the Main Quest or Side Quest Tab to view details, current stage, current and completed objectives and rewards. The player is able to track the quest which will add a small widget to the viewport with the current tracked quest and objectives.

When an objective is completed, the current objective progress is stored and updated through a map of strings to integers. This converts all associated ObjectiveID’s into an integer that can then be called in sequence to complete objectives in the intended order.

This approach allows for easy implementation of quests and improved production workflow. Designers can use the DT_QuestData table to define specific details for all stages and objectives in each quest. Start by Adding a new row into the Data Table. Here you can define the Quest Name, Description, Tracking Description, Stages, isMainQuest, AutoAccept/AutoComplete and Quest Time (if applicable).

Under Stages, add an element to the array. This adds a new “stage” or segment to the quest. Each quest must contain at least ONE stage but is not limited otherwise. Here you can define the Stage Name, Description, Objectives, Experience, Item & Trinket (Currency) Rewards.

Now under Objectives, add an element into the array. This adds an objective to the current stage. Here you can define an Objective Name, Description, Objective Type, ObjectiveID, Quantity, IsOptional, Bonus Expereince rewards. The are 5 basic objective types included are Location, Attack, Collect, Interact, along with the previously mentioned Quest Time, which aim to cover a wider range of design scenarios. It is important to set the ObjectiveID as it will be used in determining quest progress and setting up some scene actors.

With the quest ready to be implemented in the map, the QuestGiverActor will need to be set up to give the player this quest. Create a copy of BP_TestNPC and change the static mesh or create a new NPC that can be derived from a base class. Any Actor can become a QuestGiverActor simply by adding the AC_QuestGiver component and having the class implement the BPI_QuestInteractionInterface. After placing the NPC actor into the scene, select it and view the details by searching “Quest Data” or clicking the AC_QuestGiver component. Here the data table reference can be set and given the Data Table row this NPC will use for it’s given quest.

BP_QuestLocationMarkers should be placed and given the ObjectiveID set for that objective if it is location based. This provides the location notification to appear when arriving (if applicable).

BP_CollectibleSpawn actors should be placed in locations where collection-based objectives are used. New collectible types can be created by creating a child blueprint class derived from BP_CollectibleBase. Change the mesh and any other properties and define the ObjectiveID this collectible would call (the one defined in the specific objective of the Data Table).

Here are three takeaways:

Building at scale

Creating streamlined solutions was extremely important for this project for a number of reasons including team size, scope, and milestone progression. This was intended to benefit production by decreasing the potential workload on the design and implementation teams by having a system that promoted a drag-and-drop approach to quest implementation. Through modularity, the goal to promote design, creativity and usability was elevated to a higher standard.