Game Over: Learning From Failure In Videogames
We tend to think of videogames in terms of success. It’s all about rescuing the princess, getting the high score, beating the final boss, or pwning your friends. The last thing you want to think about is seeing that Game Over screen.
… That is, unless you’re a game designer, in which case the whole “Game Over” thing may be the most important detail to get right.
Consider what Will Wright, creator of such iconic games as Sim City and The Sims, has to say about the matter:
When we make games now, we very much think in terms of what are the interaction loops, and what are the success and failure sides of those interaction loops. One of the things that’s kind of non-intuitive here is that it’s actually more important to really think through the failure side than the success side. Because, when you think about it, the success side is pretty boring: you want to get to the next level. You could just spend most of your time failing, and it’s important that the failures are interesting, varied and primarily that you understand why the failure occurred.
Will Wright (2003)
Failure is an inevitable part of the gaming experience, but accounting for it is a detail too often overlooked by developers. And who could blame them? It’s much more interesting to think about cool new game mechanics or engrossing narratives. But as Will Wright points out, failure is every bit as important. Failure closes the interaction loop. No matter how interesting a game mechanic or story you have, it doesn’t matter if the player never experiences because they get frustrated and give up half-way through.
Thinking through the contingencies of failure for an interaction is an exercise of empathy with the user. Whether in videogames or more traditional UIs, framing development in a mindset of failure allows you to get in the head of the typical user and design accordingly.
Below are 2 examples of videogames that each approach failure in a poignant way. Together, they illustrate what I call 2 core mantras of designing for failure. By exploring the ways that these videogames deal with failure, we can learn a great deal about we can improve our own user experiences.
Team Fortress 2
In the overcrowded space of multiplayer first-person shooters, Team Fortress 2 really stands out. Between its innovative class system, meticulously-groomed collection of maps, and an unmatched focus on teamwork, TF2 gets a lot of things right. One of those things that I’d like to focus on is the screen you get when you die.
Being blown apart by a rocket, lit up by sub-machine gun fire, bludgeoned by a baseball bat, or being burnt to a crisp isn’t anyone’s idea of a good time. It’s a delicate matter to communicate to a user, but TF2 nails it:

There’s actually a lot going on with this screen.
First, the gameplay stops with a distinctive “whoosh” noise. With the frantic pace of a 24-person match, a break in the action affords the player a chance to step back and collect themselves. Beyond a visual cue that action has been suspended, this pause is a mental cue to reflect on what happened, so the player can understand how to not get pøwn'd next time.
Next, the camera zooms in to where your killer was when you bit the dust. This particular detail is something Valve talked about in their developer commentary: Testers sometimes had trouble understanding how or why they were killed. Especially in the case of a Sniper’s headshot from the other side of the level, for instance, it would be very frustrating to drop dead out of without adequate explanation. Thus, Valve settled on the aforementioned solution, to the chagrin of campers and griefers everywhere.
One of the most unique parts of this death screen is the “On the Bright Side” message that pops up from time to time. Just as zooming in to your killer added context of how you were killed, “On the Bright Side” adds context to your death itself. For instance, “You tied your previous record for kills this round of 4”, or “You stayed alive as Scout longer that round than your previous best”. As it were, this message recontextualizes death from failure to a form of success. Rather than be upset that you died again, you get recognized for things you did particularly well this time around.
Our insights from Team Fortress 2 leads us to the first mantra of Failure:
Provide sufficient context for the user to understand what happened, and learn how to improve in the future.
When we fail, much of the pain we feel derives from a lingering sense of confusion. “What the heck? Why did that happen?” Without properly communicating the situation, the player is unable to causally link their actions to the response. This can quickly lead to frustration, and ultimately cause the player to give up. When we fail, it’s not that we’re necessarily upset with failing itself—after all, in videogames, the stakes are pretty low. What’s really upsetting is when, because of a broken feedback cycle, we don’t seem in control of our own destiny.
World of Goo
Fueled by its critical reception and widespread distribution, World of Goo has become an iconic success story for the emerging generation of indie games. But more importantly, it shows how a strong concept combined with creativity and a great attention to detail can produce an amazing experience.
Each level of World of Goo challenges the player to build structures in order to reach a goal. How the player does it is up to them.
Game mechanics are introduced with new varieties of Goo Balls, like Ivy Goo, Balloon Goo, and Bomb Goo. These game mechanics are reinforced through different puzzles that explore the intricate ways that Goo Balls can combine and interact. Levels incorporate obstacles, like spike-lined chasms, mechanical automata, and hurricane-strength winds. All of these elements come together to keep gameplay varied and interesting, and in turn, make the player come up with new and creative strategies.
Sometimes, the solution is obvious, and it’s just a matter of getting there the fastest or with the fewest Goo Balls. Other times, things aren’t as clear, and it may take several iterations just to find something that works at all. Perhaps the worst, though, are the times when it’s clear exactly what needs to be done, but you just don’t have the finesse to get your goo tower to balance the right way.
For how challenging the game is, though, it never seems overly frustrating. Why this is has a lot to do with the way World of Goo mitigates failure.

