Design Potholes

tim-cain game-design design-pitfalls design-pillars design-documents narrative-design

Abstract

Problem: Game designers repeatedly fall into the same common design traps — what Tim Cain calls "design potholes" — that damage projects and can be avoided with awareness.

Approach: Tim identifies several recurring potholes from decades of professional experience reviewing design documents and shipping games like Fallout and Arcanum, illustrating each with stories and examples.

Findings: The major design potholes are: including too much in your game, dictating player actions in design docs, declaring player emotions without specifying mechanisms, and lacking clear design pillars. All share a root cause: not asking "why am I adding this?"

Key insight: Every element in a game — every mechanic, NPC, quest, and feature — must serve a clearly stated design goal. If you can't articulate why something exists, it shouldn't be there.

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

The Pothole Metaphor

Tim Cain defines "design potholes" as common design issues that can be avoided if you know to look for them. Like real potholes on a road: if you're going slowly, they won't hurt much, but at speed they can wreck your project. Once you've been down the road a few times and know where the potholes are, you can navigate around them. These potholes appear across all lanes of design — system design, narrative design, and level design.

Pothole 1: Including Too Much

The first and most common pothole is putting too much into your game. As a wise designer once told Tim: "A game that includes everything is about nothing."

This applies to every aspect of design:

  • Lore bloat: Wanting aliens AND supernatural elements AND psychic powers AND magic AND a noir murder mystery all in one game. While rare exceptions like X-Files pull this off, most games suffer from lack of focus when they try to include everything
  • Mechanic checklists: Adding crafting, item degradation, and base building not because they serve the game, but because "someone from marketing said everybody's doing this." Features added from a checklist rather than from intentional design create unfocused games
  • The core question: Always ask "why am I adding this?" Everything should be added for a reason — and "because I think it's neat" isn't a good enough reason

Pothole 2: Dictating Player Actions

Tim frequently encounters design documents that say "and then the player does X." This is a red flag. Unless you're making an extraordinarily linear narrative adventure game, you cannot dictate what the player does — you can only set up conditions and respond to choices.

The correct framing is: "If the player does this, then this will happen."

Tim tells a story of a designer who, when challenged on this, responded: "I will lock the player in a room and they can't leave until they do that thing." Tim's sarcastic response — "Wow, that sounds super fun" — drove home the point: games should be fun, and trapping players to force a specific action is terrible design. When the designer countered with "what about puzzle games with timed rooms filling with water?" Tim's reply was sharp: "Are we making a puzzle game? Is that your intent?" — circling back to the fundamental question of knowing your design goals.

Pothole 3: Declaring Player Emotions

Another pothole Tim sees in design documents: statements like "this will make the player feel X" or "this area feels Y."

Tim's response is always: "Don't tell me how the player feels. Tell me what you will show."

  • What art are you presenting?
  • What will the NPCs say?
  • What specific mechanisms will induce that feeling?

Stating a goal like "this area should make the player feel uneasy" is acceptable, but only as a starting point — you must then specify the concrete details of how you'll achieve it. Saying "this area is crazy, it makes a player feel nuts" without describing the crazy art, the crazy NPC dialogue, or the specific environmental storytelling is what Tim calls "say and not do."

Why Specificity Matters

Being forced to describe concrete implementations rather than vague intentions reveals practical production needs:

  • The art director may discover the required art style doesn't match the game's visual direction
  • The narrative designers may find their dialogue system doesn't support what's being proposed
  • The programmers may realize new systems are needed

Vague emotional descriptions hide these dependencies. Concrete descriptions expose them early, when they can still be addressed.

The Root Cure: Design Pillars

Tim argues that most design potholes can be avoided by establishing clear design pillars — a small number of core goals that define what your game is trying to be.

Once you've set your pillars, everything else should flow from them:

  • Does the setting support this goal?
  • Does the story advance these pillars?
  • Does each mechanic serve at least one stated goal?
  • Why does this NPC exist? What is this quest for? Why is this feature in the game?

Tim references his own games: Fallout had three acts, Arcanum had 27 — "a good number is somewhere in the middle." But regardless of structure, every element from "pickpocketing to antimatter grenades to hidden caches of treasure" should ultimately serve one of the design goals.

The warning: don't have too many pillars, or you fall right back into pothole number one — including too much. Keep them focused, keep them few, and let them guide every design decision.

References