Abstract
Problem: The game industry assumes developers are equally effective across all production stages — but is anyone actually good at every phase of making a game?
Approach: Tim Cain draws on 45+ years of experience working with developers, artists, programmers, and publishers to examine how individual effectiveness varies across production stages (brainstorming, concept, prototype, production, testing, shipping).
Findings: Every single developer Cain has worked with — including himself — has been weak at one or more production stages. The industry's treatment of developers as fungible (interchangeable across all stages) leads to poor outcomes. The solution for mid-to-large studios is to identify which stages each developer excels at and rotate them between projects accordingly.
Key insight: Developers should be characterized not just by their role (programmer, artist, designer) but by which production stages they excel at — and staffed on projects accordingly.
The Core Claim
Tim Cain makes what he calls his first "absolute statement" on the channel: every single game developer he has worked with across four and a half decades has not been good at all production stages. Not "many" or "most" — every one, including himself.
Games go through stages: brainstorming, concept, prototype, horizontal slice, vertical slice, production, content completion, testing, optimization, and shipping. Nobody excels at all of them.
Tim's Own Weakness: Wrapping Up
Cain openly admits he is not good at the final stages — wrapping up a project, tying loose ends, ensuring every map is done, every item is in, localization is handled. He leans heavily on producers for this.
The Fallout Story
On Fallout, the first project he led, Cain discovered near the end that an entire map wasn't done, items were missing, quests were unfinished or not even started. He went to Feargus Urquhart, who not only pulled people from other projects to help but rolled up his sleeves himself and did low-level work — making quests and items to get the game shipped.
Cain identifies two people in his career who were exceptional at getting games across the finish line: a producer he worked with for years, and one of the founders at Obsidian. He considers wrapping up a game to be "art" — less science, more attention to detail, management, and feel.
Examples of Stage-Limited Developers
The Brilliant Artist Who Couldn't Brainstorm
Cain worked with a "fan-freakin'-tastic" artist — phenomenal at concept and execution, could sketch something up and then build it beautifully in 2D or 3D packages. But in a brainstorming session for a new IP, everything the artist described was purely visual. When Cain asked the fundamental question — "That sounds like it looks amazing. What does the player do?" — the artist not only couldn't answer, he got angry at Cain for asking. Cain's conclusion: if you can't answer "what does the player do?" during a brainstorming session, you shouldn't be suggesting a game.
The Fast Prototyper Who Couldn't Finish
A programmer who was incredibly fast and talented at prototyping, building the base game, and the horizontal slice. But when the project reached the end and code needed to be optimized and finished, he just couldn't do it. He seemed genuinely confused that code had to be completed and shipped. Someone else almost always had to step in to finish his code and handle optimization — getting that last 10% done.
The Fungibility Problem
The modern industry treats game developers as fungible — interchangeable units that can be socketed in and replaced. A programmer is a programmer; an artist is an artist. Everyone knows this isn't true, yet companies still operate this way.
Worse, many employees think of themselves as fungible, assuming they can be placed at brainstorming and stay productive through testing and optimization. They can't — nobody can be wonderful, highly efficient, motivated, and passionate about every single stage.
The Solution: Stage-Aware Staffing
For solo and very small developers, Cain admits he doesn't see a solution — if no one on the team is good at a particular stage, there's not much you can do (which he suspects is a major reason many solo indie projects fail).
For mid-tier and large organizations, the solution is clear:
- Identify developers by both role AND stage strengths — "This programmer is great at rapid prototyping but don't want them at the end when things need optimizing"
- Rotate people between projects as stages progress — large studios always have multiple games in various stages of development
- Move concept artists to the next game after the art style is established; keep some for 2D production art (UI, loading screens, in-game textures)
- Bring in "completionists" for vertical slices and final stages — content completion, testing, optimization
The Concept Artist Exception
Concept artists are one notable exception to the stage-limitation problem. They're usually brought in early for art style definition, level layout concepts, and visual touchstones. Many are also effective during production doing 2D art — UI elements, inventory icons, in-game textures, posters, loading screens. Their skills translate well across the concept-to-production transition.
Publishers Aren't Immune
Cain extends the observation to publishers: he's never worked with one that handled every stage well. Some are great at the beginning — making good contracts, asking probing questions that tease out vague areas in design docs, helping teams spin up. But later they fall apart — poor marketing, or terrible QA oversight.
References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=rm9dT6BgL_Y