In World of Goo, there is no Game Over screen. Rather, the notion of failure is recognized as being very distinct from Game Over. This touches on a fundamental truth of problem solving—that it is an iterative process; a process of constant failure, but also of constant learning. To expect the player to get it right every time undermines the spirit of the whole puzzle genre. If the player isn’t failing, it’s not really a puzzle, now is it?
Even though failure is inevitable, and indeed important, it’s important to recognize that not all failures are equal. For instance, certain levels in World of Goo have white “undo bugs” flying around on the screen’s periphery. Activating one reverts the last thing you did, making a particularly disastrous move not force a full restart. To that point of all failures not being equal, “undo bugs” allow for an acceptable level of inevitable human error to occur without taking away from the core gameplay experience.
All of this brings us to the second mantra of failure:
When possible, allow the user to understand that they failed without having to tell them outright.
It’s like that archetypical High School French teacher—the one who corrects every last word you say, and then makes you repeat the whole sentence again, once you’ve painfully managed to eek it out. Don’t be that High School French teacher. If not just for the fact that such an interaction isn’t so much fun, they’re also not that effective. Going back to the first mantra of failure, provide the player with enough context to understand what they’re doing wrong, and they’ll often correct themselves.
Of course, there are many more things to be said about failure. This is only a start to a conversation that I extend into the ethos of everyone interested in making user interactions better.
For a deeper appreciation of the role of failure in game design, be sure to check out the work of Jesper Juul, particularly his essay, “Fear of Failing? The Many Meanings of Difficulty in Video Games”. Other suggested reading includes a Gaming World article on difficulty and failure (which also cites Juul) and A Wired article by Clive Thompson on Peggle.
Great stuff. As another data point, I recently picked up Call of Duty 4. After completing the single player campaign, I hopped online last night to check out the much lauded multiplayer mode.
There are two failure-related touches that I think are pretty nice. One is the “Kill cam” (if I recall the name correctly). It’s similar to TF2’s deathcam, but instead of simply zooming in and freezing on your opponent, it plays back the last few seconds before your death from the point of view of your opponent. This allows you to not only see why you died, but also get a brief glimpse of gameplay from a (at least momentarily) more successful player. TF2, I suppose, also provides this learning opportunity between respawns.
Secondly, COD4 multiplayer is all about leveling up and unlocking new weapons and abilities. Even when you die, you get XP simply for completing a match, another way to keep the user involved, even when things are bleak.
Anyways, I shall be subscribing to this site with the expectation of more interesting articles like this!
[...] Game Over: Learning from Failure in Videogames – Game Design [...]
A nice post—I appreciate the thoughts on user interfaces despite not being a gamer myself!
This reminds me of some other scenarios: spelling correction, compiler errors, even 404 pages (see http://tinyurl.com/dyp5mg for some discussion on these and http://tinyurl.com/mascqs for proposals to make these more useful in Firefox). I’d say the most reviled interfaces are the ones which fail to perform as expected without giving a satisfactory explanation. Windows XP’s interfaces for networking come to mind as especially horrible in this regard.
More broadly, I recommend reading Aza Raskin’s thoughts on UI design: http://www.azarask.in/blog/
“Thus, Valve settled on the aforementioned solution, at the behest of campers and griefers everywhere” I don’t think behest means what you think it means. Try “to the chagrin of” or “to the disappointment of”
I don’t think the campers/griefers wanted it known where they were.
Thanks for pointing that out. I seem to get those mixed up every now and then.