Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
May 19, 2022
arrowPress Releases
If you enjoy reading this site, you might also want to check out these UBM Tech sites:

MIGS Keynote: Gingold/Hecker On  Spore  Prototyping

MIGS Keynote: Gingold/Hecker On Spore Prototyping

November 8, 2006 | By Bonnie Ruberg, Montreal

November 8, 2006 | By Bonnie Ruberg, Montreal
    Post A Comment
More: Console/PC

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.

Related Jobs

Remedy Entertainment
Remedy Entertainment — Helsinki, Finland

Lead Gameplay Animator
Remedy Entertainment
Remedy Entertainment — Helsinki Metropolitan Area, Finland

Senior DevOps Engineer
Build a Rocket Boy Games
Build a Rocket Boy Games — Edinburgh, Scotland, United Kingdom

Lead Graphics Programmer
Disbelief — Chicago, Illinois, United States


Loading Comments

loader image