Prototyping
I've been teaching college full-time for four years as of this week... which surprised me! Over the years, I've helped my students deal with various production issues, ranging from team problems to managing project scope to iterative development. ("Iterate early and often!") There are many different ways to approach iterative development, and one specific approach I use frequently is prototyping.
First, my definition of a prototype: A prototype is intended to answer very specific questions. Ideally, the prototype answers just one question. This makes it very different from a vertical slice, which is intended to be a representation of the entirety of the game experience (just a very thin slice of it). And not everything in your game should be prototyped. A prototype answers a question that you really need to answer, before you start working in earnest on your project.
For example, I made the prototypes for a gesture game that we were thinking of doing. This would be a new kind of mobile game for me, so there are a lot of questions to answer. Here are the three I started with:
- First question (Design): What are some of the gestures we will want to use in the game?
- Second question (Tech): Can our tech accurately capture detailed gestures on the target device?
- Third question (User Experience): Will it be a fun and satisfying user experience to play via the gestures?
- Fourth question (Design): Are there additional gestures that we will want to use in the game?
These questions fit into the four categories or axes I like to use to define prototypes:
- Design
- User Experience
- Technology
- Art
A core premise for prototyping is that you should only prototype on one or two axis, because otherwise, you're trying to do too much, answer too many questions at one time with a single prototype. This approach is not my own... I first heard about this several years ago, at a fantastic GDC talk by Chaim Gingold. It's a great approach that has served me well over the years. You can find his slides at http://levitylab.com/cog.
For the gesture game, the second question "Can our tech accurately capture detailed gestures on device?" was quickly answered with, "Well, we can, but there seems to be a problem after inputting three or four gestures, where the app freezes!" Okay, so we won't move onto the next questions just yet! But that just illustrates the value of taking this kind of approach. Another team might try to tackle all these questions at once, and only later realize that they have a core technical or design issue that they have to solve before they can proceed with the project.
Prototypes can take very unusual forms. I've started some projects that I can only describe as "experiments in storytelling via gameplay". For these projects, the biggest risk is actually the narrative, not the technology. So my prototyping has been writing stories or dialogue that are representative of what would be in the actual game, to ensure that the content will be good enough to merit the other work. And by prototyping the narrative, I can also tell whether we are going to have content pipeline issues, i.e., "Can Ellen write this stuff quickly enough?" Content pipeline issues are a serious problem, for large studios or even small indie shops. For one trivia game project we considered doing a couple years ago, that answer was a definitive no, so we dropped the project purely on that basis.
I'm also a huge fan of prototyping on paper. There are many types of casual games that can be prototyped and played entirely on paper, before a single line of code is written. And sometimes the paper prototype proves that the code should not be written! For one mobile game, I playtested the paper prototype several times with friends, and could never get it to feel right. So, there is another project that is not going into full development, at least for now!
Our prototyping often involves a mockup or wireframe tool like Balsamiq, Axure, or NinjaMock. These wireframe tools are awesome and can help answer very specific questions about the user experience. They're fast and efficient and I really don't mind experimenting with them and then throwing away the results if they don't work as well as I'd like.
Is there a common thread here? Yes, it's that we prototype a lot, and then we throw a lot of it away. Why? Because it's often the right thing to do. Ideas are cheap, production is expensive. To quote my friend Stuart Moulder, "The big danger is getting too committed to an idea without validation. Prototyping is a technique that can measure the validity of those starting assumptions, along with answering questions you really don't know the answers to." I would rather discard a hundred ideas at the prototype stage than discover later that we had made a poor choice in how to invest our time, that most precious of resources.
