Abstract
Problem: How do game developers view speedrunning, and does it affect post-launch bug fixes or game design decisions?
Approach: Tim Cain shares his personal experiences with speedrunning across his games — from Fallout to The Outer Worlds — and addresses common assumptions about developer attitudes toward the practice.
Findings: Developers generally love speedrunning and see it as an ingenious form of player agency. Speedruns are not used as justification for patches unless they reveal genuinely broken game states, and Tim has never added features specifically to prevent speedrunning.
Key insight: Speedrunning is a natural extension of the player agency philosophy that defines Tim's games — the same "go anywhere, do anything" design that made his RPGs special is exactly what makes them speedrunnable.
Tim's View on Speedrunning
Tim opens by stating plainly: he loves speedrunning. He considers it a "really clever way of playing the game," and says most of his colleagues feel the same way. Developers see it as ingenious rather than offensive.
He does note a distinction: speedrunning probably isn't the best way to enjoy the game — you skip encounters, ignore quests and story. But every speedrunner he's watched has already played the game extensively. The speedrun itself becomes the fun.
The Fallout Speedrun Story
Tim's first encounter with speedrunning came with the original Fallout. The team estimated 40–60 hours of gameplay. QA testers could complete the main storyline in just under 8 hours — which was actually useful, since it meant they could play through a new build every day.
After launch, someone completed Fallout in 2 hours, which impressed Tim — a quarter of QA's time. Then someone did it in 15 minutes by getting the water chip, then blowing up both the mutant military base and the Master's cathedral.
Then came the 8-minute run. The runner never even got the water chip. It turned out the developers never actually checked whether you had it — the game just assumed you did and directed you to the next objective. The runner went straight to the military base, destroyed it, then headed to the cathedral and set the bomb. Tim's reaction: "This is clever and this is smart."
Watching The Outer Worlds Speedrun with Leonard Boyarsky
Tim references an IGN video (still available) where he and Leonard Boyarsky watched an Outer Worlds speedrun together. They were both amazed at the clever techniques — short-circuiting quests, finding ways into places, jumping out of instances to clear combat flags so equipment could be used. The runner completed it in roughly 12 minutes. Tim describes it as genuinely fun to watch, especially alongside Leonard.
The Fancy Meal Analogy
Tim acknowledges the common assumption that speedrunning must aggravate designers — someone is skipping all your carefully crafted content. He compares it to making a fancy meal and having someone say "I want to see how fast I can eat this." You understand what they're doing, but there's this really nice meal you spent a lot of time on. Still, it doesn't bother him.
Design Philosophy: No Anti-Speedrun Measures
Tim states clearly that he has never added a feature specifically to mess with speedrunning, and doesn't believe he should. If players want to figure out how to bypass content, "knock yourself out."
Content Gating in His Games
As a designer, there are legitimate reasons to gate content — keeping low-level players from stumbling into overpowered zones, or ensuring storyline pacing (even non-linear stories need pacing). This means keys, quest triggers, locked doors. But Tim admits his games do this less than most, because of the "go anywhere you want, do whatever you want" mentality.
Bug Fixes and Speedrunning
Tim draws a clear line on when speedrunning influences patches:
- Won't fix: Barrels that let you jump over a fence, or doors that can be bypassed. Speedrunning tricks that work within the game's systems are fair game.
- Will fix: If a speedrun reveals that the game can enter a bad state where the main storyline can't be finished, that bug gets fixed — not to prevent speedrunning, but because the main story arc must always be completable regardless of character build or play order.
Post-release patches, in Tim's view, should address crashes, egregious bugs, and balance issues — not make the game "less playable in certain ways."
Hiring Speedrunners for QA?
Tim addresses the suggestion that studios should hire speedrunners as testers. His answer: maybe, but there's much more to QA than seeing how fast you can finish. He values testers who report things like "this area was way too hard with my character," "these quests caused a bug when done out of order," or "this sequence crashes the game." He wouldn't reject a QA candidate for being a speedrunner, but it's not an attribute he specifically looks for.
Speedrunning as Player Agency
Tim connects speedrunning to his earliest experiences as a D&D game master in high school. His players never did anything he expected — and that unpredictability was part of the charm. He carried that philosophy into his games: not only expecting but wanting players to have maximum agency.
Speedrunning, he concludes, is simply an exercise of that player agency — "I don't want to do this, I want to do this. I don't want to go here, I want to go here." The fact that his games open up and allow it, letting players finish early through creative means, is a feature, not a bug.
References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=l-Vuw-qWCgY