Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 21, 2014
arrowPress Releases
October 21, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Poor Application of the "Fail Early" Strategy in Game Development
by Fumiaki Shiraishi on 08/16/14 02:16:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


I've been listening to some old podcasts from Freakonomics and Radiolab, and heard some episodes about quitting and failing quickly. They make some great points, and in general I agree with the idea.

Personally, however, I have nothing but bad experiences when game companies talk about the importance of failing early. I've seen a bunch of instances where this strategy was applied, sometimes first hand, and they have all failed quite spectacularly.

There are actually a myriad of different reasons why projects and games fail, but for this post I'd like to focus on how companies often mistakenly apply the fail early strategy in game development.

The "fail early" strategy with game development projects assumes that you can predict the probability of success at an early stage of development. With some aspects of development, this is pretty straight forward. Can we simulate enough enemies on screen for this game idea? Do we have the budget to create the art assets for this look? Questions like these, we can answer fairly quickly by doing some homework.

But how about the million dollar question of "Is this game going to be fun?" This is really hard. Even in the short history of game development, there are many examples of games that really weren't fun until all the pieces were in place, or a minor tweak was made at the last minute. I've also seen many instances of the reverse, where a game looked really promising in the beginning, but faltered later on.

Games that depend on moods ands emotions are extremely difficult to judge in pre production, or even in Alpha. How can we possibly fail early with these?

The strategy of failing early also ignores the human factor. Many developers are motivated by the project and its potential. But what if you were working on a project that your boss says it's probably not going to be good, and that it'll be scrapped? How motivated can you get?

Motivation is a huge factor in game development. Motivation helps create the thousands of little ideas that we have during production that actually makes a game fun. It definitely helps to have a good core concept, but even the best concept can't survive without a motivated team.

Now, my argument is not that "faily early" does not work. On the contrary, I think good teams naturally employ the "fail early" strategy on a daily basis. Even in the simplest game, developers iterate on ideas and designs many times over.

Where companies error, is when they make the mistake of equating a project with the team, and applying the "fail early" strategy on projects directly. Sometimes, I wish I was a robot, but being human, knowing that I'm just ball in a lottery box does not motivate me.

A better approach would be to say, here's a project with this goal and this team. This project will not, and can not fail. With regards to the process, the team structure, the ideas, and the designs... well those you should fail early.

Related Jobs

Crystal Dynamics
Crystal Dynamics — Redwood City, California, United States

Audio Lead
Filament Games LLC
Filament Games LLC — Madison, Wisconsin, United States

Quality Assurance Associate
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Team Lead Online Marketing - TV (m/f)
Yoh — Vancouver, British Columbia, Canada

Build & Test Engineer


Kevin Maxon
profile image
Completely agree. Failing early makes sense if your game's success depends on some simple game mechanic being fun. Failing early does not make sense if your game is highly complex or dependent on content. With Eidolon, there was /no way/ we could fail early. The game's success was completely dependent on there being an appropriate density of well-written content in the world.

Andrew Haining
profile image
Fail Early and minimum viable product are both symptoms of the influx of untrained people into game development, no one knows what they're doing so they just run around like headless chickens. If you're trained and/or smart you should think big imo to try and offer something no one else can and separate yourself from the pack of also rans. I wrote about it here on gamasutra a while back:

Nick Harris
profile image
I'd be scared to try lots of incoherent random stuff and then retrospectively find my focus, only to have to edit the player's dynamic experience by selectively removing overelaborate mechanics in the hopes I could keep everything balanced. Maybe you can get away with that methodology in a 48 hour game jam when you are desperate to impress judges with something innovatory, but the only sane way I can proceed is to prototype and tune each layer of the experience starting from the outside with the UI and working inwards towards a final polish to the presentation.

