Quest Design for Narrative Designers: Goals, Stakes and Structure

A quest is a short story the player performs instead of reads. It has a character who wants something, an obstacle, a turn and an ending, but the player is the one walking to the location, making the decision and living with the result. That makes quest design a strange mix of story craft and systems thinking: you are writing motive and stakes, and you are also defining states, triggers and failure conditions that a level designer and a programmer will build.

This guide breaks a quest into its parts, looks at the common types, and walks through a worked example from pitch to design doc entry.

The anatomy of a quest

Most quests, from a one-line side errand to a main story chapter, can be described with the same seven parts.

Giver. The character, object or event that offers the quest. A giver with a clear want and a distinct voice makes the whole quest more memorable.
Hook. The reason the player should care right now. Curiosity, sympathy, money, danger or a mystery. The hook is a promise about what kind of experience follows.
Objective. What the player has to do, stated clearly enough to act on. "Find out who poisoned the well" is an objective. "Help the village" is not.
Obstacles. What stands between the player and the objective: enemies, locks, puzzles, social resistance, time, a moral cost.
Twist. A complication or reveal that changes the meaning of the objective. Not every quest needs one, but quests that have one are the ones players talk about.
Resolution. How the situation ends, and ideally a choice about how it ends.
Reward. What the player gets: items, experience, reputation, access to new areas, a companion, or simply an answer.

If you can fill in all seven in a sentence each, you have a quest. If one is blank, you know where to work.

Main quests and side quests

Main quests carry the central plot. They usually cannot be skipped, they move the world state forward, and they often gate access to new regions. Their stakes should escalate, and they need to work for every player regardless of the choices made in side content.

Side quests have more freedom. They can be smaller, stranger, funnier or sadder than the main line. Their job is usually one of these:

Reveal a part of the world or a faction the main plot only touches.
Develop a companion or a recurring character.
Echo the main theme from a different angle.
Reward exploration of a particular area.

A useful test for a side quest: if the player skips it, do they lose something that the world felt richer for? If not, the quest is filler and needs either a sharper hook or a cut.

The fetch quest problem

"Bring me ten wolf pelts" has a bad reputation because the structure is pure mechanics. But fetching is simply the most common verb in games. Players fetch in almost every quest. The problem is not fetching. It is fetching without motive.

To motivate a fetch quest:

Make the want specific. Not "pelts" but "a pelt from the white wolf that took my brother's dog."
Let the object tell a story. The item can carry a note, a name or damage that hints at what happened.
Add a complication at the destination. The thing is not where it should be, or someone else wants it, or it is guarded by someone sympathetic.
Give the return a decision. The player learns something on the way that makes handing it over questionable.

The structure stays "go there, get it, bring it back," but the experience becomes a story with a turn.

Quest chains and states

Quests rarely live alone. A chain links several quests so that finishing one opens the next, and branching chains let the outcome of one quest change which follow-up appears.

Under every quest is a state machine. A typical minimal set of states looks like this:

Unavailable: prerequisites not met.
Available: the giver will offer it.
Active: accepted, with a current stage.
Completed: resolved, possibly with an outcome tag (spared, killed, betrayed).
Failed: the quest can no longer be completed as intended.

Stages inside the active state are where most of the design work lives. Each stage needs a clear trigger to enter it, a clear condition to leave it and the journal text the player sees while in it. When quests connect to dialogue, the flags that conversations set and read should line up with these stages. The companion post on writing branching dialogue for games covers how flags and bottlenecks keep conversations in step with quest progress.

Tying quests to levels and the world

A quest that could happen anywhere usually feels like it happens nowhere. Ground each quest in a specific place and let the place shape the obstacles: a flooded mine, a crowded market where a fight would draw guards, a manor with locked wings.

Work with level design early. Share the quest's stages and ask what the space can offer: a vantage point that reveals the twist, a shortcut the player earns, environmental details that foreshadow the ending. Quests also work best when they draw on the world's history and factions, so a strong world bible pays off directly here; the worldbuilding guide for fantasy authors is a good starting point even for non-fantasy settings.

