July 11th, 2011
In order to lighten the mood a bit from my post earlier today, let’s talk about game design.
You can’t build games in an ivory tower, or even at an Ikea writing desk. Today, I’d like to talk about what happens when one kind of reality meets theory, and a bit about the lifecycle of a game design.
Playtesting is an integral part of the game development cycle. Game design, unlike publishing, is an iterative process. You build, you play, you build, you play. In the process of playing, you will uncover problems, and they will need fixing.
I’ll illustrate. My current project, To Seek Adventure, is a two-player adventure game. It’s a roundtable game — no single GM. The game uses random scenario generation, rather like In a Wicked Age. For several generations of design document, it used a random location for each scene.
In a white box environment, playing through the game myself and working out the math, this seemed fine. Put into actual play, it crashed and burned. The game was too random. Players had too many curve balls to react to.
So my co-designer and I went back to the drawing board.1 We created a scenario generation system based on drawing some random elements (with just one location), then brainstorming a set of challenges for the heroes to face.
We took that back to the table, and damn, the game ran like a charm. I’ll be talking about these mechanics more in the future, but suffice it to say, I’m really happy with them. The game’s a mile closer to finished because and only because we put it into actual play.
During the same rounds of playtesting, we found that another mechanic was unnecessary because players tended to do it automatically. So we struck that rule. In the white box, it felt fine. But with real live people… superfluous. Entirely.
The next step is external playtesting. As a designer, I’ve got to know whether the game works when I’m not in the room. An earlier version came back with mixed results. Time to try again with the latest and greatest.
Vincent Baker’s talked about how roleplaying games modify a conversation. I’d go so far as to say that you can’t tell what that conversation is until you’ve had it. You can guess, sure, but it’s like high school debate. Prepare all you want, but you’re going to end up in emergent arguments you never predicted.
Playtesting is vitally necessary because we, as designers, can’t whiteboard human elements. A roleplaying game lives and dies on human elements. Those need to be observed, and the game needs to be improved in response to them. More to the point, a roleplaying game only truly exists in play. It doesn’t matter how beautiful your game’s clockworks are… it must play, or else it’s hardly a game at all.
- Actually the gridded Moleskine. ↩