Thursday, February 14, 2013

To prototype or not to prototype

A common piece of advice given to new designers is that of 'prototype early, prototype often'. The reasoning behind such advice is that the best way to test new ideas, to separate the wheat from the chaff, is to actually turn these ideas into physical form and play them. The harsh light of reality is shed onto these ideas that have been in your head for weeks, and only the best ones make it through. More over, prototyping as soon as possible allows a designer to judge quickly which ideas are worth spending more time on, and which ones simply do not work.

As a relatively new designer, I must say that I'm lucky in that I've never had too much of a problem with following this advice. In fact, at our weekly playtesting sessions I became somewhat known for appearing every week with a new prototype, some new and some iterations of an existing design. The best example of this I can think of was with a design I was working on last year for AEG's new Tempest setting.

I was desperately trying to make a game that I imagined fitted the different operations of the world's guilds - with the different actions in the different parts of the city reflecting the characters and aims of these organisations. To tie everything together, I was trying to find a way to have players use family members to complete these tasks, and to have these different agents gain experience and skills in line with they way they interacted with the world around them.

Looking back, it was an ambitious design, although at the time I don't think I appreciated this. I wasn't short of ideas, and I made numerous prototypes. These were duly taken along to our weekly playtesting session, where they always fell short in one way or another. Unfortunately, they seemed to fail (at least to me) not in ways that made subsequent iterations obvious, and so I would head back to the drawing board and overhaul the game. The next week I would show up with another, seemingly brand new prototype, and the cycle would continue. After two months of this, I was throughly sick of making prototypes that kept failing, and I haven't touched the game since.

Trying to understand what might have gone wrong in this whole process, I realised that I might have actually been doing myself a disservice in the way I went about this design. I'm not saying that this applies to everyone (or even a majority of designers) but what I think I needed to do was actually prototype less.

I'm come to think that spending an extra one or two weeks thinking about a game, the entire system that you are designing and how the different elements interact with each other, can be truly invaluable when it comes to producing a new prototype and playtesting it. Often, I would rush the prototyping process, telling myself that it was more important that I had a new prototype rather than making sure I had completely thought about every aspect of the game. Of course, a balance has to be struck between these two aims (and sometimes understanding everything about a design is impossible before a prototype is made!), but I certainly was on the extreme end of the scale.

My day job is as a chemist, and now I try to apply the values of experimentation to my process of designing games. Playtesting has much in common with experimenting, and prototyping with that of designing the experiment in the first place. The value of the experiment, and the conclusions that can be reached as a result, depend on making sure you design the experiment to ask the right questions. As it is with game design: the more time you spend thinking about what you want to get out of playtesting, the more valuable it will be. Far better than blindly making prototype after prototype without even knowing what questions you are asking of your players.