Botched Quests And Player Freedom

1. The Six Quest States

When developing Arcanum, Tim Cain designed a quest system with six states:

1. Unknown — The player has never heard of the quest; it likely doesn't appear in the quest log
2. Mentioned — The player has heard about the quest (e.g., "there are bandits in the area") but hasn't agreed to do anything about it
3. Accepted — The player has told the quest giver they'll take the job
4. Achieved — The player has done what was required (rescued the person, killed the bandit leader) but hasn't turned it in yet
5. Completed — The quest is turned in, reward received, done
6. Botched — A special flag (not truly a sixth state) that can be applied to any state except Completed

The key design insight: botched is implemented as a flag, not a terminal state. It can be turned on and off. When the botch flag is removed, the quest reverts to whatever state it was in before. This is the crucial difference between "botched" and "failed."

2. Why "Botched" Instead of "Failed"

Tim deliberately chose the word "botched" over "failed" because failure implies permanence — it's done, you can't do anything about it. Botched implies something that went wrong but might be fixable. The paired concept of "unbotch" makes this explicit: you can recover from a botch.

A completed quest can never be botched — once you've rescued the shopkeeper and turned in the quest, it doesn't matter if the shopkeeper dies later. You're done.

3. Two Games That Got It Wrong

Tim describes two 1990s games that frustrated him as both a player and a designer:

3.1. Ultima Underworld

Tim was trying to hand a main story quest item to an NPC. The NPC was standing in front of a lava field. Due to the UI design (clicking on an NPC gives the item, clicking near them throws it), Tim misclicked while the NPC was animating. The item was thrown into the lava — either destroyed or completely unretrievable since touching lava meant instant death. The quest became uncompletable, the game couldn't be finished, and his last save was far back.

3.2. Baldur's Gate

A quest required rescuing a farmer's missing child. The farmer said the kid went missing three days ago. No matter what the player did, the child was always found dead. Tim had a Raise Dead scroll and a cleric who could cast it — and critically, Raise Dead works on anyone dead up to nine days in D&D rules. The child had only been dead three days. But the game marked the child as an "invalid target." The designers overrode their own game's rules to force a predetermined outcome.

4. The Industry's Wrong Solution

After experiences like these, the industry trend wasn't to allow quests to fail gracefully — it was to prevent failure entirely:

• Quest items were marked undropable and unsellable, so the only way to get rid of them was turning them in
• Essential NPCs were marked unkillable — they might fall down when reduced to zero health, but they'd always stand back up

Tim argues this approach severely limits player freedom and agency. The game has already decided the one way a quest ends, and the player must follow that exact path.

5. The Better Way: Botch and Unbotch

Tim's preferred approach allows quests to fail — but provides players with tools to recover:

5.1. If an NPC Dies

• Raise them from the dead using scrolls, potions, or spells
• Speak with Dead (a spell Arcanum included specifically for this reason) — if someone with vital information is killed, you can still talk to their corpse to get the information, assuming you have the speech skills
• Find the information elsewhere — maybe it's in their locked safe

5.2. If a Quest Item Is Lost or Destroyed

• Go buy it back from whoever you sold it to (the shopkeeper won't flush quest items from inventory, and will charge you more than they paid — they're a shopkeeper after all)
• Find another one — if the item isn't completely unique, bring back an equivalent
• Craft one — if the quest giver wants a Wand of Fireballs, maybe you can craft one yourself
• Forge one — if the quest giver specifically wants "Joe's Wand of Fireballs" (it says "Made by Joe" on it), maybe you can forge a convincing copy using a forgery skill

6. Crafting as Quest Solution

Tim is especially enthusiastic about how botched quests create opportunities for crafting to become meaningful in the narrative. Instead of crafting existing solely for XP or making potions the player never uses, it becomes a potential quest solution:

• Quest giver wants a specific item? Craft it instead of retrieving it from a dragon's cave
• Need rare materials for the forgery? That becomes its own mini-adventure — exploring, possibly combat, possibly dialogue
• Don't feel like fighting the dragon guarding the original item? Use crafting as an alternative path

This ties game systems together in satisfying ways: crafting, dialogue (speech checks to convince quest givers to accept substitutes), exploration, and combat all become interconnected.

7. The Core Argument

Tim's central thesis: botching and unbotching quests, by its very nature, adds to player-directed storytelling and increases player agency and freedom. The ability to fail — and then recover through creative use of game systems — puts more decision-making in the player's hands than a system that simply prevents failure from ever occurring.

He wishes more games would adopt this approach.

8. References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=2yUMsMuq1-w