View Format: Multi-Page

Simple Quest Forge

Generate Complete Quest Databases, Quest Chains, and Procedural Templates in Minutes.

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.

The 5 Steps: Setup → Definitions → Chains → Settings → Generate.

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:

1
Create your individual quests in Quest Forge first. Give each quest a clear, unique code (e.g., WOLF_MENACE, THE_LOST_PENDANT, HELP_THE_VILLAGE).
2
Open Quest Chain Forge and link your quest database(s) in Step 1 (Setup).
3
Build chains in Step 3 by adding steps that reference your quest codes. The wizard provides dropdowns populated from your linked quest databases, so you never have to type codes manually.
Order matters. You must have at least one Quest Forge database generated before you can use Quest Chain Forge. The chain wizard needs quest codes to reference—without a quest database, the step dropdowns will be empty.

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:

Chain: "The Dragon Saga" (code: DRAGON_SAGA) | |-- Step 1: WOLF_MENACE (sortOrder: 1, required, branchGroup: "") |-- Step 2: THE_LOST_PENDANT (sortOrder: 2, required, branchGroup: "") |-- Step 3a: HELP_THE_VILLAGE (sortOrder: 3, required, branchGroup: "moral_choice") -- player |-- Step 3b: RAID_THE_VILLAGE (sortOrder: 3, required, branchGroup: "moral_choice") -- choice |-- Step 4: THE_DRAGONS_BANE (sortOrder: 4, required, branchGroup: "")

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).

Tip: Leave gaps in your sortOrder values (1, 3, 5, 7 instead of 1, 2, 3, 4). This makes it easy to insert new steps between existing ones later without renumbering everything.

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:

Chain: "The Civil War" (code: CIVIL_WAR) | |-- Step 1: DISCOVER_CONFLICT (sortOrder: 1, required, branchGroup: "") | Everyone starts here. Learn about the war. | |-- Step 2a: JOIN_REBELS (sortOrder: 2, required, branchGroup: "faction_loyalty") |-- Step 2b: JOIN_EMPIRE (sortOrder: 2, required, branchGroup: "faction_loyalty") | Player chooses a side. This affects the rest of the chain. | |-- Step 3: GATHER_INTELLIGENCE (sortOrder: 3, required, branchGroup: "") | Both paths converge here. Everyone does this quest. | |-- Step 4: OPTIONAL_LORE (sortOrder: 4, NOT required, branchGroup: "") | Optional side quest for extra backstory. | |-- Step 5a: STEALTH_MISSION (sortOrder: 5, required, branchGroup: "approach") |-- Step 5b: FRONTAL_ASSAULT (sortOrder: 5, required, branchGroup: "approach") |-- Step 5c: DIPLOMACY (sortOrder: 5, required, branchGroup: "approach") | Second choice point: how to handle the final mission. | |-- Step 6: AFTERMATH (sortOrder: 6, required, branchGroup: "") | Everyone ends here regardless of choices.

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.

Runtime tracking: Use 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).

Quest DB is required. Unlike Quest Forge which can work standalone, Quest Chain Forge requires at least one linked quest database so that chain steps can reference valid quest codes. The wizard will not let you proceed to Step 3 without at least one linked database.

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:

1
Phase 1 — Script Generation: The wizard writes C# source files (the enum, database, and editor scripts) to your output folder, then calls AssetDatabase.Refresh() to trigger Unity's compiler.
2
Phase 2 — Asset Creation: After domain reload completes, an [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:

Scripts/ ├── {GP}ChainType.cs — Enum of chain codes ├── {GP}ChainDatabase.cs — ScriptableObject (ISimpleQuestChainDataSource) └── Editor/ └── {GP}ChainDatabaseEditor.cs — Custom Inspector Data/ └── {GP}ChainDatabase.asset

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

public struct SimpleQuestChainStep { public string questCode; // Quest code referencing the quest database public int sortOrder; // Order within the chain (lower = earlier) public bool isRequired; // Must complete to advance the chain public string branchGroup; // Empty = sequential, same non-empty string = player choice public SimpleQuestChainStep(string questCode, int sortOrder = 0, bool isRequired = true, string branchGroup = ""); }

Key points about SimpleQuestChainStep:

  • branchGroup is 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

public struct SimpleQuestChainDefinition { // Identity public string code; public string name; public string description; public Sprite icon; // Steps public SimpleQuestChainStep[] steps; // Dynamic properties (aligned with database metadata arrays) public int[] categoryValues; public bool[] flagValues; public float[] numericValues; public string[] textValues; // Convenience accessors — step queries public int StepCount { get; } public SimpleQuestChainStep[] GetRequiredSteps(); public SimpleQuestChainStep[] GetBranchGroup(string group); public string[] GetBranchGroups(); // Convenience accessors — property queries (safe, returns default if out of range) public int GetCategoryValue(int index); // Returns -1 if out of range public bool GetFlagValue(int index); // Returns false if out of range public float GetNumericValue(int index); // Returns 0 if out of range public string GetTextValue(int index); // Returns "" if out of range }

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

// Get a chain from the database var chain = chainDatabase.GetChainByCode("CIVIL_WAR"); // How many steps total? Debug.Log($"Chain has {chain.StepCount} steps"); // Get all required steps var required = chain.GetRequiredSteps(); Debug.Log($"{required.Length} steps are required"); // Discover branch points string[] branches = chain.GetBranchGroups(); foreach (var branchName in branches) { var options = chain.GetBranchGroup(branchName); Debug.Log($"Branch '{branchName}' has {options.Length} options:"); foreach (var option in options) Debug.Log($" - {option.questCode} (sortOrder: {option.sortOrder})"); } // Access dynamic properties by index int chainTypeIndex = 0; // first category int chainType = chain.GetCategoryValue(chainTypeIndex); float minLevel = chain.GetNumericValue(0); string synopsis = chain.GetTextValue(0);

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.

Tip: The Quest Dependencies window is invaluable for refactoring. Before deleting or renaming a quest code in Quest Forge, check the dependencies window to see if any chains reference it.

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.

SchemaLinkedEntry format: When quest codes appear in exported schemas (e.g., the 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.

Remember: Quest chains reference quest codes, not quest data. If you update a quest's name, description, or rewards in Quest Forge, the chain automatically picks up those changes at runtime because it looks up the quest by code. You only need to regenerate the chain database if you add, remove, or reorder steps.