Managing Game Expectations

Abstract

Problem: How do you ensure players understand what game they're getting before they buy it, and how do you prevent a mismatch between expectations and reality?

Approach: Tim Cain examines two games from his career β€” Temple of Elemental Evil and The Outer Worlds β€” as case studies in expectation management, one where the team failed to deliver on valid expectations, and one where they communicated clearly but players still formed their own assumptions.

Findings: Clear, consistent messaging across all channels (PR, interviews, conferences, Reddit Q&As) is essential but not sufficient. Some players will always project their own desires onto your game regardless of what you say. You must accept this reality while still doing your best to communicate honestly.

Key insight: Managing expectations is distinct from discoverability β€” it's not about people finding your game, but about ensuring they understand what they're getting. Even perfect communication won't reach everyone, but that doesn't absolve you from trying.

The Problem Defined

Tim distinguishes this topic from two related ones he's covered previously: discoverability (people finding out your game exists) and team vision (keeping your development team aligned via design pillars and good direction). Managing game expectations sits in between β€” once someone discovers your game, how do you let them know what kind of game they're actually getting?

The core issue: when there's a disparity between what players think they're getting and what they actually get, they become upset β€” and they take it out on their reviews. A perfectly decent game can get savaged because players expected something different.

Case Study: Temple of Elemental Evil (Failure)

Tim presents ToEE as a case where the team tried to do too much with too little, and players had valid expectations that went unmet.

The Constraints

  • Low budget with an original timeline of just 18 months
  • Very small team β€” about a dozen people, with some part-timers brought on for specific tasks
  • Mid-development, they discovered WotC was switching from D&D 3.0 to D&D 3.5 β€” a change that Atari and WotC knew about but Troika didn't
  • Tim asked for 3 extra months to accommodate the rules change; Atari negotiated it down to 2
  • Tim suffered a kidney stone that lasted four months, severely impacting his work and oversight while on strong pain medication
  • Leonard Boyarsky and Jason Anderson were busy on Vampire: The Masquerade β€” Bloodlines, so Tim lacked their expertise in storytelling, narrative design, and technical art

The Result

Players didn't care about any of those explanations. They cared that the game had a bad story, bad encounter design, and was really buggy. Tim is clear: "It's not an excuse β€” I'm explaining what happened." The team tried to do too much with too little time and money, and that was their fault. Players had valid expectations of a game based on one of the most famous AD&D modules written by Gary Gygax himself, and those expectations were not met.

There was no real way to "manage expectations" out of those fundamental quality problems.

Case Study: The Outer Worlds (Partial Success)

Tim presents The Outer Worlds as the opposite scenario β€” a case where the team actively tried to manage expectations but still faced player disappointment.

What They Communicated

The team was explicit in every interview about the game's scope and limitations:

  • Marketed as "from the creators of Fallout New Vegas"
  • Repeatedly stated it had a much lower budget than most AAA games
  • It was Obsidian's first game using Unreal Engine, requiring significant learning time
  • Many new hires (narrative designers, programmers) since existing staff were on other projects
  • Explicitly stated it was about a 20-hour game

What Players Expected Anyway

Despite all this communication, many players expected Fallout New Vegas in scope β€” the same length, same mechanical depth, same everything, just in a different setting. When the shipped game was shorter than they wanted, they complained. Some accused the developers of "tricking" people β€” a claim Tim finds baffling given that the game continued selling well for five years.

The game itself was tight, well-crafted, and very bug-free by Obsidian standards. But the expectation gap still caused backlash.

Tim's Advice for Developers

Be Clear and Consistent

  • State the basics explicitly: genre, setting, story type, expected playtime, replayability
  • Read your own PR statements carefully β€” make sure they say exactly what you mean and don't imply things you won't deliver
  • Say the same things everywhere: PR releases, journalist interviews, conferences, Reddit Q&As β€” the message should be consistent
  • Don't promise what you can't deliver. Don't imply features just because it makes the game sound better

Be Specific with Comparisons

If you compare your game to another game, say exactly why you're making the comparison. Saying "we're a lot like Half-Life" could lead people to expect an action shooter, an 80-hour game, or the Source engine. Be specific: maybe the comparison is about open-world design, or humor style, or setting β€” but spell it out.

Accept the Limits

Even with perfect communication, some players will still think what they want to think. You can show clips, do dozens of interviews, state everything clearly β€” and some people's minds won't change. They'll form their own expectations, and when those aren't met, they'll complain online.

This has happened on every game Tim has ever shipped. The goal isn't to eliminate the problem β€” it's to minimize it through honest, clear, consistent messaging, and then accept that some gap will always remain.

Source

Tim Cain β€” "Managing Game Expectations" (YouTube)