Reference material helps the whole team picture the same place. Keeping mood boards, maps and concept sketches attached to each location is covered in organizing concept art and references for a story world.

Failure states

Decide deliberately how a quest can fail, and whether failure is an ending or a branch.

Hard failure ends the quest: the person you were escorting dies, the timer runs out. Use sparingly and make the cause clear.
Soft failure changes the outcome but keeps the story going: you lose the evidence, so the trial goes differently. Soft failure often makes better stories, because the world reacts instead of resetting.
Silent failure is when a quest becomes impossible without the game noticing, such as killing a giver before the player has spoken to them. Hunt these down in testing and either handle them or prevent them.

Journal text

The quest journal is where a lot of players reread the story. Good journal text:

States the current objective in one plain sentence near the top.
Summarizes what happened so far from the player character's point of view.
Updates at every stage, rather than piling new paragraphs under old ones the player has to skim past.
Matches the tone of the quest. A grim quest should not have a chirpy log.
Never reveals a twist before the player has experienced it.

Write journal text at the same time as the stages, not at the end of production. It is a quick way to check that each stage has a clear purpose.

A worked example: "The Lamplighter's Debt"

Here is an invented side quest for a harbor town, written stage by stage.

Giver: Oriel, an old lamplighter. Hook: the harbor lamps have gone dark three nights running and a fishing boat ran aground. Objective: find out why the lamps are failing.

Stage 10, Talk to Oriel. She says the oil delivered from the warehouse is watered down. Journal: "Oriel believes someone is diluting the lamp oil. Visit the harbor warehouse."
Stage 20, Inspect the warehouse. The player finds the barrels and a tally sheet signed by the warehouse clerk, Benn. Journal: "The oil was diluted inside the warehouse. Benn, the clerk, signed for every barrel."
Stage 30, Confront Benn. Benn admits it, but the twist lands: he is selling the good oil to pay off a debt to smugglers who use the dark harbor to land cargo. Journal: "Benn has been selling the oil to pay smugglers. The dark harbor is no accident."
Stage 40, Decide. The player can turn Benn over to the harbor watch, pay his debt, or follow him to the smugglers' drop at night.
Stage 50, Resolution. Each choice sets an outcome tag. Turning him in restores the lamps quickly but Oriel loses her only apprentice candidate. Paying the debt costs gold and leaves the smugglers active. Following him leads to a fight at the drop and opens a follow-up quest.
Reward. Gold or reputation with the watch, and in every branch Oriel's thanks, voiced differently depending on the outcome.

Failure: if the player ignores the quest for too long, a second boat runs aground and Oriel's dialogue changes. This is a soft failure: the quest continues, but the cost is now visible in the world.

Documenting quests in a design doc

A quest entry in the design document should let anyone on the team understand the quest without asking the writer. A practical template:

Name and ID, plus quest type (main, side, chain).
Summary in two or three sentences.
Prerequisites and where the quest is offered.
Stages, each with its ID, trigger, completion condition, journal text and the locations involved.
Flags set and read, with names matching the dialogue.
Outcomes and what each changes in the world.
Failure conditions and how each is handled.
Rewards.
Dependencies: characters, levels, items and assets the quest needs.
Open questions for design, level and audio.

Keep the entry updated as the quest changes. An out-of-date quest doc is worse than none, because people trust it.

Doing this in Aevon

Aevon's Game Studio brings the design document, quests, branching dialogue trees and levels into one project, so the quest entry, the conversation that starts it and the level where it plays out can all be kept together. Characters such as Oriel and Benn, the harbor as a location, and items like the tally sheet can have their own entries, and the manuscript editor's @mentions link them wherever you write about them.

The asset library stores concept art, reference images, 3D models, audio and documents per project, which is useful for keeping the harbor's mood board and any model assets next to the quest. Story diagrams are available for every project type, so you can map quest chains and how outcomes feed into later quests visually. Timelines and the Ideas and Notes panel, which stays open across sections, help track what the world looks like after each outcome.

For teams, roles (owner, editor, viewer) and change approval let a lead designer review edits before they land, which helps keep the quest doc trustworthy. You can start a project in the Game Studio for free, in the browser or the desktop apps.