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.

3 comments:

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.

RAVaught said...

I don't disagree with the risk taking and failure part of your theory, but I am not sure about the rest. The fatal flaw in it is that, in the end, you still have to end up with something polished, which introduces anxiety that is self-defeating to what you are trying to teach.

Perhaps a better method would be to have them create an initial prototype, and then spend the rest of the course making incremental improvements/iterations and fixing things. The grade, instead of being focused on the polished finished project, could be on documentation of the iterations and play tests results. That way, you are not grading the product, but the process itself. One of the criteria of the process can be "Displays a willingness to take risks and tests them for feasibility."

At each phase, you can have them explain what risks they took, whether or not they were successful, how they were tested, what the results were, how they were improved and/or scrapped and why.

There are a couple of great things here. First, you are blatantly telling them to take risks, and not punishing them for doing so. Second, you are forcing their participation through the journalling. Third, you are making it ok to fail, provided that they LEARN FROM THEIR FAILURE. Ultimately, risk aversion comes from a fear of failure, and fear of failure is taught from a young age through a grade based education system designed to weed out independent thought. If you don't break that cycle you won't change their habits. Their habits are the result of years of indoctrination.