I feel that Nintendo has it right by designing the control scheme first and ensuring that it is both accessible and ergonomic - i.e. frequently used actions require little or no repositioning of digits. Ideally, it should strive to be articulate whilst hiding its complexity from the neophyte so that it can be gradually mastered over the course of the increasingly difficult challenges that require it, usually as levels unlock in sequence - e.g. Super Mario 64 is unlike Far Cry 3 as you have every ability 'unlocked' at the outset when you muck around outside Princess Peach's castle.

I feel that Cloud Imperium Games (i.e. Chris Roberts) had it wrong by focusing on presentation of a hangar containing spacecraft you couldn't fly, but merely walk around and climb inside. Recently the same spacesuited guy has shown up in a teaser for its upcoming FPS 'module' without there being evidence of complex ragdoll animations. Funds are requested to research alien "conlangs" before the core of the game is proven to be on a firm, fun, foundation. This could result in patchy aesthetics, flaky dynamics and incoherent mechanics. I hope for everyone who has contributed to its development that this isn't the case.

I feel that it is far better to keep independent from the pressures of a publisher and the influence of their marketing department and not reveal your progress on a multiyear project for fear of its potential consumers becoming overly impatient and demanding of a release date before one can be readily estimated and then crazed with anger when they don't get their toy in time for Xmas.

I feel that the delay to point-to-point DriveClub past the launch of the open-world Forza Horizon 2 has contributed greatly to my ambivalent attitude towards it. Having expected to purchase it soon after I bought my launch PS4 on a not inconsiderable bubble of justifiable hype about its almost overdetailed car models, slipping nearly a whole year past the release of a sequel to a game that I adored bursts its tyres on the starting grid. Hello Games have surfed a wave of expectations that is so steep that it was at one point in danger of wiping them out as accusations that No Man's Sky was a sham, which then became moderated to "well, all the planets will look the same" as grumpy internet keyboard warriors tried to drown the studio that had once been underwater already.

I feel that it is better to avoid this early hype by making no development blogs, teasers or trailers, until you have something you can simply demo. If at all possible self-fund as I have with my work which is an intergalactic MMORTSFPSRPG which has so far cost me £20,000. Quite why Roberts needs $51,000,000 to do something smaller is a mystery to me. However, I wholeheartedly agree that one should 'think big or go home' as it would just be a waste of my time to do something in 48 hours that I simply wasn't emotionally invested in. Even if I am the only person to ever play my game I will be completely satisfied as to be honest I don't really want the hassle of customer support and forum moderation. Just having a hobby that can expand my technical knowledge is immensely rewarding and more than compensates for my investment in time and resources.

John Woznack
profile image
I'm not sure I agree with the term "fail early". Rather, I'd suggest a better way of thinking about this is: "Quickly recognize and admit when something isn't going to work, then make changes to prevent failing."

Too often I've seen a team start out with an obviously-impossible game design & schedule, but no one dares to voice their doubts, usually for fear of being negatively labeled by everyone. Months go by and as the schedule slips, and features aren't done, and the game play isn't fun, still no one says anything. On the contrary: pep-rally meetings are held in a disgusting attempt to increase the shame of missing deadlines in hopes that everyone on the team will mindlessly agree to work overtime as penance for their production sins.

And although I generally agree with the idea of putting the high-risk items at the front of the development schedule, like Fumiaki says, often times the most important aspects of a video game won't emerge until it's done, or nearly done. We can always guess at what we think will be the critical parts, but even then there's a risk of failing to pinpoint what's truly risky for the development cycle. (How many games have been technically wonderful, only to have horrible gameplay or zero fun?)

I think it would be better for teams to quickly and openly agree when something about the development isn't working, and then change course to prevent actually failing in the first place. (Yes I know - easier said than done when your under a publishing contract or some such outside pressure.)

Jacob Crane
profile image
I always looked at the fail early principle is quickly get minimal viable product in the hands of potential users and get feedback ASAP. That way you can assess what is working and what is not working and if your adjust or rethink things.

That being said, generally speaking people will try to codify something into a more rigid structure to try to be able to put it all on paper easier for people who are not exposed to direct development to understand.

