Quest Dependency Tracking: Managing Prerequisites in Complex Campaigns

What Quest Dependencies Are and Why They Matter

A quest dependency exists when one quest cannot be started or completed without progress from another quest. The dungeon door requires a key found in a different dungeon. The NPC with critical information will only talk to the players after they have proven themselves by completing a task. The final ritual requires ingredients gathered from three separate quests.

Dependencies are everywhere in complex campaigns, and they serve important functions:

• They create progression — players must build toward goals step by step
• They reward thoroughness — players who explore broadly have more options
• They create meaningful sequencing — the order of events matters
• They generate backtracking hooks — reasons to revisit locations or NPCs

But untracked dependencies create some of the most frustrating player experiences in tabletop gaming. A player reaches the locked door and the GM cannot remember where the key is. The players complete three quests to gather ritual components and the GM realizes they missed a fourth requirement. The NPC demands the players prove themselves but the proving quest was never actually designed.

Mapping Dependency Chains

The first step is making dependencies visible. For each active quest in your campaign, identify:

• Prerequisites — What must be true before this quest can be started?
• Requirements — What must be obtained or accomplished during this quest?
• Unlocks — What does completing this quest make available?

Then draw the dependencies:

[Find the Map] → [Locate the Tomb] → [Retrieve the Crown]
                                    ↗
[Recruit the Sage] → [Decode the Wards]

In this example, retrieving the crown requires both locating the tomb AND decoding the wards. Locating the tomb requires finding the map. Decoding the wards requires recruiting the sage. The players have two parallel tracks they need to advance.

Types of Dependencies

Hard dependencies — Quest B literally cannot happen without Quest A. The locked door cannot be opened without the key. The ritual cannot be performed without the component. These are binary: either the prerequisite is met or it is not.

Soft dependencies — Quest B is significantly easier or more rewarding with Quest A completed, but it is not impossible without it. The NPC is more cooperative after the players' reputation improves. The dungeon is more dangerous without the protective amulet from the earlier quest.

Information dependencies — Quest B requires knowledge gained from Quest A. The players need to learn the location of the hidden fortress. They need to discover the villain's weakness. They need to understand the political landscape before they can navigate the negotiation.

Resource dependencies — Quest B requires resources (items, allies, funds) acquired through earlier quests. The siege requires an army the players must recruit. The magical weapon requires components gathered from multiple locations.

Timing dependencies — Quest B must happen before or after a specific event, which may be triggered by Quest A. The ritual must be performed during the eclipse. The assassination must happen before the coronation.

Building a Dependency Tracker

A practical dependency tracker needs three components:

The dependency diagram — A visual map showing which quests depend on which other quests. This is your at-a-glance reference for understanding the quest structure.

The status overlay — For each node in the diagram, track its current status:

• Locked — Prerequisites not met
• Available — Prerequisites met, players have not started
• In progress — Players are actively working on this
• Completed — Done, unlocks are available
• Failed — Players failed this quest, dependency chain is affected

The prerequisite checklist — For quests with multiple prerequisites, maintain a checklist showing which have been satisfied. When all boxes are checked, the quest unlocks.

Designing Player-Friendly Dependencies

Dependencies should create satisfying progression, not frustrating gates. Follow these design principles:

Multiple paths to prerequisites. Do not design a dependency where only one specific action satisfies the prerequisite. If the players need to gain the duke's trust, there should be multiple ways to do so — completing his quest, bringing him valuable information, having an ally vouch for them, or discovering leverage.

Telegraph dependencies clearly. Players should know what they need before they need it. "The ritual requires moonstone, dragonfire ash, and the blood of a willing celestial" tells the players exactly what to pursue. Springing a previously unknown requirement at the climax is frustrating.

Avoid deep chains. A dependency chain that is five or six links deep becomes tedious. Players lose track of why they are doing Quest E and how it connects to their actual goal. Keep chains to three or four links maximum, with the connection to the ultimate goal visible at every step.

Provide parallel paths. When a quest has multiple prerequisites, let the players pursue them in any order. Do not force a specific sequence unless the narrative demands it.

Have fallbacks for failed dependencies. If a quest in the chain fails — the artifact is destroyed, the NPC is killed — the dependency chain needs an alternative route. The artifact has a lesser counterpart. Another NPC has partial knowledge. The ritual can be modified with a higher cost.

Tracking Dependencies During Play

Before each session: Check your dependency diagram. Are any quests about to unlock? Are the players pursuing a quest whose prerequisites they have not met? Do you need to telegraph an upcoming dependency?

During play: When players complete a quest or satisfy a prerequisite, mentally check the dependency diagram. Does this unlock anything? If a new quest becomes available, create an opportunity for the players to discover it naturally.

After each session: Update the status overlay. Mark completed quests, update prerequisites, and check for any dependency chains that have been broken by player actions.

When Dependencies Break

Players will break your dependency chains. They will find the locked door before the key. They will skip the introductory quest and go straight to the advanced one. They will kill the NPC who was supposed to give them critical information.

When this happens:

• Adapt the dependency. If the players reach the locked door without the key, maybe there is another way in — a skill challenge, a destructive approach, a secret passage. Do not invalidate their exploration just because they did not follow your planned order.
• Relocate the prerequisite. If the players skip Quest A and go to Quest B, put the prerequisite information or item somewhere in Quest B. They still need it, but they find it in a different context.
• Rewrite the chain. If a key dependency link is permanently broken, redesign the remaining chain. The original plan was never sacred — only the current state of the campaign matters.

Want to visualize your campaign's quest dependencies as a clear, navigable map? Join the TransitMap waitlist — see every quest, prerequisite, and unlock mapped as interconnected transit routes where dependencies are visible at every junction.