Ways To Screw Up Preproduction

Here's the Reader's Digest version of the talk I gave in Singapore.

Preproduction and prototyping used to be considered dangerous and risky - make the game already! was the money-guy's cry - now, as far as I can tell, it's an industry standard practice.  I've seen how effective a good, long prototyping phase can be with Spider-Man 2 - so I endorse the change. 

Still - there's a lot of ways you can screw up prototyping. 

Here are some things not to do with your preproduction phase:

Use it as an excuse to coast or slack

Preproduction can turn into slack-time for a couple of reasons:  one would be because it's the beginning of the project, and it seems like you have all the time in the world.  The other would be because it can become a "fuzzy front end."

You need to timebox your preproduction.  If you're inventing some kind of revolutionary game mechanic, you should have a rough draft in 1-4 weeks.  You should have something promising in 2 months.  You should have an actual game you can kleenex test in 2-3 months.  You should have something you'd be willing to show executives in 3-6 months.  Or sooner.  On Spider-Man 2, we hit that timetable--and lots of guys were putting in voluntary overtime to do it--and we came up with something loved by many.

There's a corollary here, which is you can't write an engine from scratch if you want to hit these time tables.  Mark Cerny suggests "dual tracking" it - one team prototypes using the old engine;  the other team refactors the engine, but keeps it backwardly compatible so you don't lose too much of that prototyping work.

 Throw your prototype away

The immortal words of Fred Brooks "Build one to throw away."

I'm pretty sure these immortal words were wrong.

But here we get into semantics.  There are your "proofs of concept" - one of your quick iterations with placeholder graphics and whatnot, with levels that are "grey mesh" or "orange mesh" or "sheet" or whatever you call it at your studio - and then there's your release-quality "prototype" or "vertical slice."  You throw your POC's away - your vertical slice should be kept around, and one day go in the box (with changes, sure, but basically the same thing).

Why not throw it away?  First of all, it's probably got half an hour to an hour of gameplay in it.  If you throw it away, your game will be half an hour to an hour shorter.  Second of all, when you throw it away, you jump headfirst into the dead zone.  You go from having some game to show and iterate on to nothing. 

For example, on Spider-Man 2, our first E3 demo was our vertical slice.  A lot of it was smoke and mirrors, and a lot of it changed, but it basically went into the box. 

Have extended preproduction on an evolutionary, rather than revolutionary, sequel

If you're making a Tony Hawk 2 out of a Tony Hawk 1 do you need to do prototyping?  Sure, if you're adding something new, but that work can be done in parallel with constructing levels that use the same mechanics as the previous game.

Let People In Power See The Prototype Before It's Ready

This is something Mark Cerny warns us about:  "The Stench of Failure" - if you show off your prototype too soon, you create a first impression that will be nearly impossible to shake.  Word will spread, morale will plummet, you'll have to kill it.

Something I learned the hard way is that it's not just executives who can create the stench of failure:  if you're on a big team with multiple prototyping efforts going on simultaneously, anybody who's not working directly on a given prototype can create the stench of failure if they see it before it's ready.  They may check it out with the best of intentions - "We're going through everybody else's prototypes and providing feedback" - but a prototype that isn't ready isn't ready.

I had to kill one of my own prototypes because of this - to this day I don't know if we could have made it work or if it was just a plain bad idea.  If I'd managed to control access, or, once "feedback" was given, I'd told those helpful other team members to keep their mouths shut to the rest of the team, maybe the prototype would have gotten a fair shake.

It's Not All Doom & Gloom

All that said, I am a super-huge fan of prototyping.  Sure, sometimes full production gets short shrift because you spent too much time working on the core gameplay - but I'd rather have that core gameplay than a polished turd.  And sure, sometimes you have to kill a questionable idea that might have worked - but without prototyping, you never would have tried that idea at all. 

Time and again I've seen a quirky "nobody believes in this" idea gain momentum and turn into something great simply because someone sat down and spent a week or three making a rough draft.

A screwed up prototyping phase is better than any Big Design Up Front phase.

Comments

[Darius K.]

I would slightly rephrase "Let People In Power See The Prototype Before It's Ready". In particular, I think a prototype is a rhetorical tool as much as it is anything else. Just like you would word an email to the CEO differently than you'd word an email to your co-worker, you would also not show the same prototype to the execs as you would to the team. It's all about (1) understanding your audience and (2) controlling who your audience is.

[Pag]

Great post! But, to be nitpicky, shouldn't it be called "Ways to Screw Up Prototyping"? For me, preproduction covers a lot more than just a prototype: game design writing, choosing a art style, overall planning and so on. It's the phase where you plan what you're going to do before you actually do it. Or is my definition broader than the usual one?

[Jamie Fristrom]

Not nitpicky at all - yes, preproduction is a larger set than prototyping - still, items 1, 2, and 3 are ways to screw up the whole enchilada. 1 & 3 are obvious, I think - and with #2 I'm really talking more about a 'vertical slice' prototype than a rough-sketch prototype, one of the things you end up with at the end of prepro. And shouldn't discard.
Seems obvious but I've seen it happen.