Author: by Bonnie Ruberg, Montreal

Chaim Gingold and Chris Hecker, both of Maxis/Electronic Arts, ended the first day of the Montreal Games Summit with their keynote on advanced prototyping. Because they had a lot of ground to cover in a short amount of time, Gingold and Hecker spoke quickly and energetically. They are currently working on Spore alongside Will Wright, and used examples from the game’s development process to illustrate both good and bad prototypes. Prototyping For Dummies Gingold and Hecker began their talk by pointing out the steps in the creation of a game: having an idea, discovering what you’d like to do, pre-production (how you’re going to do it), developing, and selling. Prototypes, they say, can be very helpful in the first three of these five steps. To be useful, however, such prototypes need a clear hypothesis. Once a hypothesis is established, a prototype can answer crucial questions, reveal up sides and down sides to an idea, and persuade others that your idea is a good one. Some of the qualities Gingold and Hecker identify in a good prototype are cheapness, agility, lightness, falsifiability, testability, relevance to the game at hand, generalizability, and surprisingness. Your prototype should be persuasive and fun. As Hecker says, “You should have to kick people out of your chair... If someone sits down and wants to play, you win.” Design Docs? Just Say No! Gingold and Hecker do point out that often it’s tempting to write a design document to put forth an idea instead of actually prototyping. But they warn that such documents are boring, static, and take a leap of faith. With a prototype, says Gingold, you know what works; with a document, you’re just hoping your design will fly. Prototypes, on the other hand, clearly answer the “will it work?” question. As Hecker shows off a prototype for leg movement in Spore, he remarks, “You know this is successful, because everyone in the audience wishes they could come up here and use it. It’s hot.” Prototyping takes time, so Gingold and Hecker suggest ways to get around a length process, including “stealing:” seeing how certain elements you’d like to use have played out in other games. They also recommend using programs like Maya to get around unnecessary programming. In terms of time, they have a policy of permission vs. forgiveness. You need to be prepared to fail early – but that’s okay! If a prototype takes less than two days, don’t worry: just go ahead and do it. It if takes more... you should probably have permission. Decomposition For Evolution Gingold and Hecker point out the importance of “decomposing” your problems: breaking them down into smaller and smaller problems that could be addressed most beneficially in specific prototypes. In order for your prototypes to be efficient, they also recommend minimizing any material that it’s crucial for testing your specific question. For example, Gingold and Hecker were testing creature designs for Spore, and placed test creatures in a world of flat terrain. However, in-game, these creatures will move on a slightly curved plain, namely a small planet. But, by creating a representational wire-frame planet mock-up, they were able to see the difference was insignificant. One of the hurdles Gingold and Hecker recognized for prototyping is budget. They graphed the relation between quality and cost, and showed that, to move from a “good” prototype to an “awesome” prototype, you have to put in a lot of money for, proportionally, not much result: their point being prototypes don’t need to be perfect, they need to balance effectiveness and efficiency. As far as programming goes, they recommend ignoring traditional rules. Agility and velocity should be the standards here, not robustness or elegance. They also advocate collaboration between designers and programmers, who can create a feedback loop of inspiration as well as checks and balances. Conclusion In conclusion, Gingold and Hecker show that regular prototyping actual helps streamline the development process, even if it initially makes you feel less “independent.” It’s also important to keep an archive of your prototypes. After all, the best prototypes, they say, are the ones you can refer to again and again as you work your way to a finished game.