Design, Doubt, & the Scientific Method

A problem I frequently face when designing a new game is intense anxiety from not having answers to all its design problems at all times. It's a cycle of obnoxious mood swings where I'll fall in love with a high-level game concept and feel all smart and clever about it; and then I'll start prototyping, discover that there's a seemingly infinite number of design issues I didn't anticipate, and decide to give up on games altogether.

It's melodramatic and silly, but this sense of despair is real, and it recurs many times over a project's development. One moment I'm excited about a new mechanic or rule change that I believe will solve all the game's problems, and the next I'm crushed when it inevitably doesn't. There's a cost to this: anxiety feels shitty, of course, but it's also distracting. When I'm in the pit of despair, I'm not thinking clearly and my productivity suffers.

Antihero is my first project as an indie developer, and I suspected, at the outset, that I'd go through this cycle a lot. I was right! And, in fact, the anxiety has been even worse: because so much of my ego is tied up in this project, failure feels like it'll throw into question my entire sense of self. But over the course of Antihero's development, I've also come up with this One Weird Trick™ for talking myself down off these ledges. It essentially boils down to "trust the prototyping process," which is so basic I'm embarrassed to devote a blog post to it, but it turns out to be useful for me to frame prototyping and iteration in terms of the scientific method. (This will involve some metaphor-stretching.)

Specifically: each iteration of a game - each prototype - is a set of hypotheses. Even a simple prototype is comprised of dozens or hundreds of little ideas, each of which is a hypothesis in the form of "I think the game  will benefit from <some design decision>." ("I think the character's sword should take 2.5 seconds to swing," "I think dying should be permanent," etc.) 

You bang out a prototype as quickly as you can, and then you subject it to a playtest, which is the experiment. Playtesting exposes your hypotheses to reality - you discover what is working and what is not (or, especially early in the process: "what is failing horribly and what is failing slightly less horribly"). 

Playtest results - your data - come in the form of observations you make about the experience a tester is having ("they're not discovering the hidden treasure chest on level 2") and their reported experiences ("the demon lord boss was frustratingly difficult.") You analyze this feedback and use it to modify your hypotheses. But - and accepting this was key, for me - you only need to pick some small subset of design issues to tackle for the next game iteration. You can - you MUST - give yourself permission to leave holes in the design, with the understanding that you'll learn more about potential solutions for those holes with further experimentation. 

Finally: repeat this process until you've arrived at a provable theory -- in other words, a game that you're happy with. (Or the less-happy but equally-important-to-discover theory: "this concept is fundamentally broken/I don't have the resources required to realize it, and it needs to be set aside.")

There are a couple important things here that lend sanity to my development. First, it's been useful to frame playtests as a series of concrete, realizable goals. I'm always either doing a playtest or making changes that will be in an upcoming playtest; therefore, I'm always moving towards a goal. And second - and more important - it underscores for me the nature of playtests as experiments. By definition, you cannot know the outcome of an experiment until you run it; similarly, you cannot know the solution to a design problem until you playtest it. Unsolved design problems is just the nature of a game in development.

I know - everyone who makes games knows - that prototyping and playtesting are important. But framing the process in these terms has had a dramatic impact on my relationship to the development process; it's helped me get to shore more quickly during the - still frequent - moments when I feel totally adrift. To create a game, you don't have to have answers to everything. In fact, especially in the early stages of a design, you don't need the answers to anything.

The only things you ever need to move forward are a broken prototype and a playtester.