Gameplay's Influence On Story

tim-cain narrative-design quest-design rpg player-agency game-design

Abstract

Problem: How much does gameplay influence what stories can be told in video games, and how do developers handle the tension between a story that wants to go a certain way and gameplay that needs to stay fun?

Approach: Tim Cain draws on his experience directing RPGs like The Outer Worlds and Fallout to explain how narrative designers should think about quest structure differently from linear media writers.

Findings: Stories in RPGs should be built around player goals, not player actions. Designers should provide objectives and let players find their own path, with systemic fallbacks for unexpected player behavior. Tracking player choices and reflecting them in end slides adds massive replayability.

Key insight: Design quests as goal-based rather than event-based — tell the player what needs to happen, never how to do it, and let the story unfold from their choices.

Source: https://www.youtube.com/watch?v=fzUzRqmgJKE

The Problem With Linear Thinking

Tim identifies a core challenge: most narrative designers come from writing for books, movies, or TV — all linear media. They instinctively plan stories as sequences of specific player actions: "the player goes here, the player does this." Tim's immediate response in meetings is always: what if the player goes somewhere else? What if they don't go there at all?

He's had narrative designers respond with "we will force them to go there and lock them in that space until they do the thing we want." Tim's verdict: that does not sound fun.

Goals Over Actions

Tim's core principle: don't think of your story based on player action — make it based on player goals.

Instead of telling the player "go to the goblin cave and get this item," just tell them "I need this item." If it's not unique, the player might buy it, craft it, or find it some other way. The quest-giver doesn't care how — they just want the item.

Similarly, for a rescue quest: don't say "go to this cave, kill the goblins, rescue the merchant." Just say "this merchant got kidnapped — rescue him." This opens up discovery (who kidnapped him? where are they?) and multiple solutions (negotiate, bribe, fight, do a favor for the captors). The quest-giver only cares that you come back with the merchant.

This is why Tim hates the phrase "story-driven game." For The Outer Worlds, he insisted on calling it a player-driven story. "Stories don't act. Players act."

Design Fallbacks for Everything

If you embrace player freedom, you need fallbacks. What happens when the quest item gets lost or sold? Is the quest failed? Can it be recovered?

Some approaches:

  • System-level prevention — Mark quest items as unsellable/indestructible. Simple but limiting.
  • Essential NPCs — Mark key characters as unkillable. Tim dislikes this and knows players do too.
  • Alternate resolutions — Tim's preferred approach. If the merchant dies, maybe there's an end slide about his death. Maybe his unique inventory is gone forever. The game reacts to what happened rather than preventing it.

Players love when the game reacts to their actual choices rather than forcing everyone through the same scripted experience.

Keep Solutions Systemic

Multiple quest solutions can quickly spiral out of control. Tim's advice: keep solutions systemic rather than hand-scripted.

  • If an item is already craftable, you already have a system for obtaining it — no extra work needed.
  • If it drops from enemies in the area, just add it to the loot table.
  • Unique scripted solutions (special dialogue, custom quest branches) require hand-scripting, which is expensive to create, debug, and maintain.

A practical constraint: dialogue gets localized into other languages early and gets locked. If your quest solution depends on unique dialogue, you need to find those bugs early — another reason to favor systemic solutions.

Railroading Kills RPGs

Stories that force the player to do one thing, go one way, and solve it one particular way make players feel railroaded. In an RPG — where you're telling players they can create a character and play however they want — this is especially damaging.

A pacifist player forced to kill every goblin to complete a main quest feels terrible. Side quests can get away with fewer options (players can just skip them), but main quests need multiple paths.

Track Choices, Reflect Them Later

Beyond just allowing multiple solutions, Tim advocates tracking what players do and reflecting it later:

  • Set flags when the player makes choices
  • Have NPCs reference those flags in later dialogue
  • Change end slides based on accumulated decisions

This accomplishes two things: it tells the player "the game is really watching me" and adds enormous replayability. Players finish and immediately want to replay to see what changes — "this time I'll save that merchant" or "this time I won't sell that quest item."

The Bottom Line

Set up situations with multiple ways through them. Tell the player a goal. Let events unfold. Make stories goal-based, not event-based. That's role-playing games.

References