How To Make A Good Game Setting

Abstract

Problem: How do you develop a compelling game setting β€” and how do you know when it's "done"?

Approach: Tim Cain shares a series of self-assessment questions designers should ask about their settings, drawing on decades of experience from Fallout, Arcanum, and The Outer Worlds.

Findings: A good setting must be easy to explain, support interesting non-linear stories, enable meaningful quests with reactivity, contain compelling NPCs, and feel evocative enough that players want to inhabit it. The design document format matters too β€” it should be a living, versioned, interlinked document rather than a static file.

Key insight: Don't get ego-attached to your creation. If you think everything that comes out of your head is brilliant and requires no critique, you're wrong β€” and you won't be a good designer.

Source: https://www.youtube.com/watch?v=kW7gOPHmr-Q

The Bread-Kneading Problem

Tim opens by admitting that articulating how to make a good setting was surprisingly difficult. He compares it to kneading bread β€” you reach a point where you just know it's ready, but describing the sensation to someone else is nearly impossible. Making a setting works the same way: you work on it, and at some point it just feels right. His solution is to reframe the process as a series of questions you should be able to answer well.

Kill Your Ego

Before diving into the questions, Tim emphasizes a critical mindset: don't get attached to your ideas. Designers who treat any questioning of their work as a personal attack will never improve. Everything you create needs to survive critique. If you can't handle that, you won't be a good designer.

The Questions

Can You Explain It Simply?

The first and most fundamental test: can you describe your setting briefly in a way that makes people immediately get it? The setting document is read by everyone β€” programmers, artists, publishers β€” and they need to grasp it quickly.

Tim cites The Outer Worlds' elevator pitch: "Fallout meets Firefly." That wasn't even his line β€” it came from one of Obsidian's founders β€” but it worked perfectly because it's short and instantly evocative. If you can't describe your setting briefly in a way that makes people say "I get it," your setting may be too complicated or too niche.

Can You Tell an Interesting Story In It?

A setting can be easy to understand yet support no compelling narratives. Video game stories are non-linear β€” you set up chapters, but players go through them in their own order, skip things, and do the unexpected. Your setting needs to accommodate that.

Crucially, the setting should be reactive. As the player acts, the world changes: situations shift, new events become possible, others close off. This is something only games can do β€” two people reading the same book get the same story, but two people playing Fallout get wildly different playthroughs. Tim loves that about the medium.

Does It Support Interesting Quests?

If every quest in your world is "go talk to Bob, then talk to Mary, then deliver a widget to Susan," you don't have an interesting setting. Good quests present interesting questions β€” situations to resolve that involve investigation, evidence-gathering, multiple approaches, and meaningful choices.

The player should be figuring out how they want to solve problems, not just following a linear checklist.

Does It Have Compelling NPCs?

NPCs serve multiple critical functions: they advance the story, demonstrate reactivity, and perform world-building. In The Outer Worlds, companions chattered constantly β€” to you and to each other. They'd comment on things you might not even notice, reinforcing the setting through organic dialogue.

Games without meaningful NPCs lose enormous depth. Even if your setting is fascinating on paper, it needs characters who bring it to life.

Is It Evocative?

The hardest quality to pin down. Beyond being understandable and story-rich, does your setting make players want to be there? Does it draw them in and make them want to explore?

Evocative settings are mysterious, slightly unknown, maybe a little scary. You can't force it by pointing at every interesting thing β€” players need to discover these elements themselves. Tim uses Fallout as an example: wandering through the irradiated remains of civilization, encountering mutated creatures, exploring ruins β€” there's something inherently compelling about that premise that makes people want to dig deeper.

How Mainstream Is Your Idea?

This question only matters if you care about sales, demographics, or if your publisher demands broad appeal. For Fallout and Arcanum, Tim and his team never asked this β€” they made games for each other, and those titles became "cult classics."

The Outer Worlds was different. Tim was explicitly told: "We want casual RPG players to want to play this." This doesn't mean dumbing things down. Tim's analogy: the view from a mountaintop is just as gorgeous whether you rock-climbed up or drove. You can keep full complexity in story, setting, and mechanics β€” you just lower the initial slope and front-load the more accessible elements.

He points to Roger Zelazny's Lord of Light as a model: it opens like a fantasy novel, then gradually reveals itself as science fiction exploring deep questions about identity. It doesn't front-load the complex stuff.

The Evolution of Design Documents

Tim traces how setting documentation evolved across his career:

  • Early career: No documents at all. People told you what they wanted verbally; you'd walk to someone's office if you had questions.
  • Fatherhood/Riches era: Design documents on napkins β€” literally scribbled at lunch by the producer.
  • Fallout: Things were written down, but loosely. There was no single "Fallout design document."
  • Arcanum: A thick Word document with change tracking, created because they needed to pitch to a publisher.
  • The Outer Worlds: A hierarchical, interlinked set of Confluence pages β€” the gold standard.

Why Confluence-Style Documents Win

The Outer Worlds' design documentation was a wiki-like structure: an introduction page linking down to systems, combat, melee, ranged, skills, items β€” all interconnected. A programmer assigned to implement melee combat could follow links to read about two-handed weapons, the skills that use them, the formulas involved, and the broader combat context.

Key advantages:

  • Automatic change tracking β€” you can see what changed and why
  • Living documents β€” anyone can check the current state at any time
  • Contextual links β€” every piece of information connects to related pieces
  • Institutional memory β€” when someone joins late and asks "why doesn't the setting include aliens?", you can point them to the documented decision and its reasoning

Track Your Changes

Tim strongly recommends keeping change history, for two reasons:

  1. It's interesting to look back and see how things evolved
  2. It's practical β€” when someone suggests an idea you already tried, you can show them the old version and the reasons it was changed

Closing Thought

Tim has been making game settings since before D&D β€” he made board games as a kid. The process is hard to fully articulate, but these questions serve as a reliable guide. Ask them honestly, answer them without ego, and be willing to revise. That's the path to a good setting.

References