在我分享在《How I Teach Game Design》博文的教学大纲中，作业布置一两周后就要上交。那么学生在这一两周的实际工作时间里做什么呢？答案就是：迭代设计过程。（请点击此处阅读本系列之序言）
在纽约的Different Games大会上，我听了游戏设计师Mattie Brice的好演讲。她展示了游戏测试的改善法。她的要点是，测试有时候可能消弱游戏设计中个人的、有表现力的巧思——如果你让外行人参与测试，制作一款取悦他们而不是你自己的游戏，你可能会扼杀你的游戏中最独一无二的东西。
作为迭代设计的案例，我经常叫学生阅读Richard Garfield发表在《The Rules of Play Reader》（我与Katie Salen一起编辑的选集）的一篇文章《<万智牌：旅法师的对决>的设计进化》（The Design Evolution of Magic: The Gathering）。
我还给Brenda Laurel的书《Design Research》写了一个章节的内容，是关于迭代设计过程的，叫作《玩中学：迭代设计过程》（Play as Research: The Iterative Design Process）。
《三连棋》练习直接受到我的游戏设计偶象之一Bernie DeKoven的启发。在他的游戏设计书《The Well-Played Game》中，有一整个章节是在介绍修改游戏，其中就包括《三连棋》。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）
How I Teach Game Design 1: The Game Design Process
by Eric Zimmerman
how and why to iterate + a game modification exercise
In the syllabus I shared in my last How I Teach Game Design post, graded assignments are given out on one week, and then one or two or three weeks later, they are due. So what happens in-between, during the actual work time? The answer is: the iterative design process.
Iterative design means a process focused on playtesting. You produce a playable prototype of a game as quickly as possible, then playtest the prototype, and you decide how to evolve the game based on the experience of the playtest. One way of understanding iterative design would be its opposite: a designer who works out all of the details of a game in advance, and creates a final set of rules and other materials without ever actually playing the game.
Of course, this caricature is absurd: no game designer I know has ever released a game without playtesting it. But I do have a particularly strong emphasis on iterative design in my teaching and my creative practice as a designer. The game designer Kevin Cancienne once called me a “playtesting fundamentalist’ – and perhaps he’s right. (So much for my stance against fundamentalism.)
What’s the big deal about iteration? The behavior of complex, interactive systems – like games – is incredibly difficult to predict. You generally cannot know exactly what players are going to do once they start playing your game. The only way to find out is to actually build some primitive version of your game, have people play it, and see what happens. Each time you playtest, you find out what does and doesn’t work, make some adjustments, and then play again. That’s why it is called the iterative process – you create successive versions, or iterations, of your game as you go.
The process of iteration consists of these steps:
1. design a prototype
2. playtest your prototype
3. analyze what happened
(then it’s back to step 1 – modifying your game to create a new prototype)
In a game design class, most of the playtesting will be done by the designers themselves, especially for short assignments. But of course it is always good for other people to play the games and give feedback – such as designers playing each others’ games in a class. For commercial game development, of course, a more rigorous playtesting process is highly recommended. (More details about playtesting methodology are coming in future posts.)
Principles of iteration
Below are a few ideas to keep in mind about the iterative process.
Ideas are cheap. People often romanticize the creative process, assuming that the hardest part of doing anything is to come up with a “good idea.” I could not disagree more. Ideas in and of themselves – by which I mean a concept you might have for a game – are not that important. Game design ideas gain value, sophistication, and meaning only when they are playtested. The hard work of the process, the actual game design itself, happens during the iterative process, not the concepting process that proceeds it.
Stop brainstorming and start prototyping. When a group begins discussing a game project, the tendency is for everyone to discuss their ideas ad infinitum. Whose idea is better or more interesting? Whose idea will make a better game? The truth is that it doesn’t really matter – any place is a good starting point for a design process. The challenge of iteration is to get a playable prototype happening as soon as possible. The art of iteration is to decisively pick one idea – any idea – that can quickly be playtested.
Embrace failure. One of the hardest things about iteration is seeing your ideas fail. But it’s really important to experience failure – most ideas will not work the way you expected them to play out. That’s why it is important to iterate like mad, trying out ideas, seeing what works and doesn’t work, evolving your design forward as you learn from your mistakes. Failure is like spicy food – it hurts at first… but then you acquire a taste for it – and soon you just can’t get enough. You never completely lose the hurt, but you also learn to enjoy the pain.
Be critical. As we iterate, we practice our ability to be rigorously critical with each other and with ourselves. The study of game design can provide a language and set of concepts to help designers see why a game design might or might not be working. But ultimately it is up to you to learn how to be critical with your own design.
More experimental? More iteration. The more weird or unusual an idea is, the more important it is to iterate. If you are doing an exact copy of an existing game, just changing a few superficial elements, you probably don’t need to playtest as much. But if you are doing anything at all original or experimental then you absolutely need to playtest throughout the entire process.
Keep it ugly. As a game design prototype, you should not worry if your game has gorgeous visual aesthetics. Initial prototypes should be down-and-dirty, skeletal versions of a game. Don’t design beautiful illustrated playing cards – just grab some index cards and handwrite what you need. Perhaps later on you’ll end up with a beautiful looking game, but at first, keep things fast and loose so that you can quickly try out different ideas.
Sidebar: the pitfalls of playtesting
Just so that I don’t come off as too fundamentalist about playtesting and iteration, I want to be sure and acknowledge that iteration is not a cure-all for every designer and every game, and that it can be dangerous to playtest your design uncritically.
At the Different Games conference in New York City last year, I saw a great talk by game designer Mattie Brice who presented a corrective to the idea of playtesting. Her point was that playtesting can sometimes dilute the personal, expressive quirkiness of a game design – that if you playtest with outsiders, and create a game to please them instead of yourself, you could end up killing what is most unique about your game.
This is a very valid point. It’s important to be critical of playtesting, and of the reactions your playtesters might have to your game. Like any design concept or methodological tool, playtesting is not universally valid or true, and there are many ways to playtest well or poorly.
New rules for an old game
I like to get my students making something as quickly as possible – even during the first class. Because creating a game from scratch is often a daunting challenge, one way to kickstart the design process is to give designers an exercise where they are modifying an existing game, rather than making a new one.
The Tic-Tac-Toe exercise usually takes place during the very first class meeting. It serves as a good introduction to understanding game rules, as well as an “icebreaker” design activity.
Analyze Tic-Tac-Toe and then redesign the game by changing a few rules.
understanding how changing game rules changes the system of a game
introduction to the iterative process
icebreaker game design exercise
Before the exercise
Through class discussion, make a general list of the rules of Tic-Tac-Toe. For example:
1. play takes places on a 3×3 grid
2. two players alternate turns placing an X or an O in an empty square
3. three of the same symbols in a row wins
4. if no one can play, the game ends in a draw
Then discuss why Tic-Tac-Toe always ends in a draw for most players. Have the class brainstorm what they might modify in order to change the game: the grid size and shape, the number of players, the winning conditions, the things you can do on a turn, etc.
Pairs of students try to redesign the game in order to increase the space of possibility of the game – to make it more interesting to play than the “solved problem” of classic Tic-Tac-Toe.
As they design, have them change as little as possible – one, two, or three rules at the most. They should follow the iterative process of making small changes, playing their modified version, analyzing how they affected the game, and then redesigning again.
Finally, groups can share their modifications with the class, and what did and didn’t work. If there are too many groups for everyone to share, then pairs of groups can play each others’ games and discuss.
At this point, I’ve seen my students create hundreds of variations of Tic-Tac-Toe. My favorite was an exceptionally elegant variation where nothing was changed – except the winning condition. If you got 3-in-a-row, you lost. Playing this version of Tic-Tac-Toe means trying to force your opponent to make what we normally consider a “winning move.” As a minimal rule-change that turns the “solved” game of Tic-Tac-Toe into a brain-twisting puzzle, I loved that modification.
For a great case study on iterative design, I often have my students read The Design Evolution of Magic: The Gathering, an essay by Richard Garfield that appears in The Rules of Play Reader, an anthology I co-edited with Katie Salen.
I also wrote a chapter in Brenda Laurel’s book Design Research about the iterative design process called Play as Research: The Iterative Design Process which is available to read at ericzimmerman.com.
The Tic-Tac-Toe exercise is directly inspired by one of my game design heroes, Bernie DeKoven. In his classic game design book The Well-Played Game, there is a whole chapter devoted to modifying games, including Tic-Tac-Toe. MIT Press just published a new edition of the book. (Full disclosure: the new edition’s *awesomely brilliant* foreword was written by me.)(source:gamasutra)