If a picture is worth a thousand words, a good prototype can be worth far more. Prototypes of video games can communicate ideas and mechanics much more efficiently than meetings or a design document. Prototypes also save time, money, and unnecessary frustration during the design process.
Sometimes, it's not possible to create an electronic prototype of a video game, due to software or hardware issues, financial cost, or a lack of time, but with a few office supplies and a bit of ingenuity, game development students (and even the pros) can make useful and purposeful paper prototypes of game ideas.
During the spring semester of 2008, a group of graduate students (myself included) at Carnegie Mellon University's Entertainment Technology Center formed a team to create games for the Apple iPhone. Due to design choices and software timing, we relied heavily on paper prototyping and paper play tests.
Our team consisted of seven members: one producer, one game designer, one artist, one sound designer, one interaction designer, and two programmers. We wanted to create a game experience that was both social and intuitive and that utilized several of the unique features of the iPhone (specifically multi-touch, proximity sensing, and the accelerometer).
Initially, we had some concerns as to when Apple would be releasing the iPhone software development kit, what exactly it would be capable of, and how complete it would be. When we looked at our goals, coupled with our concerns, we decided to create a series of micro-game (5 to 15 seconds) experiences that would be placed into an overall meta-game designed to encourage social interactions with multiple users on one iPhone.
The first question we had to answer was how and where do we start developing games for the iPhone without having the ability put custom code onto the device?
The Entertainment Technology Center bought us a phone to develop on, but stipulated that we could not hack the phone or do anything else to void its warranty. With that in mind, for testing and design purposes, we considered creating hardware solutions to mimic the iPhone's unique features, using Panda 3D to quickly mock-up the micro-games.
The group decided against these early technological prototypes for a few reasons.
First, we were concerned about the necessary investments of both time and money. We reasoned that since we knew little about the SDK, it was foolish for our programmers to spend time creating prototypes that probably couldn't be used once we were actually able to put code into an iPhone. This point was especially relevant considering the entire production cycle for the project was one semester. We all agreed that our programmers' time would be much better spent brushing up on Objective C and researching the platform, rather than making temporary code.
Second, the costs (again, both financially and in time) to create mock-iPhone hardware with multi-touch capabilities, an accelerometer, and a proximity sensor were prohibitive. While it certainly would have been fun to experiment with creating these varied devices, we worried that the resulting technology would not meet our needs. Additionally, the three systems almost certainly could not be combined into one easy-to-use device.
Finally, we wanted to be able to test the games in almost any situation or any setting -- not just in our project room -- and due to the size of possible hardware mock-ups, this didn't seem feasible.
With these concerns in mind and on the recommendation of our faculty advisor, we decided to pursue paper prototyping and play testing. We conducted five rounds of paper prototyping and gathered massive amounts of data and feedback. Here are top five most significant things we learned about paper prototyping and play testing video game concepts.
1. Create Standard Procedures
In any play test, it's important to have a set of standard procedures to ensure that the people who are administering the test are not inadvertently affecting the data that is collected. With paper prototypes there are even more to consider; thus early on, the team set a few rules that quickly became standard practice for each of our play test sessions.
First, we tried to have all the team members at all the play test sessions. We reasoned that all sections of the pipeline, from art to programming to interface design to sound, would benefit from directly seeing play testers in action. Additionally, because of the nature of paper prototypes, each team member was needed on site to fill the roles normally handled by technology, such as scorekeeping, network connections, verification, and so forth.
Because we were a team of only seven people, were able to meet this requirement pretty easily. However, for a larger team, this may be impractical.
Second, since we wanted to gather as much information as possible and many of our team members would be busy with various duties during the play tests, we photographed and videotaped all the sessions. The tapes allowed us to go back later and reexamine not only the play testers (their body language, reactions), but our performances as mediators as well. We wanted to be sure that we were presenting our designs in a neutral manner that did not lead our testers toward solutions.