Quest Chain Forge Wizard
The Quest Chain Forge Wizard is the second of three wizards in Simple Quest Forge. While the Quest Forge creates individual quest definitions (the building blocks), the Quest Chain Forge groups those quests into ordered storylines—quest chains that represent multi-step narratives, story arcs, or progression paths in your game.
Each chain contains steps that reference quest codes from your Quest Forge database. Every step carries three key properties: a sortOrder that controls sequencing, an isRequired flag that marks mandatory versus optional steps, and a branchGroup string that enables player-choice branching within the chain.
Open the wizard via Window › Simple Quest Forge › Quest Chain Forge Wizard.
It walks you through a 5-step process similar to the Quest Forge, but focused
on organizing quests into meaningful sequences rather than defining individual quest content.
Quest chains are ideal for any scenario where completing one quest should lead to another. Whether you are building a 20-quest main story campaign, a 5-quest companion loyalty arc, or a branching moral dilemma with multiple outcomes, the Quest Chain Forge gives you the tools to define those relationships visually in the Unity Editor.
Relationship Between Quest Forge and Quest Chain Forge
Understanding how these two wizards relate is important before you begin:
Quest Forge (Individual Quests)
Creates standalone quest definitions—each with a code, name, description, objectives, rewards, and dynamic properties. Quests are the atoms of your quest system. They exist independently and know nothing about chains.
Quest Chain Forge (Quest Groups)
Creates chain definitions that reference quest codes from Quest Forge databases. Chains are the molecules—they organize atoms into meaningful sequences. A chain does not duplicate quest data; it simply says "do quest X, then quest Y, then quest Z."
The typical workflow is:
WOLF_MENACE, THE_LOST_PENDANT, HELP_THE_VILLAGE).Chain Structure
Quest chains use a flat Chain > Steps structure (similar to SEF's Squad Forge). Each chain is a named container holding an ordered list of steps. There is no deeper nesting— a chain is simply a sequence of quest references with ordering and branching metadata.
Here is an example of what a chain looks like:
In this chain, the player completes quests 1 and 2 in order, then faces a choice between
helping or raiding the village (both in branch group "moral_choice"), and finally
completes the dragon quest. The chain has 5 steps, but only 4 are played in any single
playthrough.
Chains also have their own dynamic properties (Categories, Flags, Numerics, Texts) defined in Step 2 of the wizard. These describe the chain as a whole—not individual steps. For example, you might tag a chain with a "Region" category or a "Minimum Level" numeric.
Understanding Chain Steps
Each step in a quest chain is a SimpleQuestChainStep struct with four fields.
Understanding what each field does is essential for building effective chains.
questCode
The quest code that this step references, matching a quest in one of your linked Quest Forge
databases. For example, "WOLF_MENACE" or "DELIVER_THE_LETTER". In the
wizard, this appears as a dropdown so you can select from available quests without memorizing codes.
The dropdown shows both the quest name and code for easy identification.
sortOrder
An integer that controls the order in which steps are presented to the player. Lower numbers
come first. Steps with sortOrder: 1 come before steps with sortOrder: 2,
which come before sortOrder: 3, and so on.
Steps that share the same sortOrder are considered to be at the same point in the chain.
This is most commonly used with branch groups: two steps at sortOrder: 3 in the
same branch group represent a choice the player must make at that point in the story.
You can also use the same sortOrder for unrelated steps that the player can complete in any order (e.g., "gather three items" where each item is a separate quest at the same sortOrder).
isRequired
A boolean flag indicating whether this step must be completed for the chain to be considered
finished. When isRequired is true, the player cannot skip this step
(or, for branch groups, must complete at least one step from the group). When false,
the step is optional—the player can do it for extra rewards or lore, but the chain progresses
regardless.
Common uses for optional steps:
- Bonus side objectives that reward extra XP or items
- Lore-heavy exploration quests that flesh out the story
- Challenge quests that only dedicated players will complete
- Time-limited opportunities that may expire as the chain advances
branchGroup
A string that groups steps into player-choice branches. This is the most powerful feature of the chain system. The rules are simple:
- Empty string (
"") — The step is sequential. It is a normal step in the chain that the player encounters in sortOrder. Most steps use this. - Non-empty string (e.g.,
"moral_choice") — The step belongs to a named branch group. All steps sharing the same branchGroup string are alternatives—the player picks one path, and the others are skipped.
See the Branch Groups section below for a deep dive with examples.
Branch Groups
Branch groups are the key mechanism for player choice within quest chains. They allow you to create meaningful decisions that affect how a storyline unfolds, without needing any scripting or complex graph editors.
How Branch Groups Work
The concept is straightforward: steps that share the same non-empty branchGroup
string are treated as alternatives. When the player reaches that point in the chain (determined
by sortOrder), they choose one path from the group and the other paths are skipped. The chain
then continues with the next sortOrder value.
Steps with an empty branchGroup (the default) are always sequential—they
are regular steps that every player completes.
Naming Branch Groups
Branch group names are arbitrary strings. You can name them whatever makes sense for your design. Descriptive names are recommended so that the chain is self-documenting:
| Branch Group Name | Meaning | Example Steps |
|---|---|---|
"" (empty) |
Sequential — not a branch, always played | Standard quest steps everyone completes |
"moral_choice" |
A moral dilemma — pick one path | "Help the village" vs. "Raid the village" |
"class_quest" |
Class-specific path — pick your class quest | "Warrior Trial" vs. "Mage Trial" vs. "Rogue Trial" |
"faction_loyalty" |
Faction allegiance — pick a side | "Join the Rebels" vs. "Serve the Empire" |
"approach" |
Tactical approach — how to solve the problem | "Stealth Infiltration" vs. "Frontal Assault" vs. "Diplomatic Solution" |
Example: A Complete Chain with Multiple Branch Points
Here is a more complex chain that demonstrates multiple branch groups:
In this chain, a player will complete 5 or 6 quests out of the 9 defined (depending on whether they do the optional step). They make two independent choices: which faction to join, and which approach to take for the final mission. That gives 2 x 3 = 6 possible playthroughs of the same chain.
Branch Groups with More Than Two Options
Branch groups are not limited to binary choices. You can have as many steps in a group as you
want. A "class_quest" branch group might have 6 steps—one for each playable
class. The player completes the one matching their class, and the others are skipped.
Multiple Branch Groups in One Chain
A single chain can have as many different branch groups as needed. Each group is independent. Just make sure each group has a unique name. The names only need to be unique within the same chain—different chains can reuse the same branch group names without conflict.
SimpleQuestChainTracker to track chain
progression, record branch choices, and sync with SimpleQuestTracker for individual
quest state. See Runtime API for details.
Step 1 — Setup
Configure database identity and link your Quest Forge databases.
Database Identity
Set the name, namespace, generation prefix, and suffix for this quest chain database. These
control the names of the generated C# types and asset files. For example, with prefix
My and suffix Story, you would get MyStoryChainDatabase.cs.
Linked Quest Databases
Drag and drop one or more generated Quest Forge database assets into the quest database list. These provide the quest code dropdowns in Step 3 when adding steps to chains. You can link multiple quest databases—codes from all of them are merged (first database wins for duplicate codes).
The setup step also supports drag-and-drop: you can drag database assets directly from the Project window onto the database list area.
Step 2 — Definitions
Define chain-level dynamic properties. These properties apply to the chain as a whole, not to individual steps. Use them to categorize, tag, and describe your chains with structured metadata.
The four property types available:
- Categories — Enumerated properties with predefined entries. Examples: Chain Type (Main Story, Side Story, Companion), Region (Forest, Desert, Mountain), Difficulty (Easy, Normal, Hard).
- Flags — Boolean on/off toggles. Examples: Is Repeatable, Unlocks New Game Plus, Has Branching, Faction-Locked.
- Numerics — Float or integer values with optional min/max ranges. Examples: Minimum Level, Total XP Reward, Estimated Duration (minutes), Number of Quests.
- Texts — Free-form string fields with configurable line count. Examples: Synopsis, Epilogue, Designer Notes, Unlock Conditions Description.
All four property sections are always visible in the wizard, even when no definitions exist yet. Empty sections show a "No X defined." placeholder. This makes it obvious that the feature exists and is available when you need it.
Schema Export and Import
Schema export/import is available at the top of this step with four buttons: Full JSON, Light JSON, Markdown, and Import. These work the same way as Quest Forge's schema export. The schema captures your property definitions so you can share them between projects, back them up, or use them with AI-assisted content generation workflows. See AI Workflow for details.
When exporting, linked quest references use the SchemaLinkedEntry format—
each reference is stored as a {code, name} pair rather than a bare code string.
This gives AI assistants and human readers the display name alongside the code for better context
when working with exported schemas.
Step 3 — Chains
Create and edit chains in a split-panel layout. The left panel shows the chain list with search, sort, and pagination controls. The right panel shows the full chain editor for the selected chain.
Left Panel — Chain List
The chain list shows all chains with their names and codes. You can search by name or code, sort alphabetically or by creation order, and paginate through large lists. Use the + button to add new chains and the - button to remove the selected chain.
Right Panel — Chain Editor
Identity Section
- Name — The display name of the chain (e.g., "The Dragon Saga")
- Code — A unique identifier (e.g., "DRAGON_SAGA"). Use the Auto button to generate a code from the name automatically.
- Description — A free-form text description of the chain
- Icon — An optional sprite icon for the chain
Steps Section (Nested ReorderableList)
The steps section is a reorderable list where you add, remove, and reorder the quest steps in this chain. Each step in the list shows:
- Quest Code — A dropdown populated from all linked quest databases. The dropdown shows quest names alongside codes so you can identify quests without memorizing codes.
- Sort Order — An integer controlling step sequence. Lower values come first. Steps with the same sortOrder are either parallel objectives or branch alternatives (depending on branchGroup).
- Is Required — A checkbox indicating whether this step must be completed for the chain to be considered finished.
- Branch Group — A text field for the branch group name. Leave empty for
sequential steps. Enter a descriptive name (e.g.,
"moral_choice") to group steps into player-choice branches. Steps sharing the same non-empty branchGroup value are presented as alternatives—the player picks one. Branch groups are color-coded in the editor for visual clarity.
Chain-Level Properties Section
Below the steps, you will see all Categories, Flags, Numerics, and Texts defined in Step 2. Set the values for each property on a per-chain basis. For example, set the "Chain Type" category to "Main Story", toggle the "Is Repeatable" flag, enter the "Minimum Level" numeric, etc.
Step 4 — Settings
Configure output paths and generation options. This step is identical in structure to Quest Forge's settings step. You can customize:
- Output Folder — Where the generated scripts and data asset will be
saved. Default:
Assets/Generated/QuestChains. - Script Subfolder — Subfolder for generated C# scripts within the output folder.
- Data Subfolder — Subfolder for the generated ScriptableObject asset.
Step 5 — Generate
The final step performs two-phase generation. This is the same process used by all Simple Quest Forge wizards:
AssetDatabase.Refresh() to trigger Unity's compiler.[InitializeOnLoad] handler detects the SessionState flag
(SimpleQuestForge_QuestChain_WaitingForCompilation), waits one frame via
delayCall, then creates the ScriptableObject asset and populates it with your
chain data from a temporary JSON file.This two-phase approach is necessary because Unity must compile the new C# types before an asset of those types can be created. The SessionState flag ensures the process resumes correctly even if Unity's domain reload takes a moment.
What Gets Generated
After generation completes, you will have the following files:
Where {GP} is your generation prefix (set in Step 1). For example, with prefix
Fantasy, you would get FantasyChainType.cs,
FantasyChainDatabase.cs, etc.
Generated Database Features
The generated database ScriptableObject implements ISimpleQuestChainDataSource and
includes:
- All chain definitions with their steps and dynamic property values
- Metadata arrays for property definitions (category labels, flag names, numeric names, text names)
- The custom editor provides a split-panel inspector with search, sort, pagination, and bulk operations—matching the same polish level as the Quest Forge generated editor
Runtime Data Structures
The runtime types are defined in SimpleQuestChainDefinition.cs under the
SimpleQuestForge namespace. These are the structs your game code interacts with
at runtime.
SimpleQuestChainStep
Key points about SimpleQuestChainStep:
branchGroupis a string, not an integer. An empty string ("") means the step is sequential. A non-empty string groups steps into player choices—all steps sharing the same branchGroup value are alternatives.- The constructor provides sensible defaults:
sortOrder: 0,isRequired: true,branchGroup: "". - A null branchGroup is automatically converted to an empty string in the constructor.
SimpleQuestChainDefinition
Convenience Methods Explained
| Method | Returns | Description |
|---|---|---|
StepCount |
int |
The number of steps in this chain (null-safe). |
GetRequiredSteps() |
SimpleQuestChainStep[] |
Returns all steps where isRequired is true. |
GetBranchGroup(string group) |
SimpleQuestChainStep[] |
Returns all steps belonging to the named branch group. Returns an empty array if the group name is null or empty. |
GetBranchGroups() |
string[] |
Returns an array of all unique non-empty branch group names in this chain. Useful for discovering what choices exist. |
Example: Querying a Chain at Runtime
Utility Windows
Simple Quest Forge provides two utility windows that are especially helpful when working with quest chains:
Quest Browser Window
A read-only browser that lets you quickly search and inspect all quests across your generated databases. This is useful when designing chains—you can keep the Quest Browser open alongside the Quest Chain Forge wizard to look up quest codes, check quest details, and verify that the quests you want to reference actually exist.
Open via Window › Simple Quest Forge › Quest Browser.
Quest Dependencies Window
Shows cross-references between quests, chains, and procedural templates. For any selected quest, you can see which chains include it as a step and which procedural templates reference it. For any selected chain, you can see all the quests it contains and whether they exist in the linked databases.
Open via Window › Simple Quest Forge › Quest Dependencies.
Schema Export & Import
The Quest Chain Forge supports the same schema export/import system as all other Simple Quest Forge wizards. Schemas are available in Step 2 (Definitions) and capture your property definitions and chain data for backup, sharing, or AI-assisted workflows.
Export Formats
- Full JSON — Complete schema including property definitions, all chain
data, and linked quest references as
{code, name}pairs (SchemaLinkedEntry format). Use this for full backup or AI content generation. - Light JSON — Property definitions and instructions only, without actual chain data. Use this when you want an AI to generate chains from scratch using your schema.
- Markdown — Human-readable documentation of your schema with tables, examples, and instructions. Linked quest codes include both code and name columns.
Import
Import a previously exported JSON schema. The import process presents a 3-choice dialog for both definitions and chain data: Replace (overwrite existing), Merge (add new, keep existing), or Skip (ignore that section). This gives you fine-grained control over what gets imported.
questCode field on chain steps), they are stored as {"code": "WOLF_MENACE",
"name": "Wolf Menace"} pairs rather than bare code strings. This gives AI assistants and
human readers the display name alongside the code for better context. On import, only the
code field is used for matching.
Designing Good Chains
Here are practical tips for creating effective quest chains:
Start with an Outline
Before opening the wizard, sketch out your chain on paper or in a text file. List the quests in order, mark which ones are required versus optional, and identify where player choices occur. It is much easier to reorganize an outline than to restructure steps in the wizard.
Keep Chains Focused
A chain should represent a single coherent storyline or progression arc. If your chain has 30+ steps covering multiple unrelated plot threads, consider splitting it into multiple shorter chains. This makes chains easier to manage and gives players a sense of accomplishment as they complete each one.
Use Branch Groups Sparingly
Branch groups are powerful, but every branch point multiplies the number of possible playthroughs. A chain with 3 binary branch points has 2 x 2 x 2 = 8 possible paths. That is 8 paths you need to test and ensure make narrative sense. One or two meaningful choices per chain is usually the sweet spot.
Name Branch Groups Descriptively
Use names like "faction_loyalty", "moral_choice", or
"class_quest" instead of generic names like "branch_1". Descriptive names
make your chain data self-documenting and easier to understand months later when you revisit the
project.
Leverage Optional Steps
Not every quest in a chain needs to be required. Optional steps add depth for invested players without blocking progression for those who want to move on. A good pattern is a required main objective followed by one or two optional bonus objectives at the same sortOrder.
Test with SimpleQuestChainTracker
Once you generate your chain database, use the SimpleQuestChainTracker runtime class
to simulate chain progression. Feed it completed quest codes and verify that chains advance
correctly, branches resolve as expected, and optional steps do not block required progression. See
Runtime API for details on the tracker.
Use the Dependencies Window
After building your chains, open the Quest Dependencies window to verify that all referenced quest codes actually exist in your linked databases. A chain that references a deleted or renamed quest code will not cause a compile error, but it will produce broken data at runtime.