Abstract
Problem: How long should game development take, and what are the trade-offs of long vs. short development cycles?
Approach: Tim Cain draws on his experience shipping games in as little as 14 weeks (Bard's Tale Construction Set) and working on projects that took up to nine years (WildStar), examining the pros and cons of extended development timelines.
Findings: Longer development allows more content, polish, and debugging, but introduces serious risks: feature bloat, hardware obsolescence, team turnover, "team relaxation" (procrastination at scale), and franchise aging. Short timelines force painful cuts but also enforce discipline.
Key insight: Development time is not purely a "more is better" equation — long cycles carry hidden costs that can be just as damaging as shipping too early.
Pros of Long Development Time
Tim identifies several clear advantages of extended development:
More Features and Content
A longer timeline means fewer painful cuts. Tim references Monarch in The Outer Worlds — originally designed to be a large, explorable, lawless planet that got significantly reduced due to time constraints. He regrets that cut, as it was meant to make the world feel bigger and more lived-in.
Side Content and World-Building
Long timelines allow for NPCs and side quests that aren't all tied to the main storyline. Tim values characters who are "just there to run their shop or farm" — they make the world feel real rather than entirely player-centric.
Debugging Time
Tim notes that every Troika game shipped as an alpha. Arcanum was about to start a bounce pass when it shipped. Temple of Elemental Evil (done in 20 months on an 18-month schedule) was told "nope, shipped" right when the team was ready to start serious debugging. Vampire: The Masquerade — Bloodlines shipped before it was even finished, which is why the Warrens at the end of the game are completely empty.
Cons of Long Development Time
Feature Bloat and the "Big Bag of Features" Problem
More time can mean too much of a good thing. Tim cut talking raccoons, endoskeleton robots, and a liquid metal robot from Fallout — not for time reasons, but because they didn't belong. With a long timeline, you lose the excuse of "we don't have time" when cutting features, forcing more subjective and politically difficult conversations with designers.
Romance Options as a Case Study
Tim explains why he doesn't put romance options in his games: not because he's against them, but because doing them well requires enormous narrative designer time. Most RPG romances feel like "bizarre slot machines" — say the right thing, have the right item, and the character sleeps with you. He suggests dating sims do romance far better.
Coordination Complexity
More features means more production overhead. Going from managing dozens of features to hundreds requires exponentially more coordination — checking for unintended emergent interactions, ensuring everything works together. Some production teams are up to the task; some aren't.
Hardware Changes
An 8-year development cycle means targeting hardware that doesn't exist yet. Consoles have roughly 10-year lifetimes. Are you targeting the next console you know nothing about? Betting on future GPU capabilities? This is a significant risk.
Team Turnover
Nobody wants an 8-year gap on their resume. Tim himself has a 10-year gap between Bloodlines (2004) and South Park (2014) because WildStar consumed six years and still shipped after South Park. Long projects guarantee significant team rollover.
Team Relaxation
Tim compares this to college students who don't start their papers until the deadline looms. He's seen it at individual and company levels — without a publisher acting as "the adult in the room" enforcing milestones, teams (and entire studios) can drift. He admits Arcanum may have suffered from this with too many features and too-loose design pillars.
The Fallout 5 Concern
Tim expresses personal concern about Bethesda's sequential development approach. With Starfield finishing and Elder Scrolls next in the pipeline, Fallout 5 likely won't arrive until ~2034 — nearly 20 years after Fallout 4, and 40 years after Tim started making the original Fallout.
He worries that:
- Players of Fallout 5 may never have played Fallout 4, let alone the originals
- Their entire concept of Fallout may come from the Amazon TV show
- Franchises risk becoming "archaic" when gaps span literal generations
Tim understands why Bethesda focuses on one project at a time (he's heard it called "the Eye of Sauron" — a few key people who keep the project on track), but fears that as development times extend further, beloved franchises will age out of cultural relevance.
The "Eye of Sauron" Management Style
Tim mentions hearing this term at various companies: the idea that a studio has a small number of key people whose focused attention is what makes a project work. When that focus ("the Eye") is on your project, things move. This is why Bethesda doesn't split their team — they do their best work when everyone is pointed at one thing.