Tales of Preproduction: Refining the prototyping procedure

I am teaching the Game Preproduction class for the second time this semester, and this time I am joined by Antonio Sanders as a team-teacher from the School of Art. There are already a lot of interesting things happening as we have a class that is now have Computer Science majors and half Animation majors. We have also extended the class time to a "studio" duration, so we meet twice a week for three hours per meeting instead of the 75 minutes I had with my inaugural group last year.

Given that quick summary of our context, I want to share a significant change that we made to the prototyping process from last year. Last year, the team adjusted the schedule because we didn't dedicate enough ideation time to prototyping, and so this year, we set aside five days for this. Each day, the students are supposed to bring in a prototype that answers a design question. I remember this also being challenging last year, and it wasn't until late in that process that we remembered the seven questions that Lemarchand poses about prototypes in A Playful Production Process. 

In an effort to get the students thinking more critically about their prototypes, we have required them to write short prototype reports that address Lemarchand's seven questions. The last of the questions, which Lemarchand himself typesets in bold to show its importance, is, "What question does this prototype answer?" What the reports help reveal, which was harder to see last year, were cases where the questions themselves were either malformed or unanswerable. That is, students are going into prototyping without a good idea of what prototyping is. Several times, I've seen students show their prototypes, and when I ask what design question they answer, the students have to look it up on their reports. This is pretty strong evidence that the questions were developed post hoc. What's most troubling is that, after having completed four of the planned five rounds, these problems are still rampant.

Early in the process, my teaching partner suggested students think about design questions in the form "Is X Y?" where X is a capability being prototyped and Y is a design goal. For example "Is holding the jump button down to fly giving the player a sense of freedom?" While this heuristic proved helpful, a lot of students struggled with it: in part, I think they didn't understand that it was only a heuristic, and in part because they haven't practiced the analysis skills required to pull a design question out of an inspiration. If I were to use this again, I'd follow the obvious-in-retrospect need to rename those variables, to something like "Does this player action produce this design goal?" (Unfortunately, the discussion of design goals comes up later in the book, so maybe even this idea is too fuzzy for the students.)

Many of the questions that students want to pursue are actually research questions. I mean this in both the colloquial and the academic senses. A question like, "Does adding a sudden sound make the player scared when they see the monster?" is obviously answered in the affirmative: one need only look at games that induce jump-scares to see that this is effective. Questions like, "Do timers increase player stress?" are simple design truisms that are not worth prototyping. In yesterday's class, I tried to explain to the students that if the question is generic then it's a research question, and that design questions are always about specifics. In particular, through science, we approach generic questions through specific experiments that attempt to answer the general question; through design, we answer specific questions through specifics directly.

Reflecting on these problems, it becomes clear that the earlier parts of the semester were not goal-directed enough. Students acknowledged after our in-class brainstorming session that they were not brainstorming game ideas (but that's a topic for another post). When the students did research, many of these were also not goal-directed. Now, in prototyping, we're more easily to see what students are interested in, and we can point out to them that their interests and issues can and should be solved by blue-sky ideation or by research. However, we haven't baked that into these first five weeks. Put another way, we took a waterfall approach to ideation whereas perhaps next year we should try an iterative one.

We're in the process of collecting summaries of all the students' prototypes. I put together a form that uses this template for students to self-describe prototypes that are viable for forming teams around:

This game will be a GENRE/TYPE where the player CORE MECHANISM to GOAL/THEME. 

I'm eager to see if this was a helpful hook for the students. I will have to ask them about it on Tuesday and then see if it's something we can use with next year's cohort.

Notes from the inaugural Game Preproduction class: How Do I? vs. Should I?

As I mentioned back in January, I am teaching our CS390 Game Preproduction class for the first time this semester. I have a small class of students who already know me, and so it's been a real pleasure to teach. It has not been without some hiccups, though, and I need to start capturing some of them here on my blog. This will help me to understand and contextualize what happened and also give me an archive of observations for future improvement.

From February 7 through February 14 was set aside for the goal of making as many prototypes as possible so that the students could form teams and focus in on goals by February 16. That date marks 15% of the project time, which Lemarchand recommends as the extent of the ideation phase. On February 2, I gave the students the option of how they wanted to be held accountable to this goal. Together, we agreed that each student should present one prototype on each of the three upcoming classes (Feb 7, 9, and 14), and that at least one of these must be a paper prototype and one of these must be a digital prototype. One of the reasons for the latter constraint is that our previous presentations of paper prototypes showed that many students did not understand how best to use this medium. 

Upon returning to the reference text, I also realized that the students did not seem to understand the distinction between a playful prototype and a paper prototype, and this gives me something specific to improve next time. Students brought in playful physical artifacts and experiences that were enjoyable in various ways, but they did answer any design questions about video games. For example, it is fun to move a ship around and make shooting noises, but this doesn't tell us anything about a particular design for a shmup, or it is fun to run across the room and try not to be caught by classmates, but this doesn't tell us anything particular about a stealth or action game. The distinction between playful prototypes and paper prototypes is clear in the reading but was not evident from my students' presentations.

While watching students present their digital prototypes, I realized that there was another important distinction to make: the difference between How do I? and Should I? A lot of the students who showed digital work were really asking the question of whether they could accomplish some design goal, but this question is not fruitful for making decisions about video game direction. It should be a given that anything one has seen in a videogame before is something that they can make, given enough time. And yet, even I fell victim to this during our in-class digital prototyping workshop, when I tried to see if I could make a weapon-switching shmup in an hour. The real question to answer with a prototype at this stage is, "Should I pursue this idea?" Would a shmup where you can swap weapons be fun? Yes, of course it will. That is well trod design territory. Sketch the weapons and Bob's your uncle. (Well, he's my uncle, anyway.)

On one hand, it's easy to say that I should simply push students toward the question of whether a design is worth pursuing rather than whether they can engineer it. On the other hand, Lemarchand makes it clear that one of the first steps in the process is to learn your tools... but my students, by and large, are not very good at their tools yet. Some have been gamedev hobbyists, others have taken an elective in game programming, and others have no experience making videogames at all. When facing your own ignorance about how such things are done, it is natural to be slow and to need to tinker. It is not clear how to resolve this conflict. Next year, as our curriculum matures, more of my CS majors will have game programming experience; however, then we will also have students from other production majors coming in, and I suspect we will run into the same kind of second-order ignorance.

Rereading the text, I was reminded that Lemarchand provides a set of questions that a prototype should answer. His list comes right before the aforementioned playful-physical-digital distinction. Having the students frame their work within these questions may be another important step to improving the process. Adding a reporting layer may look like it is making them do more work, but I think, if it is done right, that the questions will help the students do less and better work. For reference, Lemarchand's questions (from page 23) are:

• What player activity am I prototyping?
• What game verbs am I investigating?
• What kind of experience does this player activity produce?
• What tone or mood does the player activity have?
• What interesting gameplay and story things can I do with this player activity right now?
• How much could I do with this player activity if I had the time to devise different situations and scenarios in which to use it?
• What question am I trying to answer with this prototype? (Emphasis in original.)