Gamasutra: The Art & Business of Making Gamesspacer
The Importance of Being Buggy
Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 24, 2014
arrowPress Releases
April 24, 2014
PR Newswire
View All
View All     Submit Event





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


 
The Importance of Being Buggy
by Greg Pollock on 06/08/13 03:25:00 pm   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.

 

Bugs are the bane of the business of software engineering. They cost time and generate fruitless conflict between programmers and bean counters (which in turn wastes more time). I happen to be one of those bean counters, and it makes me mad as hell to see even more of my beans disappearing without getting a better game to show for it. 

Despite all that, I want to argue that bugs offer a valuable kind of input to the game creation process. I came to this view in part from working as a designer and producer on games, and in part from Thomas Kuhn's analysis of knowledge in The Structure of Scientific Revolutions. Instead of sighing and wringing my hands over a roadmap as soon as I see something unexpected, I ask what a different game would look like where the mistake was instead correct.

Fifty years after it's publication, I still find Kuhn’s thesis shocking: that the normal practice of science does not change our understanding of the world. Normally, a scientific experiment should only confirm that what you know is true. At most, a normal scientific experiment should demonstrate that you can do new things by applying those rules in a slightly different way. Facts that don’t fit your paradigm are either considered special cases, to be described by a subset of rules, or research problems to be solved in the future.

Kuhn advances this view of science for a few reasons. First, it is necessary for science as a community of practice to be cautious about overturning its foundations. Second, humans tend to fit new facts to existing paradigms. Third, the historical record of scientific revolutions shows that scientists have held onto mistaken views—that fire was made of phlogiston or that outer space was filled with aether—despite being aware of the experimental evidence that would become the cornerstones of later scientific paradigms. 

I find Kuhn’s view both inspiring and dispiriting. The keys to massive, paradigmatic leaps of knowledge could be already among us, ready to be discovered by someone brave enough to question everything—and at the same time, these are rare crisis events that we are strongly predisposed to avoid. (David Hume made a similar argument in his proof against miracles: a miracle by definition defies your understanding of the possible, and so either indicates a mistake of perception or reshapes your concept of the possible). 

I try to keep Kuhn’s lesson in mind when I inevitably encounter bugs in a game I’m working on. Some bugs are not the kind that can lead to productive knowledge, just like not all scientific accidents can lead to breakthroughs. There is such a thing as simple error, and you fix it and try again. But other bugs have forced me to rethink my vision of a game by proposing alternatives that no one around me had considered. 

Two examples from my most recent game can illustrate the benefits of a skeptical openness to bugs. The game involves two players placing mines that will be hidden from their opponents and which each player will try to avoid (like Stratego). One problem was that a player could run through the opponent’s map, find the mines, then force quit the app and the round would be reset when they returned. This forced us to consider the question: having experienced the mulligan, should players be able to purchase a re-do? We decided this was abusive and not fun, and so we introduced security measures to prevent it. 

Another bug caused undetonated mines to carry over between the three rounds of the game. This happened to solve a problem we had been struggling with. We wanted some kind of “rubber-banding” so that players who lost the first round would have a slight advantage later, resulting in more contested and exciting finales. But since both players have full knowledge of the others’ turns (we show a replay of how your opponent fared), there was no way to sneakily give an asymmetrical advantage without explicitly cheating on one player's behalf. Preserving mines had the effect of giving an emergent advantage to players who killed fewer runners with mines in the first round. It also introduced new meta-strategies around hiding your mines to intentionally hoard them—an unusual tactic, but one that played into the game’s overall concept of anticipating your opponent. 

Both of these examples could be considered not to be true “bugs” in that they didn’t prevent the game from working—they are more like incomplete implementations than faulty ones. The lesson of Kuhn’s work, however, is to question what it means for a piece of software to “work,” and so question distinctions about what “really” is a bug. The biological concept of stress, for example, was discovered because Hans Selye was so bad at working with his lab rats that he drove them to produce stress hormones no matter what substance he injected into them. The data he gathered was worthless for the experiment he was running—from that perspective it was all noise and no signal—but gave a view onto an entirely different way of conceiving the body’s disposition to illness. I try to maintain this view of bugs: even if they present as the complete negation of what we’re working on now, maybe they are the inkling of something radically bigger to come.


Related Jobs

SG North
SG North — Toronto, Ontario, Canada
[04.23.14]

Director of Live Production
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[04.23.14]

Associate Producer - Treyarch
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[04.23.14]

Production Coordinator (temporary) - Treyarch
Vicarious Visions / Activision
Vicarious Visions / Activision — Albany, New York, United States
[04.23.14]

Software Engineer-Vicarious Visions






Comments


Craig Hauser
profile image
Let's not forget something like "canceling" in the Street Fighter series was also, at first, a bug. Now it's a staple of almost all modern fighters.

I wish more of _my_ bugs were like that. Alas, mine are almost always of the "falling through the floor" variety.

Michael Herring
profile image
"Expected results: Gun should fire. Actual results: Game crashes."

"Let's find inspiration in some other bug."

Joel Bitar
profile image
More famous "feature bugs": The movement systems that gave old-school shooters like quake and tribes the depth needed to be fun in the long run were all unintentional, strafe jumping, rocket jumping, skiing etc. They were of course also later included in the sequels on purpose, (although carmac really hated the idea of strafejumping in quake2).

Jay Anne
profile image
Good insight. We used to systematically create artificial bugs in that sense, where we had a system to randomize in-game values to safely create some of these same conditions, mostly for fun, but also to explore assumptions.

Luis Guimaraes
profile image
The air combo in DMC was also a bug first, that the animation wouldn't let the player fall while attacking in mid air.

tony oakden
profile image
As Joel says, Skiing in the original Tribes is a great example of a bug which became an important feature of the game when the devs discovered how much fun it was.

I think this is one of the big advantages small indie studios have. When something unexpected happens in the build it's relatively painless to examine it and see if it's got potential. In a big team the response tends to be "that's not right... Kill it!"


none
 
Comment: