Challenges Facing Game Designers

1. The Seagull Designer Problem

The biggest frustration for game designers: everyone thinks they're a designer. Tim calls these people "seagull designers" — they swoop in, drop an idea on your desk, and fly away thinking their job is done. When you ask follow-up questions ("How does this interact with existing systems? What about edge cases?"), the answer is invariably: "I don't know, I just had an idea. Run with it."

This happens constantly, from team members and outsiders alike. And when the feature finally ships after months of work, the seagull designer takes 100% of the credit despite contributing roughly 1% of the effort.

2. The Real Design Process

Tim walks through what actually happens after an idea is born:

2.1. Specification

This is where 90% of wannabe designers fail. A specification is a detailed document for a specific, scoped feature — not "combat" but "two-handed melee combat and its interaction with skills, perks, and items." It starts with goals (what is the intent?) so that later discussions can evaluate whether the implementation meets that intent, or whether the intent itself needs changing.

The spec must include formulas, numbers, and links to every other feature it interacts with. Without these, programmers will live in your office asking questions, and artists won't know what UI elements or assets to create.

2.2. Implementation and Iteration

A programmer gets assigned the spec and begins implementing. They'll visit the designer constantly as they discover conflicts with existing systems. This may require changes that pull in producers (for scope decisions) or reveal that existing systems were already problematic.

Art often becomes a blocking dependency — features get partially implemented, then wait for artists before the programmer can finish.

2.3. QA

QA's job is to break the feature, and they're very good at it. Tim has witnessed producers yelling at QA for finding problems — something he pushed back against, noting you should be grateful bugs are found before shipping. QA discoveries feed back into the spec-implementation cycle, as issues may be design problems, code bugs, or art that doesn't loop or interrupt correctly.

2.4. Credit Disputes

When a feature ships and players love it, who gets credit? The person with the original high-level idea? The spec writer everyone worked from? The programmer who coded it? The artist whose visuals made it appealing? QA who made it actually work? Tim notes these disputes are common and often nobody remembers correctly — he's had conversations where both parties turned out to be wrong about whose idea something was.

3. Real Examples of Bad Design Proposals

3.1. Permanent Death in an MMO

Around 2000, Sierra brought Tim a spec for an MMO where death was permanent — die once and your character is deleted, lootable by whoever killed you. Tim explains why this works in single-player "Iron Man" modes (where death is ultimately your fault) but fails in MMOs: you can die because your tank didn't taunt, your healer didn't heal, or your group dragged you into an overleveled dungeon. Once players feel their death wasn't their fault, permanent death becomes unacceptable — especially when competing MMOs don't have it.

The same game restricted certain races behind a 100-hour playtime gate, framed not as an "unlock" but as "prove you're a real fan before you deserve this."

3.2. Removing Encumbrance

Someone proposed removing encumbrance entirely — let players pick up anything without movement penalties. Tim pointed out this would worsen an existing inventory management problem (hundreds of items becoming unmanageable). The proposer acknowledged the issue but wanted to "roll it in" with a future fix. Tim noted that encumbrance actually solves the inventory problem by capping what you carry.

3.3. Removing Ammo

The same person wanted infinite ammo for all ranged weapons. Tim argued this would destroy the balance between ranged and melee weapons — melee's advantage was never running out of ammo. With infinite ammo everywhere, melee loses its role as a fallback. When Tim asked how existing specs for melee and ammo systems would be updated, the answer was: "That's your job." Tim's response: "No, my job is to get my stuff in the game. If you want this change, you explain how it fits." The feature wasn't added.

3.4. "The Designer's Job Is to Kill the Player"

Tim worked with a designer who genuinely believed a designer's primary goal was to kill the player — not challenge them, but kill them. Every feature's main purpose should be finding ways the player could die. Tim disagreed fundamentally: his goal was always to entertain the player. He acknowledges this is nebulous, but it cascades down through every design goal. This is why his games sometimes aren't perfectly balanced — he prioritizes fun over balance. If players find an overpowered build, he's usually fine with it. The one thing he won't accept: a build that can't finish the game. That's "the definition of not fun."

4. Why Design Is Uniquely Vulnerable

Tim closes with an observation: nobody walks up to a programmer and says "I could code that better," and nobody tells an artist "let me model something better than that." But people do this to designers constantly. The other disciplines don't face the same presumption that anyone could do their job.

His advice: don't let it discourage you. Just go in knowing it will happen.

5. References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=4XzaRlW2sio