Abstract
Problem: When a game studio is starting fresh, how do they decide what game to make, and who gets the final say?
Approach: Tim Cain draws on his experience founding projects — including Fallout — to lay out a practical framework for selecting the right project based on team composition and constraints.
Findings: The decision comes down to two axes: scope (driven by team size and budget) and strengths (what the team is actually good at). The person who should lead the decision is whoever combines the strongest creative vision with the ability to communicate it. Hooks help but aren't mandatory.
Key insight: Pick a project that leans into your team's strengths and fits within your size and time constraints — then commit fully to the features you choose.
Scope: Size and Time Dictate Features
The first filter is practical: how big is your team, how much time (budget) do you have? This determines the number of features your game can support.
More features means a richer game, but also exponentially more work — not just implementing each feature, but handling all the interactions between them. Skills, perks, traits, and backgrounds will stack, conflict, and raise edge cases that all need resolution.
If you go narrow, that's fine — but you must lean fully into those features. Tim's examples:
- Parkour game — Make climbing integral. Important locations require it. Some enemies can't climb; terrifying ones can.
- Physics game — Commit to destructibility. Weapons interact with physics. Explosions matter. Limbs come off. NPCs get knocked around.
The principle: once you pick a feature set, make it the heart of the game. Half-committed features are worse than absent ones.
Strengths: Build What Your Team Is Good At
Look honestly at your team's composition:
- Lots of narrative designers? Make a story-driven game.
- Mostly artists? Make a gorgeous adventure or puzzle game with simple underlying mechanics — things like spatial puzzles or configuration-based solutions.
Tim tells the Fallout engine story: early on, when it was just him, he built three separate engines — a 3D polygon renderer, a voxel engine, and a sprite engine. When the team grew and they assessed who they'd be working with, they chose the sprite engine — not because 3D wasn't "the future," but because the future wasn't there yet, and a sprite engine played to what the team could actually deliver.
The voxel engine was great for water and elevation but bad for buildings and NPCs. The 3D engine would have been a huge mistake for a game like Fallout in the mid-90s (they were already using 3D for Starfleet Academy, but that was just ships in empty space). The sprite engine matched the game they needed to make.
Who Decides?
Two scenarios:
Funded by a Publisher
The funder often dictates the fundamentals — setting, genre, elevator pitch. Tim has made several games where the core concept wasn't his choice. He leaned into it, bringing his strengths (choice and consequence, interesting characters, gray morality), but the basic "what is this game" was decided by whoever was paying.
Self-Funded or Indie
Look for the person with the strongest vision AND good communication skills. Both matter:
- Strong vision but can't communicate it? Useless — unless they're making the entire game solo. The team can't build what they can't understand.
- Great communicator but no vision? Dangerous — the project will constantly redirect as shiny new ideas catch their eye. ("Hey, what if we made it fantasy instead?" — a year into a post-apocalyptic game.)
The Role of Team Members
Team members don't make the final call, but they heavily influence it:
- They know their own capabilities: "My animations tend to be rigid — maybe robots instead of snakes."
- Domain experts add enormous value: someone who plays every fantasy RPG and knows what players are praising and what they wish existed is a goldmine for feature selection.
Hooks: Nice to Have, Not Mandatory
Publishers and marketers always ask: what's your hook? The one thing people will associate with your game.
Tim's observation: hooks usually emerge organically from a team member who feels strongly about a particular feature, can communicate it well, and it happens to align with the team's strengths. A good hook makes marketing, press coverage, and elevator pitches dramatically easier.
But truly excellent games that do many things well don't strictly need one. It never hurts to have a hook — it's just not a prerequisite.
Summary
Tim's framework in a nutshell:
- Assess your constraints — team size, budget, timeline
- Scope your features — fewer done well beats many done poorly
- Lean into strengths — build what your team is actually good at
- Commit fully — once you pick features, make them central
- Right leader — vision + communication, or defer to the funder
- Listen to the team — they know their capabilities and the market
- Find a hook if you can — but don't force it
References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=XgEPFzamR5I