In the last 18 months, it has become rare to hear someone say “prototyping” without it being adjacent to either the word “rapid” or “iterative,” or (for that matter) “rapid iterative.” I see that “rapid prototyping” generates about 1.6 million Google hits, whereas there are exactly 589 for “slow prototyping.” The prototypers have spoken.
During the development of our game Schizoid, we accumulated more evidence (the hard way) that rapid prototyping is the best method of creating innovative game-play. This was not surprising. But at the same time, we also found (probably belatedly) that there’s a second reason that speedy rapid prototyping is important: Speed saves prototypes—and in turn, therefore, it can save projects. (If “speedy rapid prototyping” sounds redundant, a more detailed description might be “rapidly-iterative prototyping that quickly proves its point.”)
Design Documents Stifle Innovation
I don’t think I’ve talked to any developer in the past five years who has said that the key to innovative game development is writing—and then executing—a thick, monolithic game design document. In contrast, the buzzwords—actually buzz-bullet-points—I’ve heard in the last couple of years have been:
• Try a tiny prototype to investigate a new game-play idea. If it’s fun, plan tentatively to use it, and polish it up and improve it a little bit next week. Repeat until you get Peggle. If the idea isn’t fun, then either make it more fun in the next week and try again, or throw it away and try something else; you have avoided a path to boredom, and it didn’t cost you much to learn to avoid that path.
• Agile development methods like Scrum are really good for this. Work in short sprints, making immediate adjustments to the previous day’s work, and operating off of a two-page to-do list. And you should adopt this philosophy of embracing frequent change, using a rapid-prototyping philosophy on most components of your game project, for nearly the entire time you are developing the game, up until you really freeze the features and go into final QA.
• You can’t design the fun of a video game in advance on paper. As you create parts of the game, unexpectedly fun interactions will appear occasionally. The team should pounce on these—because each unexpectedly fun part of the game might expand to be a larger part of the game, or even end up being the focus of the whole game.
These are the now-standard arguments on how to innovate in games. Each has significant downsides. From the viewpoint of trying to create an innovative game, the worst downside is that as an independent game developer, it’s generally not possible to do any of the above. For the past 15 years, publishers have required that thick, monolithic design document (as opposed to Design By Rapid Prototyping) for several well-intentioned reasons:
• A publisher wants to force you to think through the consequences of your design decisions. By writing down the details of the scoring system before you’ve started coding, you may realize, for example, that the scoring system requires the Reflex Detector system, which you forgot to write into the schedule. (Even so, I’d argue that designing the scoring system up front is a pure waste of time since at design-doc time it’s not even clear what the score should measure.)
• The publisher simply wants to see and understand what it is paying for. “Is this game we’re buying more like Doom 3, or Castle Wolfenstein 1 (on the Apple II version)?”
• The producer has a sneaking suspicion that you are planning to pocket three-quarters of the advances and use the remaining one-quarter to pay one subcontractor and a few college interns to slap together a game that’s barely sufficient to satisfy the milestone definitions. The big design document may protect against this, the producer hopes, and robustly!
Another aspect of the thick design document that affects innovation is this: The publisher usually tries to incorporate that document into your contract. When stuff from the design document gets changed, simplified, or—horrors!—cut altogether, a cranky individual at the publisher can (and probably will) point to the contract, explain that you are in breach, demand a reduction in your percentage of ownership, and otherwise lean like hell on you. Some managers at publishers look forward to this.
The drawback, of course, is that the standard, written-up-front design document stifles innovation, all attempts to refer to it as “a living document” notwithstanding. The first problem is that such a document implies that you can chart a year in advance the wisest course for a project to which you will make minor course corrections on a daily basis. In addition, since the delivered game is supposed to reflect the thick design document that’s embedded in a contract, your own management will actively resist changes to what was written in the original design document. The issue is that every design change thus becomes a change to the contract—which usually requires either fighting or begging the publisher.
The implication of all this is that the large game publishers are only going to get innovative game-play from: (a) internal teams that use rapid prototyping throughout most of the project, and are given a long leash to do so; and (b) external developers who somehow have the cash to develop innovative prototypes on their own, without any detailed top-down design requirements. Both of these paths can be hindered by The Big Design Document.
Speed Saves Prototypes —The Schizoid Case Study
I don’t think it is overstating it to say that “rapid iterative prototyping” is principally responsible for the creation and survival of our Schizoid project. In fact, due to its innovative game-play, it was the speed of its development that saved Schizoid from almost certain death.
When Jamie Fristrom, our technical director, came up with the original idea for Schizoid, we were spending a lot of time pitching publishers on various projects. We spent a lot of time writing short design treatments, scheduling, and budgeting. Jamie had an idea for a game in which the two thumbsticks on a console controller would control two separate heroes, and he wanted to take some time to prototype it. “Sure, go for it,” I said, but I was uneasy about whether this was going to be a wasted couple of weeks when we could have spent more time improving our time and budget estimates for our proposals.
While looking for, you know, rapid iterative prototyping solutions, Jamie had the good fortune to happen upon XNA Game Studio by Microsoft. He created a prototype using programmer art (or, “fancy X’s and O’s,” if you will) in four days. This was enough to get us excited about the game; then we got some friends excited about the game, then game designer Richard Garfield suggested this would make a great co-op game, and things snowballed from there. One idea led to another, as they say, and within eight weeks we got a pretty nice prototype in front of Microsoft, who greenlit the project for publication on Xbox Live Arcade.
The important thing about all that, I think, was those first four days. What if Jamie had taken two weeks to make the prototype? At what point would I have started asking him about when he thought he’d be done? How frequently would I have nagged him about it? How soon would I have told him to drop the prototype and move on to something else? In hindsight, Jamie should have taken whatever time he needed in order to get Schizoid going; but prototyping innovative game-play is speculative, and many prototypes are awful, including many based on great prototype ideas. How long do you want your best people putting their efforts toward something that has less than a 50% chance of panning out? There are a hundred other tasks they could be performing in order to help you ship product, and isn’t shipping product the core of the business? It’s hard for managers to stick with having their best people do speculative work. It’s different when you’re dealing with a knock-off of some game whose critical reception, strengths, and flaws are well understood. When trying out an innovative idea, though, there’s simply no way of knowing how it will turn out without creating it.
This experience has convinced me that half-measures are the death of prototypes—or at least, of prototypes that are intended to prove innovative game-play. Such projects really do have to have your best people on them, equipped with tools that will lean on speed of development over any other factor. In our case, XNA Game Studio was a great big help because it provided a game framework that was ready to go, and because coding in C# is much faster than coding in C++—especially if you’re prototyping and don’t have to spend any time optimizing for performance.
Any considerations other than speed of development need to be de-prioritized as much as possible. Don’t tell your engineers that, to save time in the full game’s schedule, it’s important to build a sturdy framework upon which the entire game can eventually be built. The prototype should be quick-and-dirty, and the code should probably be mostly thrown away afterwards. Since game-play is the thing being prototyped, use any art you can grab—anything at all—and cram it in there. Spend all your time on writing game-play code, and then as soon as you’ve got something working, get someone to play the game. If something’s bad, make suggestions on improving it immediately—in the next day or so. Remember, the prototype has got to shape up quickly in order to justify its own existence. Otherwise, it might get killed.