In short: To fail early is to execute something as soon as possible to gauge if the intended effect you wished to create is actually working. (Reading between the lines this should be done in the fastest cheapest way possible)

Fumiaki Shiraishi
profile image
Thank you guys for the feedback!

I totally agree with the importance of front loading risks, and employing techniques to prove out ideas.

I'm was not trying to argue against the principle in general. Just the misinterpretation of it.

Randy Angle
profile image
I've made games for a VERY long time. Most teams simply don't have management systems in place to properly run projects (and I'm talking very big and very small teams too). Too many times I've walked into a studio that claims to use Agile and SCRUM only to find that they have implemented a haphazard approach that will frustrate and complicate their games. LEAN process, which relies heavily on "fail early" mentality and MVP thinking - is great for building a certain kind of software or service oriented application - but like Agile, can suck the creative energy out of art and fun game design. I'll pick on Fishville for an example of paying too much attention to the analytics and compulsion loops and not enough attention to what was actually fun. I've also seen many teams apply so much rigor and discipline to the process of software development that they simply miss on the actual creative endeavor of making something fun that will engage players.

Making games takes a careful balance of creative chaos along with the order of software engineering. Frederic Markus calls it "The Nintendo Way" and I call it SMAFF (Smaller, Faster, Funner) - but they both are based on prototyping and replaying the core mechanics and game loops, iterating as necessary until you actually find the fun in your game. Then, and only then, are you green lit to move forward into actual production of final game assets, levels and eventually JUICE (the polish and pizazz). Our players are sophisticated and require quality throughout the experience - cutting corners is not allowed. But spending production budget on a game that has not been properly prototyped with a Miyamoto Box level of "Is it fun to run and jump yet?" is a waste - that is the time and place to use "Fail Early" - it is what prototyping is for.

Damien Ivan
profile image
Not trying to be flippant, but the response that seems obvious to me is that the whole game doesn't need to be finished to try it out early. If a game depends on mood, then maybe it's more important to make one demo level *really well* instead of making a whole game roughly.

If anyone with more experience in this matter than I think what I'm saying is dumb or crazy, please let me know, but in my field of expertise (video/animation), there are times when that's exactly the way to go — instead of doing a rough one or two minute video initially, the better way is to do ten seconds as well as possible.

Am I crazy here?

[Edit: fixed missing word, "minute"]

Randy Angle
profile image
Damien, You are correct - there are various terms for what you suggest (example: vertical slice), but the idea here is can you create the aesthetic (mood) through your choice of mechanics and dynamics. Not every emotion needs to be 'fun'.

Fumiaki Shiraishi
profile image
Some concerns I would have in making just one demo level really well though:
1) To make one demo level really well, I think you often need MOST of the tech and game design done. So this approach really only mitigate art production risks. Ok, maybe I shouldn't say "only" because art production cost can be huge. But in my experience, art production is expensive but manageable. Rarely does art production breakdown completely. Game design, on the other hand, breakdown completely quite regularly. (Or have I just gotten lucky with art production?)

2) I feel like sometimes teams can get caught up in details when working on just one level. Essentially miss the forest for the trees. Even in pure action games, a sense of progression is a big part of the experience, and I'm not sure if you can explore that in only one level.

Damien Ivan
profile image
Fair enough. It did occur to me after the fact that building the engine itself is no small feat.

Doru Apreotesei
profile image
I've personally cobbled together a method of my own called the Tiered Pyramid Method. It's not yet made it into my blog here at Gamasutra, but one of these days I'll get around to it. In the meantime there's a video of an early lecture on Youtube which I'll gladly share.

Summarized, it's about frontloading risk - but also identifying risk correctly. Just "difficult to do" or "likely to fail" isn't enough. The feature/content in question must also be ranked in order of importance to the project. I've seen quite a few projects that have failed because people got things backwards - they focused on stuff that was difficult, but ended up being broken by "easy" and "low-risk" stuff that they had grossly under-estimated.

