Convergence: Theory into Practice

Pitching the Concept

KW: The game was pitched as a discipline-wide peer review supplement for all Bedford/St. Martin’s books. We had an author, up-and-coming game scholar Ryan Moeller; we had evidence, culled from reviews of other books, that instructors needed more peer review coverage; and we had a sense that games might be an important new genre for educational publishing.

Facing the Challenges: Budget

KW: The project was approved, but with a small budget. Peer Factor was seen as a pilot project, designed to help us learn more about how games could be built for the composition classroom. I attended the Serious Games Conference in 2006, hoping to find developers to work with. When I went around to the booths, talking up my project and probing for interested developers, they laughed at me. “You can’t do anything for under $100,000,” one developer told me. My budget was significantly less than that. In fact, I had about as much to spend on each of my game episodes as someone shopping for a pre-owned mid-sized car. In short, nobody wanted to work with me.

To make games a viable platform for English Composition, we had to find ways to produce them at costs that were in line with typical media projects. I found inspiration at one of the Serious Games Sessions I attended. It was entitled: You Can’t Change History! How Games Require us to Rethink What and How we Teach. In this session, Andrea Lauer and Nick deKanter presented LauerLearning’s Freedom Fighter ’56. Their game used still images and a graphic novel aesthetic to immerse players in the events of the Hungarian Revolution in 1956. Students interacted with the narrative in ways that were pedagogically, but not technologically, sophisticated. Freedom Fighter ’56 accomplished its goals in a smart way, without relying on expensive 3D graphics or complex interactivity. That presentation was my ray of hope in an otherwise discouraging first foray into the world of game development.

The Game Design Document

KW: Because I was a complete newbie to the game design process, Ryan sent a Game Design Document and suggested that we fill it out. Parts of this template corresponded to the Project Description Document I put together when proposing a new project. My project descriptions outline the concept, the market need, the competition, and other particulars of the project like budget and schedule. The Game Design Document also had sections that were equivalent to the Request for Proposal documents I send to designers and developers for estimates, and to the Technical Specifications documents that I prepare for developers. The technical specs document includes wireframes, storyboards, and functional specifications for all aspects of the digital product. For the most part, I understood the purpose of the Game Design Document and I had some established development practices that mapped to game design. I was comfortable imagining and outlining general features, feature sets, user interface, characters, and story. But the Game Design Document also asked me to specify game formats and functions that I had little experience with. Things like: game play, the game world, key locations, travel/movement in game, scale, objects, time, camera (movements and angles), game engine, game characters, enemies and monsters, musical scores and sound effects, sound design, single player game, hours of game-play, and victory conditions.

Some of these unfamiliar territories also struck me as foreign to how we conceptualize traditional learning tools, but maybe they shouldn’t be. When I began to think deeply about each of these game features, I realized that they weren’t just good for gaming, they were good for learning. I’ll give you one example, “enemies and monsters.” Monsters are an essential force of resistance in most games and overcoming them adds to the challenge and satisfaction players feel. The little green monster who makes a cameo in Peer Factor, represents the student’s peer review fears. When the player shoots him down (clicks on him), s/he gains ten points and is treated to a hint for coping with typical peer review anxiety. Other forces of resistance in Peer Factor include: unhappy facial expressions that register with bad comments, the chorus of “awws” a player gets when a low scoring choice is made, and low goodwill meter readings. These mechanisms allow players to feel the sting of poor performance in a private, mediated way. In short, the “enemies and monsters” feature in games provides a convenient and playful mechanism for externalizing the emotional aspects of learning: the resistance, the anxiety, the monsters of learning.

The game design template Ryan loaned me was a useful starting point, but it was set up for entertainment games. Learning games have different goals and outcomes. Development would have gone more smoothly if a template, geared specifically to learning games, was available. If such a template existed, its opening section would ask designers to state the learning goals and outcomes. These objectives would serve as a baseline for decisions about each feature. The document should help designers figure out how each feature engages the player, and how each feature teaches the player. The learning game design document should also include a section for ancillary materials. Keeping in mind Henry Jenkins’ directive to think of the game as the beginning part of the process, designers should plan materials for the learning that will take place around their game. (2006)

RM: All games teach. Period. Even at the most basic level, games teach players how to play them. I was never concerned that our game wouldn’t teach players something. Rather, I was more concerned with how our game would teach players something useful and in a way that was fun and engaging.

The most difficult aspect of the design document for me was designing the game script and player dialogs with very little to go on in terms of what the game would look like, sound like, or play like. We were given a great deal of latitude within the narrow confines of the budget to create the game that we wanted to create; however, at the time we created most of the design document, we had not yet located an interface designer or a developer. I remember coming out of one design meeting in particular, being extraordinarily depressed after reviewing pages and pages of dialog that did not capture the aesthetic qualities of a game. It didn’t yet feel like a game. It felt more like a choose-your-own adventure book than a game.

So, I think that it is important that educational game development remain a highly collaborative project. I could not have created the game script without our shared vision of what the game would look like, sound like, and feel like to play. In the software and entertainment industries, design documents are the structural glue that gives a design team a cohesive goal and documents any developments on the project to date (see Ryan, 1999, for example). I try to teach my students that design documents should be central to any team effort, and they should be continually updated and revised. After working on this project, I still think this is true. We had many different people working on this project, and they were all coming at it from different perspectives. The design document kept us communicating with one another productively. Rather than changing the particular template for educational game design, I would recommend that educational design teams work together earlier in the design process so that different elements of the game—from the interface, to the gameplay elements, to the script—mutually reinforce one another throughout the design process.