Sunday, March 01, 2009

Teaching Iteration and Risk-Taking

There is an inherent conflict between the nature of classes and course objectives, when it comes to designing a game as a class project.

The best way to learn to design games is to make a rapid prototype, fail miserably, figure out what you did wrong, and try again. Repeat until you get it right. In order to do this, the student has to feel like it is okay to take risks, that it is perfectly acceptable (even expected) to try crazy stuff that may simply not work out.

But of course, this is for a grade. Enter the fear of failure. Or, it's not for a grade at all. No threat of failure, but likely no effort put in by students on an "optional" project. Is there a way around this paradox?

Here's the method I'm currently using:
  • My non-digital game design project has four milestones. The first is just a high concept, target audience, basic information (number of players, etc.) and some core mechanics. The second is a rough but playable prototype. The third is a playtested prototype, with the mechanics finalized or close to it. The final milestone is a polished product.
  • All milestones are graded. Early milestones are easy points -- just turn in something, anything, as long as it works. Later milestones are graded based on the quality of the design -- you'd better have done some iterations.
  • For the future, I'm thinking that early milestones should be worth fewer points than later milestones. This puts less importance on early work and more focus on the final product.
  • On the days where milestones are due, students bring their works-in-progress to class and present the work for peer review. This also gives me a chance to see how the projects are progressing. In the future, I should probably just give a grade right then and there for the early milestones.
  • Make it clear to students from the beginning that the more they iterate on their project, the more they playtest, the more they fail and then change, the better their final project will be. Unfortunately, this is one of those things they might just have to find out the hard way for themselves. I'll try bringing in a student work from an earlier course (with permission) in its various stages of completion, to show just how much difference playtesting can make.


Mauricio said...

Other thing I do: encourage students to bring more than one idea for their project on week 1(making one simple concept doc for each one).

Then they can make a verbal presentation of these ideas to the rest of the class next week, having a fast feedback of the reception of the ideas (so they can try wild things).

After that each student must choose just one idea (or a mix) do keep going, making proposal and design documents, then releasing progressives milestones till the finished game.

Nels Anderson said...

Mauricio beat me to it, but I definitely agree. If time allows, perhaps the students are assigned to create three different prototypes, one per week. After feedback on each from the rest of the class, they decide which one to run with.