Another important thing is cross-dependencies. Seemingly "minor" systems often end up drastically changing the game dynamics and player behaviour, and thus enjoyment. That's why I'm recommending stacking horizontal slices rather than vertical ones.

If anyone's interested, here's the link:

Sheng TAO
profile image
Mr. Shiraishi, I like your idea of how not to wrongly apply the "fail early" strategy in GD.
Would it be OK that I translate your post into Chinese and share it with my colleagues and friends? (some people don't feel good reading articles written in foreign languages.)

Fumiaki Shiraishi
profile image
Sure, no problem!
Thanks for asking though.

Sheng TAO
profile image

Kenneth Nussbaum
profile image
I think with any mantra the "fail faster" mantra is a broad stroke approach to game design, I think its intended to serve more as a reminder not as a design philosophy. "Failure is not an option" is another mantra that should also be used in the game development industry, but developers still need to be careful not to place themselves in an unhealthy and overly stressful work environment.

I think fail early is just a reminder to game developers to be more humble about the ideas they produce. I also think it means look for the holes in game development early and find ways to prototype larger ideas on a smaller scale, this helps with that issue where one minor change can make the difference in making a game fun. In the case of a AAA studio this is particularly true, sure the typical dev schedule doesn't have time to waste on mini-game versions of the final product, but with the way modern game engines are set up its not too hard to quickly mess around with art assets, level designs, and system design. When making a shooter why not mess around with a prototype of a version where grenades inflict a status aliment, like lower speed or less accuracy. That would take minutes to program and be a lot of fun to test, maybe it'll help point out game play quirks you didn't realize were there.

There's no catch all to game design, there's risk and there's a lot of unknowing, no mantra is ever going to fix that. As the 'fail early' mantra gets more and more popular I think its clear its something that a lot of developers needed to hear and be reminded of, not to follow it as a die hard life philosophy.

Clinton Keith
profile image

It sounds like "front-loading risk" is the better way of expressing this.

Something else you said struck me:
"Where companies error, is when they make the mistake of equating a project with the team, and applying the "fail early" strategy on projects directly. Sometimes, I wish I was a robot, but being human, knowing that I'm just ball in a lottery box does not motivate me."

I agree, but I think there is too much emphasis on the "project" which has "resources" assigned to them. The focus should be on a culture of building high performance teams. These teams are trusted and can be aimed at a game concept that they can prove or disprove as fast as possible. This culture doesn't blame a team for disproving a bad concept and the team doesn't see it as their failure. These cultures are rare but they exist.

Yes, people don't want to abandon a game early, but working 2+ years on a game that you know isn't going to be any good is worse.

Eric Robertson
profile image
I'd argue the strength of Agile and Fail Early mind sets is not in the just the early validation of high risk concepts, but that it re-frames the attitude of the dev team into a more long term and hopefully more profitable one.

Instead of a static game end state design, the project becomes an evolving system. One that is meant to grow and adapt as players provide feedback continuously.

I believe the upward vector of the product's trajectory of fun is much more important then its state of fun on release. I want the game to transform on its own to become earth shattering revolutionary fun on day n, never stopping to evolve.

On a side note, this is the reason I predict the Google self driving car will, in only a decade or two, save more lives then the most experienced ambulance driver, become more reactive then the most veteran of military drivers, and win more races then the best human NASCAR drivers. They don't care about today, they care about it's evolving vector.

Gary LaRochelle
profile image
I would recommend reading: "Creativity, Inc" by Ed Catmull, President of Pixar Animation and Disney Animation.

There are a lot of similarities between making a game and making a Pixar film. Both start out as creative projects that evolve over the life of production. He writes of "Failing" and "Failing Quickly" (not "Failing Often"). You fail quickly to get the problems out of the way as soon as possible.

People failed because they didn't know the right way to do something. But if you hire someone who has the experience of doing something right, you cut down your failure rate greatly (saving you time and therefore money).