Game prototyping is all the rage these days. Chaim Gingold and I gave a fun lecture at the 2006 Game Developers Conference titled, Advanced Prototyping. The material is based on our experience prototyping games, technology, and user interfaces for Spore and at the Indie Game Jam over the past 4 years. Here's the abstract:
Creating effective prototypes of game designs, user interfaces, and technologies requires a unique set of skills and knowledge, somewhat distinct from the skills used in making a game. This lecture discusses creating these various types of prototypes from an advanced and in-depth perspective. The talk goes through a number of important questions and topics that should be addressed before, during, and after the prototype is created, including metrics for judging the effectiveness of prototypes, how to decide the focus of a prototype, how to design, start, and build the prototype, both from a content and a code standpoint, and how to iterate the prototype via testing and integrating feedback. Various approaches to these issues are compared and contrasted, with the end goal of teaching attendees how to create successful and high quality prototypes.
It's in the new fangled presentation style all the kids are doing these days, which means it's basically useless without hearing the audio, so:
One idea in the talk I want to call out here is the Tower of Tuning. We defined the various levels of tuning as, from top to bottom:
- scripting language - add another language into your game
- hotloading - reload the variables when the file changes
- data driving - variables in a file
- interactive editor - sliders, hotkeys, and the like to change the variables
- recompiling - just variables in code, trivial, doesn't scale, but doesn't always need to
Some people like to ascend as high as they can on this tower, thinking that a scripting language is the ultimate flexibility. We disagree. You want to be a low as you can on the tower and still get your job done efficiently. Each step up the tower adds systemic complexity to your project, so don't take it until you need to (for example, long compile times force you to make interactive editors, long load times force you to hotload, etc.).
We gave the talk again at the 2006 Montreal International Game Summit, and then once again at Ubisoft after that conference.
The GDC version went off really well—I was incredibly happy with it. The MIGS version was fine, but we felt it was a bit low energy in comparison, and we were kind of bummed that we ended on a relative low note. But then, immediately afterwards, friends at Ubisoft Montreal invited us to give it again at their office, and that version turned out to be the best of the three. I think we spent 1.5+ hours and made the presentation totally interactive.
We changed a few minor things for the later presentations. The two worth mentioning are:
- We changed two of the intro slides to reflect the current thinking on the production process, where prepro is split out into discovery and preproduction, and we talked about how prototyping is most useful during the first three stages:
- We mentioned one new additional metric at end, which is how often is your prototype referred back to in the archive? If nobody ever looks at it again, then either it was answering a really simple question and completely answered the question, full stop, or it maybe wasn't as useful at answering questions as you originally thought since nobody felt the need to use it to clarify or remind people of the solution.
There was some press and blog coverage of the talk:
One of the meta-goals of this talk was to learn what makes a good two-person talk. You can see the lessons we learned here.