Abstract
Problem: How should game developers approach prototyping and iteration to maximize the quality of their final product?
Approach: Tim Cain draws on 30+ years of experience — from Fallout's early engine experiments to Arcanum, South Park, and Carbine Studios — to explain the "fast fail" methodology and its trade-offs.
Findings: Fast fail (rapid prototyping) produces better games by cheaply eliminating bad ideas early, but it requires a willingness to throw away work, a singular creative vision to ensure convergence, and stakeholders who can see past gray-box aesthetics. Without these conditions, the methodology breaks down.
Key insight: Fast fail is the path to greatness, but only if the team has a clear vision to converge toward — otherwise you wander the design space forever.
What Is Fast Fail?
Fast fail — what Tim has always called rapid prototyping — means quickly assembling rough versions of game mechanics, levels, or systems to test whether they work, before investing in final art and code. The goal is to discover failures cheaply: you're not upset when something fails, you're happy that you found out with minimal time and resource investment.
This requires a specific mindset: designers must let go of mechanics they love, programmers must throw away code, and artists must throw away art. Some people simply can't do this — Tim initially thought it was ego, but now believes some people genuinely can't accept that the path to a destination isn't straight. He draws an analogy to hill-climbing algorithms in AI: you can get stuck on a local maximum, and sometimes you need to go downhill to reach the true mountaintop.
Fast Fail in Practice: Fallout
Tim practiced fast fail extensively during Fallout's development, even before the term existed:
- Three engines were built and tested before settling on the isometric engine. A voxel engine was too limited; a 3D engine was too slow and low-poly for acceptable frame rates. Without building and discarding those prototypes, the team wouldn't have known.
- When Leonard Boyarsky proposed changing Fallout's aesthetic to a retro-50s vision of the future, work that didn't fit was thrown out — wall sets, props — though some pre-existing assets (like Road Warrior-style leather armor) were kept when they weren't jarring.
- When GURPS was dropped, Chris Taylor came back in just a few days with a nearly fully realized replacement system (SPECIAL). They threw it in, hooked it up, played it, and iterated — adding luck at Tim's suggestion, adding purchasable perks at Brian Fargo's request. The game itself was treated as a prototype.
Why Companies Avoid Fast Fail
Bosses and publishers can't see past gray boxing
Tim has worked with people who look at a gray-box prototype — toast-shaped guards sliding around big gray cubes — and say "this is stupid" or "this mechanic is awful." The mechanic isn't awful; they just can't evaluate gameplay separate from visuals. If you work with people like this, you simply cannot show them prototypes. The only workaround is waiting until you have a beautiful corner or vertical slice to present.
Developers can't bear to part with their work
Once someone has coded a system, written a design doc, or modeled a creature, they desperately want it in the game. Tim mentions that on South Park, they threw away entire completed, shippable levels — painful, but necessary. Some developers can't handle this; they see their work being thrown away rather than understanding the prototype served its purpose.
The cost problem
With Fallout, Tim did much of the early prototyping alone, on his own time, so it cost almost nothing. But with a full team, fast fail means paying many people to do work that may be discarded. Every other industry calls this R&D — but the game industry largely doesn't budget for it. Only companies with large enough war chests (Tim cites id Software, Valve, and Blizzard) can work on a game "until it's done." Most companies work on a game until the budget runs out, then ship it.
The Convergence Problem
The most dangerous failure mode of fast fail is never converging. Tim saw this at Carbine Studios (WildStar): lots of ideas flowing in from too many people, but nothing converging toward a singular vision. All the prototyping and redesign in the world won't help if you're just wandering through design space without a destination. Fast fail requires a singular creative vision to converge toward.
The Arcanum Cautionary Tale
Arcanum illustrates another pitfall: the team prototyped many systems but ran out of time to remove or polish them. Players ended up experiencing systems in their raw alpha state — prototypes that were never meant to ship, but did because the clock ran out.
Stable Goodness vs. Unstable Greatness
Tim frames the core trade-off: companies must decide whether they want stable goodness (safe, predictable, but mediocre) or a little unstable greatness (riskier, but with higher potential). Games that ship "eh" and only get significantly better after a year of patches are evidence of studios that didn't fast-fail during development.
Fast fail can lead to unstable games because of all the churn — but Tim believes it is the path to greatness. His recommendation: if you're building a prototype, do it as quickly as possible, make as many prototypes as you can, and see what works. The result will be a better final game.