This semester I was on the Smoking Duck Squadron team creating our awesome Flash game, “Nightmares”. My primary role was everything art-related: art direction, art assets, the works. The outcome of our sweat, tears, and lack of sleep is a beautiful game that recreates the experience of a child trying to defeat his or her nightmares. My team worked really well together, and I couldn’t be more proud of the work we put out.
The initial challenge of designing a game – and the game’s core mechanic – was a problem that we met head-on multiple times. Everyone on the team participated in brainstorming and contributing to the game concept, and the first thing we knocked out was the idea of recreating the world of a child’s nightmares. Ideas were in no short supply in the Squadron; in fact we had to check each other multiple times from getting too conceptually creative. We found it more difficult, however, to nail down one main game mechanic that would make the game fun to play. Zimmerman’s explanation of iterative game design in “Play as Research: The Iterative Design Process” describes a method of game design that quite neatly fits the techniques we used. He describes the process of design as creating, testing, analyzing, and refining. In the beginning of our design process, we would meet for a couple hours a week and just come up with lists of ideas and flow charts outlining how the game would work. We took pictures of our ideas, typed them out, posted them online for our future reference, and basically just let them sit in our minds for a bit. The next time we met, we would playtest our ideas in a couple different ways: we would play out a level verbally and pictorially by talking and drawing pictures on a white board illustrating how the game would play out, or we would do paper-and-pencil playtesting on a table, using bits of differently colored paper and pipe-cleaners to represent baddies, heroes, and platforms. Every single time we discussed our ideas and did further playtesting, we would tweak (or, perhaps once, completely revamp) our mechanic. At first I was worried that this meant we were just having a hard time sticking to our plans, and that it would mean indecisiveness all the way through the process, but Zimmerman actually recommends this kind of iteration. According to him, even though game design is about creating a set of rules for others to follow, the purpose is not to create an experience based on rules, but to create an experience of play. The emergent fun of a game is not something that can be exactly predicted, and therefore it has to be experienced to some extent before concrete decisions about the quality of a game product can be made. What I didn’t realize we were doing until now was iterative design. Thank goodness for our “indecisiveness”!
Once our mechanic was decided upon (a sweet-ass “lucidity” bubble created by our fantastic programmers that represents the amount of dream self-awareness the player-character has in-game), the more physical design process began. We went through a lot of trouble figuring out which game engine we wanted to use as well as which IDE to code the ActionScript in. Once we discovered that our ideal game engine, the Citrus Engine for Flash, was available for free for students, we started knocking out code and art assets. This might have happened in the wrong order, but it was only at this point that we asked ourselves: How do we want to teach our player how to play the game? One of the aesthetics that we really wanted to stick to was to use as little, if any, text as possible, and to avoid heads-up display elements whenever possible. Our self-imposed challenge was to figure out how to teach the player the rules of the game without actually writing out sentences. Don Norman’s essay, “Affordances and Design”, outlines a few rules of thumb for interface design that I think we were intuitively following. Or perhaps it was the result of our excellent training as designers, provided by Ian Bogost and Celia Pearce. Either way, Norman coined the term affordance as a relationship between a user and a world or interface that communicates the ability to perform some action. The goal in any design job is to match up the user’s perceived affordances with the true abilities of the object or interface, so that the user is always able to figure out how to use an artifact without getting confused or frustrated. The first rule of interface design according to Norman is to “follow conventional usage”. I think it’s safe to say that our team has played a few video games between us *cough* and so “conventional usage” to us means to design a game along precedented lines. There is a convention very popular among our community of conveying the rules of a game pictorially rather than verbally or orally. This method was used very well, and very popularly, by “Portal”, developed by Valve Corporation. In “Portal”, the instructions for the different game mechanics are illustrated on the metal walls of the game environment as a series of restroom-esque figures. We decided to emulate that design in “Nightmares”, and the public response was fairly positive. While we had to tweak our illustrations a bit in order to make them more clear or timely, in the end I believe they worked out pretty well. Other game mechanics in “Nightmares” were decided upon based on what we believed to be the cultural conventions of our time. Baddies should be able to be eliminated after jumping on their heads as well as with an “attack move” in traditional Mario-style, for example. This rule of “conventional usage” as we chose to implement it directly conflicted with another of Norman’s rules however: “use words to describe desired action”. This rule is to ensure that interfaces are as easy to understand as possible, and text is often the most straightforward way to convey direction. In our case, I believe the affordance of pictorial instruction as used in video games overrides the requirement of verbal clarity. For stylistic purposes, among others, my team certainly decided that it did.
The artsy aesthetic goal of our game called for a very particular kind of visceral response. As a recreation of a child’s nightmare, “Nightmares” is supposed to make the player feel perhaps nostalgic, perhaps a little creeped out, hopefully a little joyously anxious. The game art is supposed to work with the game mechanic in equal parts to create this feel, and I believe they do a decent job achieving that. Nicole Lazzaro outlines four key ways game designers invoke emotion in their games without using the storyline in her paper “Why We Play Games: Four Keys to More Emotion Without Story.” The third key rule is using “altered states”, otherwise known as toying with thoughts, perceptions, and human behaviors to create sensation. The music and sound effects in the game establish a creepy, dreamy expectation, and the sight limitation creates an anxiety that mirrors the fear of the unknown in a dream. Many in-game experiences in “Nightmares” are meant to recreate real-life memories and emotions, and the perception of that link by the player means the success of our game design. Lazzaro also describes certain differences between general computer interfaces and games in “What’s My Method? A Game Show on Games”, one of which is the difference between the extrinsic value held in a program that is supposed to help the user achieve something in particular, and the intrinsic value of playing a game for its own sake. “Nightmares” is definitely an intrinsically valued experience. The player probably won’t learn anything new or produce new artifacts or have spectacular insights after experiencing the game. Instead, we hope Nightmares makes the player remember, reflect, and enjoy a phenomenon that they had probably previously forgotten about. If we can a player take a startled jump that brings back memories of their childhood fear of the dark, then “Nightmares”, in my book, is a wild success.
Lazarro, N. & Keeker, K. (2004). “What’s My Method? A Game Show on Games.” In CHI 2004 Conference Proceedings, April 2004. http://www.xeodesign.com/whatsmymethod.pdf.
Lazzaro, N. (2004-2005) “Why We Play Games: Four Keys to More Emotion Without Story.” Self-published white paper. www.xeodesign.com/whyweplaygames.html.
Norman, D.A. (2004). “Affordances and design.” http://www.jnd.org/dn.mss/affordances_and.html.
Zimmerman, E. (2003). “Play as research: The iterative design process.” http://www.ericzimmerman.com/texts/Iterative_Design.html.