A playtester takes your quest, walks 400 metres, picks up three mushrooms, walks back, and hands them over. They do it. They don't complain. Then, in the post-session interview, they can't remember what the quest was about — or who gave it to them.
That quest wasn't broken. It was completed exactly as designed. It just didn't do anything: it added no knowledge, no capability, no relationship, and no pressure. It moved a counter. Most weak quests in indie games aren't badly written; they're structurally empty, and you can catch that on paper long before anyone builds the mushroom.
Here's a way to design objectives so that emptiness shows up in the document, not in the playtest.
Every objective should change one of four things
Before you write a line of quest text, decide what state the player is in after it that they weren't in before. There are only four useful answers:
- Capability — they can now do something new: a tool, a traversal move, a spell, an unlocked shortcut, a party member.
- Knowledge — they now understand something: who runs the smuggling ring, that fire melts the ice walls, that the friendly NPC has been lying.
- Access — a space, vendor, faction, or system is now open to them.
- Standing — their relationship with a person, faction, or the world has shifted measurably.
The mushroom quest changes none of these. Give it one — say the herbalist now teaches you to brew a cure (capability) and mentions the mine has been flooded since the fire (knowledge) — and the same walk suddenly has a reason to exist.
A practical rule: every quest changes at least one, and your main-path quests should change at least two. Side content can be single-purpose; the critical path can't afford to be.
The five-beat spine
Most quests that feel good share a shape. The Witcher 3's monster contracts are the clearest teaching example: you take the contract, question witnesses, read the tracks with Witcher Senses, prepare the right oil and bomb, then fight a monster whose weakness you deduced. Four different verbs, one continuous thread.
Generalised, that's five beats:
- Hook — why now? Someone is in trouble, something is about to be lost, or the player is curious.
- Approach — the player chooses how to engage. If there's no choice here, you have a corridor, not a quest.
- Complication — the situation is not what the hook claimed. The victim is the culprit; the monster is protecting a nest; the door needs a key you already sold.
- Resolution — the player acts on the complication, ideally with the capability or knowledge the quest itself surfaced.
- Consequence — the world acknowledges what happened. An NPC reacts, a price changes, a door stays open, a location's state flips.
You don't need all five in every quest. But you should know which ones you dropped and why. A fetch quest with a strong complication is fine. A fetch quest with none of beats 2–5 is a counter.
Write the spine as five bullet points before writing dialogue. If you can't fill beat 3 or beat 5, that's the quest telling you it isn't ready.
Budget your quest types
Small teams get in trouble by designing every quest as a bespoke set piece, then cutting 60% of them at milestone panic time. Decide your mix up front and hold yourself to it.
| Type | Build cost | What it's for | Suggested share |
|---|---|---|---|
| Set piece | Very high — bespoke scripting, unique space, custom art | Act climaxes, first hour, demo beat | 5–10% |
| Authored side quest | High — new dialogue, 1–2 unique states | Character depth, optional systems teaching | 20–25% |
| Systemic quest | Medium — reuses existing encounters, new framing | Bulk of optional content | 40–50% |
| Template / repeatable | Low — parameterised generator | Long-tail activity, economy sinks | 20–30% |
Skyrim's radiant quests are the canonical template layer: the same structure re-pointed at a new dungeon and a new target. They work because the game has enough hand-authored content around them that the templates read as texture rather than substance. If your template quests outnumber your authored ones three to one, players will notice the seams by hour four.
For a two-person team shipping a 6-hour game, a realistic target is roughly 3 set pieces, 8 authored side quests, 15 systemic ones, and one template family with 10 instances. That's 36 objectives — write them as a single list before building any of them, and you'll see the shape of your content problem immediately.
Gate on knowledge, not just on flags
The strongest objective design trick available to small teams costs almost nothing to build: gate progress on what the player knows rather than on what the save file records.
Outer Wilds is the purest version — the ship log tracks what you've learned, and nothing is locked except by your own understanding. You can do the ending on your first loop if you somehow know how. Most games can't go that far, but partial versions are cheap:
- A vault code written on a wall in another region, which the player can type in whenever they find it.
- An NPC who answers differently once you've read a specific letter — no quest flag, just a dialogue condition on an item in your inventory.
- A boss that dies faster if you noticed its tell during a scripted earlier appearance.
Knowledge gates make your world feel continuous, and they let you reward attention without building new content. The cost is documentation discipline: you have to record which piece of knowledge lives where, or you'll gate something behind a note you later cut.
This is exactly the kind of dependency that rots in a spreadsheet. If you're tracking objectives in GameDesignerX, put the prerequisite knowledge in the objective's description and link it to the location or item that carries it, so cutting that item surfaces the broken gate instead of hiding it.
The objective review checklist
Run every quest through this before it enters the build. Anything with three or more "no" answers goes back to the document.
- Does it change capability, knowledge, access, or standing? Which?
- Can the player see or guess the reward before committing?
- Is there more than one approach, or at least more than one order of operations?
- Does the complication arrive before the halfway point?
- Does any NPC or world state acknowledge it afterwards?
- What's the failure state — and is failing more interesting than a reload?
- Can it be completed out of order, and does that break anything?
- What does it cost to build, in the same units as the rest of your backlog?
- If you cut it tomorrow, what else breaks?
That last question is the one teams skip, and it's the one that hurts at milestone time. An objective that unlocks a shortcut used by three later quests isn't a side quest — it's critical path wearing a disguise. Map those dependencies while the content is still cheap to move.
Start with the list, not the quest
The highest-leverage half hour in objective design is writing all of your quests as one-line summaries in a single list, with their type, their beat-3 complication, and what state they change. No dialogue, no names, no scripting.
You'll immediately see the three quests that are the same quest, the act with no set piece, the systems nothing teaches, and the NPC who hands out five errands in a row. Fixing those in a list takes an afternoon. Fixing them in Unreal takes a month.
Then build the three that survive the checklist most convincingly, put them in front of a tester, and ask the only question that matters afterwards: what do you know now that you didn't know before? If they can answer, the quest did its job.