The Mission Graph: How Great Adventures Are Designed, Not Improvised

The Invisible Skeleton

Every adventure has a structure. Even a playground game of make-believe has an implicit one -- there is a villain, there is a hero, and there is something the hero needs to do. The structure is what keeps the game from dissolving into random noise.

In traditional game design, this structure is called a quest graph, dependency tree, or mission flow. It is the map of what needs to happen, in what order, and under what conditions, for the adventure to progress from beginning to end. In tabletop RPGs, the dungeon master holds this structure in their head. In video games, a designer lays it out in documentation before a single line of code is written.

At Conch, we call it the mission graph, and it is the foundation of every adventure on the platform.

What Is a Mission Graph?

A mission graph is a directed acyclic graph -- a DAG, in computer science terms -- that maps the dependency relationships between every meaningful action in an adventure. Each node represents an objective: pick up a key, talk to an NPC, defeat a guardian, unlock a passage, reach the final chamber. Each edge represents a dependency: you cannot do this until you have done that.

Here is a simple example. Imagine an adventure set in a haunted mansion:

1. Find the rusty key (hidden under a loose floorboard in the library)
2. Unlock the cellar door (requires the rusty key)
3. Talk to the ghost in the cellar (only appears after the door is unlocked)
4. Learn the secret passage location (the ghost tells you, but only if you bring her a locket)
5. Find the locket (it is in the attic, guarded by a hostile spirit)
6. Defeat the spirit or sneak past it (OR gate -- either works)
7. Give the locket to the ghost (requires both finding the locket and talking to her)
8. Enter the secret passage and escape (the final objective)

Laid out as a graph, this creates a web of dependencies. Some are linear -- you cannot unlock the cellar without the key. Some are parallel -- you can explore the attic and the library in any order. Some have OR gates -- there are multiple ways to get past the spirit. And the final objective requires multiple threads to converge.

This is what gives an adventure depth. Without the graph, you are just wandering around doing random things. With it, every action has weight because it connects to something larger.

Why AI Adventures Need Structure More Than Anyone

Here is a counterintuitive truth: the more freedom you give a player, the more structure you need behind the scenes.

In a decision tree adventure (the kind most interactive fiction platforms use), the structure is the content. Every path is pre-written. The player cannot deviate because there are only a handful of options at each point. The structure is implicit in the branching tree itself.

In an AI-powered adventure, the player can do anything. They can say anything. The AI will respond. This is the freedom that makes AI adventures exciting -- but it is also what makes them fragile. Without structure, the AI is flying blind. It does not know what matters, what should be gated, or what constitutes progress. The result is a conversational experience that feels open but shallow. You can talk about anything, but nothing you do has consequences that persist.

The mission graph solves this. It tells the AI engine: here is what matters. Here are the dependencies. Here is what the player needs to accomplish. The AI is still free to improvise the narrative -- the dialogue, the descriptions, the moment-to-moment storytelling -- but it does so within a framework of real objectives that have real prerequisites.

When a player picks up the rusty key, the mission graph records that the key is now in their inventory. When they try to open the cellar door, the system checks the graph: do they have the key? If yes, the door opens and the ghost node becomes reachable. If no, the AI can narrate the locked door in a dozen creative ways -- but it will not let the player through, because the structure says they are not ready.

This is the difference between an adventure and a conversation.

The Anatomy of a Node

Every node in a Conch mission graph has a few key properties:

Action type. What kind of objective is this? The system recognizes actions like PICKUP (acquire an item), TALK_TO_NPC (engage a character), GIVE (hand over an item), USE (apply an item to something), RELOCATE (move to a location), UNLOCK_LOCATION (open a new area), NPC_DEFEATED (win a combat encounter), and GAME_END (the adventure is complete).

Target. What entity does this action involve? A specific item, NPC, or location in the adventure world. These are not abstract -- they are real entities in the game state, placed by the creator in specific scenes.

Gate type. When a node has multiple prerequisites, is it an AND gate (all must be completed) or an OR gate (any one will do)? This determines whether the player needs to complete every requirement or just one path.

Final flag. Is this the end of the adventure? The system needs to know which nodes represent completion, so it can verify that the adventure is solvable and track when a player has won.

How the Graph Gets Built

When a creator builds an adventure on Conch, they design the world: scenes connected by paths, NPCs placed in locations with their own personalities and inventories, items scattered across the map. This is done visually, with a drag-and-drop scene editor -- no coding required.

The mission graph is then generated from this world structure. An AI analyzes the adventure -- the items, the NPCs, the locations, the relationships between them -- and constructs the dependency graph. It identifies natural gating points: this NPC has a key, that door is locked, this path requires an item to proceed. The result is a graph that reflects the adventure's internal logic.

The creator can review and adjust the graph. They can add dependencies, change gate types, set which node is the final objective. But they do not have to start from scratch. The graph emerges from the world they already built.

Validation: Catching Problems Before Players Do

A mission graph is a formal structure, which means it can be formally validated. Before an adventure goes live, the system runs a series of checks:

Structural integrity. Are all node IDs unique? Are there self-loops or duplicate edges? Do all referenced entities (items, NPCs, locations) actually exist in the adventure?

No cycles. A mission graph must be acyclic -- you cannot have circular dependencies where A requires B and B requires A. If a cycle exists, the adventure is impossible.

Solvability. This is the big one. The system walks the graph from the start nodes (objectives with no prerequisites) through to the final nodes, respecting AND/OR gate semantics. If there is no path from start to finish -- if the player cannot possibly complete the adventure given the dependencies -- the system flags it.

These validations catch design errors that would otherwise only surface when a frustrated player gets stuck with no way forward. In the world of decision tree adventures, dead ends are a known problem. In Conch, the mission graph makes dead ends detectable and preventable before the adventure is published.

Why This Matters for Quality

The mission graph is ultimately a quality tool. It is the difference between an adventure that was designed and one that was thrown together.

On platforms where adventures are created by typing a text prompt and letting the AI do the rest, there is no graph. There are no dependencies. There is no validation. The AI generates the story on the fly, which means it cannot guarantee that the adventure is coherent, completable, or satisfying. Items appear and disappear on a whim. NPCs contradict themselves. There is no meaningful progression because there is nothing tracking what progress means.

The mission graph ensures that every Conch adventure has a spine. Not a rigid, linear spine -- the graph supports branching, parallel objectives, and OR gates that give players multiple paths. But a spine nonetheless. A structure that guarantees the adventure goes somewhere, that actions have consequences, and that there is a satisfying ending reachable from the beginning.

This is what separates a game from a conversation. And it is what makes the Creator Studio more than just a prompt box -- it is a world-building tool with engineering underneath.