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.
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.