Gameplay Options

tim-cain system-design game-options difficulty player-choice testing ux

Abstract

Problem: How many gameplay options should a game offer, and what are the hidden costs of extensive customization?

Approach: Tim Cain revisits his earlier video on difficulty settings, responding to community discussion about gameplay options more broadly. He presents three major arguments against offering too many options, drawn from player comments and fellow developers.

Findings: Excessive gameplay options create compounding QA costs, trigger choice paralysis in players, and can signal indecision from the game director. The sweet spot lies between too many and too few.

Key insight: Every gameplay option multiplies your test matrix, fragments your player base, and may not actually improve anyone's experience — think carefully before committing to them.

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

1. Context

This video is a follow-up to Tim's earlier video on difficulty settings. The comment section on that video sparked a broader discussion about gameplay options in general — not just difficulty, but all the knobs and switches a game exposes to players. Tim distills the conversation into three main arguments against having too many options.

He explicitly excludes accessibility options (colorblind modes, subtitles, font sizes, input remapping, gamma correction) from the discussion. Those serve a different purpose — enabling people to play the game at all. This video is strictly about options that change how the game plays.

2. Argument 1: The Testing Nightmare

Every gameplay option must be tested, and every combination of options must be verified as viable — meaning all player builds can still complete the game under that configuration.

2.1. The Quest Marker Example

If your game has a toggle for quest markers, your narrative and level designers may have written NPC dialogue assuming markers exist. An NPC who says "Bob stole it — he's hiding in Shadow Cave" gives you nothing to work with if markers are off. Contrast that with: "The cave is on the south face of the cone-shaped mountain." If designers built for one setting, the other setting breaks.

2.2. Combinatorial Explosion

Testing every player build against every combination of gameplay options makes the test plan grow geometrically or exponentially. This directly translates to time and money. Worse, you might spend 50% of your testing budget on option combinations used by less than 2% of your player base.

2.3. Metrics Fragmentation

More options means more combinations, which splinters your player base into smaller groups. Some rare combinations may require disproportionate testing effort despite minimal usage — a fact that, as Tim notes, "will drive any of the production people on your development staff crazy."

3. Argument 2: Players React Badly to Too Many Choices

This was the argument that surprised Tim the most.

3.1. Choice Paralysis

Some players open the options menu to make one small change and find 10 pages of settings with 20 options each — sliders, numerical values, toggles. They freeze. They can't process it and give up.

3.2. Accidental Difficulty

Players change settings without fully understanding what they do, then blame the game for being too hard. "Slider 57 on page three" might have fixed their frustration, but they never found it because it was buried in an ocean of options.

3.3. Self-Sabotage

The most fascinating pattern: players will enable options they hate simply because the option exists, then blame the game.

Tim gives two examples:

  • Save scumming: If a game allows saving anywhere, some players will compulsively save-scum even though it makes the game less challenging. They resent the game for letting them do it.
  • Quest markers: Some players always turn on quest markers even when they prefer playing without them and the game works fine either way. They're mad the option exists at all.

Tim's honest take: "I don't know how to fix that. You can't really argue with what people like."

4. Argument 3: Developers Don't Like It Either

Fellow developers — sometimes on Tim's own teams — push back against extensive options for additional reasons beyond testing.

4.1. Implementation Burden

Every option requires code, UI work, and dedicated testing. It's work on top of making the actual game.

4.2. "Just Decide"

Some developers (and critics) argue that the game director should simply decide what game they're making and commit to it. Tim has been accused of using options as a crutch — pushing design decisions onto players rather than testing, iterating, and choosing.

4.3. Making Multiple Games

Some gameplay options are so significant they fundamentally change the underlying experience. At that point, you're effectively making two or three different games — with all the development cost that implies.

5. The Takeaway

Tim's conclusion is characteristically balanced: think very carefully about your gameplay options before committing to them. Having too many is just as bad as having too few.

The ideal is a curated set of meaningful options where each one has been designed for, tested, and doesn't create unintended consequences when combined with others.

6. References