Abstract
Problem: What's the difference between a game made by committee and one made through collaboration, and why does it matter?
Approach: Tim Cain draws on decades of experience leading game projects (Fallout, Arcanum, Carbine) to contrast the two approaches, identifying specific failure modes he's witnessed in committee-driven development.
Findings: Committee-designed games suffer from diluted vision due to decisions being made by vote rather than by experienced leads. Specific dysfunctions — loudness, charisma, persistence, annoyingness, and misguided fairness — cause bad features to enter games through social dynamics rather than design merit.
Key insight: A committee is just a form of a mob; collaboration with clear leadership produces coherent games, while design-by-vote produces forgettable ones.
Defining the Two Approaches
Collaboration means a group of people work on a feature together — a strike team or a loose affiliation — contributing code, art, and design. Everyone gives input, but the final decision is made by the lead or leads involved. When ties need breaking or features don't fit, one person (the project lead, now often called "game director") steps in and makes the call.
Committee means the same group structure, but decisions are decided by vote. Tim notes this sounds great on the surface but has historically always produced worse results.
Problem 1: Themes Get Lost
Committee-designed games end up with inconsistent features. Individual contributors bias toward what they personally love — the person who made crafting makes all the best items come from crafting, undermining quest rewards and loot drops. Nobody intended this, but without unified oversight it happens naturally.
Tim uses Arcanum as an example: the game's core theme is that magic and technology are antithetical. A committee might have voted in quests where someone "figured out how to mix magic and tech" — a "magic gun" — destroying the very premise that makes the setting interesting.
Problem 2: Good Ideas That Don't Fit
Individual ideas can be genuinely good but wrong for the game. Tim illustrates this with the original Carbine setting — a planet at coordinate 0,0,0,0 in every multiverse where anything could break through: robots, dragons, cyber implants, gods. As someone pointed out to him: "Since everything can go in here, nothing really belongs here."
This connects to Tim's design philosophy of setting → story → mechanics in strict order. You pin the setting first (Fallout = post-apocalyptic), then build a story that belongs in that setting, then create mechanics that support both. Committees undermine this hierarchy because features get voted in without checking whether they serve the established vision.
Fallout as Counter-Example
In Fallout, Tim enforced that main story quests must have at least three paths: combat, stealth, and dialogue. Designers frequently submitted quests with only combat. Because he had final say as project lead rather than running a committee vote, he could enforce the rule — either the quest got reworked, relegated to a side quest, or cut entirely.
Problem 3: Loudness
The biggest problem Tim has seen in committee-made games: the loudest person gets the most ideas into the game. This is the classic extrovert-vs-introvert dynamic. Introverts go to meetings where one or two people dominate, and they can't get a word in.
Tim's approach to this is that collaboration has to go both ways. He actively tries to draw out quiet people, but expects them to meet him halfway — either speak up in meetings, or send their ideas via email after reading the minutes. He'll shut down the person dominating, but the quiet person has to actually contribute.
He draws an analogy to his own YouTube channel: the loudest commenters demand technical coding videos, but those are actually his least-watched content. The silent majority wants high-level design discussions, development stories, and process insights. The loudest voices represent a minority.
Problem 4: Charisma
Charismatic people convince the committee their idea is best, even when rapid prototyping proves it doesn't work. This is where a feature should get fast-failed and cut, but instead the charismatic person convinces everyone to keep iterating: "No no, let's keep changing it, let's change it." Someone with authority needs to say "boom, we're out."
Problem 5: Persistence
People keep bringing up the same idea every meeting until others give in out of exhaustion. This is closely related to deliberate annoyingness — Tim once confronted someone who admitted to being deliberately annoying in meetings specifically to wear people down and get their feature approved.
Problem 6: Misguided Fairness
Someone suggests a bad feature, it gets shot down, and they complain: "You guys never let me put in any of my ideas." Out of guilt and a sense of fairness, the committee approves the bad feature. Tim admits he's done this himself — letting features into his games that he didn't like because the person suggesting them hadn't had any ideas accepted in months.
The Core Problem: Diluted Vision
Tim's one-sentence summary: games by committee tend to have their vision diluted.
Games that feel "okay" and "interesting" but ultimately unmemorable probably had a committee or an inexperienced project lead. When one person is in charge, everything lines up with their vision — it might not be a good vision, but at least it is a vision. Committee games become a generic hodgepodge: "It's kind of a fantasy game and we go around and do fantasy quests and get money and treasure."
A committee is fundamentally a form of a mob, and you don't want mob rule in game design.
References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=5-Jl1ptf6vs