Casually Hardcore devlog

On prototyping…

August 24th, 2008

Chris Hecker and Chaim Gingold spoke at GDC 2006 about prototyping and I’ve only recently discovered it. I wish I had read it before I began my prototype because they discuss some gnarly issues I’ve encountered.

The powerpoint slides and MP3 audio are available here, but I’ll summarize the juicy bits.

1) Game Design Documents are truly useless in answering questions about a game like “Will it be fun?”

And that’s why we always need to prototype - to answer some hard questions scientifically (rather based on hunches). I completely agree with I’ve tossed large parts of my original GDD away because the GDD was based on speculation on what would be fun/easy/simple/understandable - half of which was wrong.

2) All prototypes try to answer hard questions so those questions should have yes/no answers that can be falsifiable. There is no point in asking a question that can not have an answer.

- Can this cooking game mechanic be made compelling?
- Can the player control driving a car using a video camera (i.e can the player deal with video processing lag)?

One thing Hecker + Gingold emphasize is failing early. The prototype’s goal is to answer the question as quickly as possible.

Quick == Cheap
Cheap is good!

3) Cost vs. Quantity… due to economics you can not just create a prototype will full-art and gameplay and in the end you DO NOT WANT TO. Hecker and Gingold talk about answering questions as CHEAPLY as possible - steal, use existing art tools, mock stuff up, etc… anything to avoid actually building a prototype with code + art.

Now, eventually you will need to program code and create art - the question is how much of each?
They say code is VERY EXPENSIVE and non-linear as you will need to build an engine, physics, rendering, input, etc. even before any “prototyping” begins. The cost of content is flat throughout the prototype (and game). It can contribute to answering the prototype’s question from the start.

They argue that content is preferred over code - that means trying stuff in Maya or Max or an art tool first. In my prototype, I’ve spent far too much time building tech and too little on the gameplay / asking-answering questions bit. Code is necessary in my specific case, but I should not be building scripting systems or anything that is more technology than necessary for the prototype:

The reason why you still need to code is to answer some technical questions like… Can I get 30fps with 1M polygons on the screen?

Their rule is “Only spend code where you need understanding; throw content at the rest.”

In my prototype, I needed answers to some hard physics questions that could not be answered using Maya-based art mock ups. I also had some critical pipeline and schedule/timeframe questions that if the answers were negative would have killed the project immediately. Remember, fail early!

Entry Filed under: Game Development