Problem-Driven Game Design

In my experience, a problem-driven approach is the only reliable generator of high-quality game designs. The more time I spend focusing on specific, well-articulated problems and questions, the more likely it is that my final design will be novel, deep, and valuable.

This approach pervades every stage of my design process, including the initial choice of what to work on. I won’t even start a project if I don’t have at least one clearly-stated problem or question in mind. Maybe I dislike something about an existing game or genre. Maybe I have a question about some game system that I’ve never seen in action before. It doesn’t need to be an earth-shattering question. It just needs to be well-formed, interesting, and unresolved.

The desire to get rich is unlikely to generate a high-quality design. The desire to create a new game in a genre that I truly love is equally unlikely to generate a high-quality design. The issue is not one of ethics or aesthetics. The issue is that the design space is mind-bogglingly vast and only sparsely populated with high-quality games. I’m standing in a desert, and I need to know which way to go. Neither love nor money helps me in this situation.

Problems provide direction. They point. They’re features of the local environment that say, “There may be treasure over there.” Success isn’t guaranteed, but this methodology succeeds more often than random chance would dictate, which is not true of any other approach I’ve tried.

An Example

Werewolf is a great game, but there are things I don’t like about it:

• It requires a moderator and a logistically awkward eye-closing phase.
• It doesn’t play well with fewer than seven players, and is often long.
• Being a werewolf is unpleasantly exhausting.
• Players are often eliminated early and must either leave the room or sit in silence.

Not everyone is bothered by these problems. That’s fine. My unique design sensibilities determine which problems I choose to work on. The important point is that my problems are specific enough and unambiguous enough to suggest a direction.

Indeed, on the day I clearly articulated these problems to myself, I had the following game idea: assign a hidden character card to each player, and then try to discover the owner of a different card each round.

This hypothetical proto-game addresses all four of my problems, to varying degrees. It requires no moderator or eye-closing. It works with as few as three players. It doesn’t put an individual player on the chopping block for an entire game. And if players are ever eliminated, they’re allowed to stick around and keep talking, because they don’t have any game-ruining information.

This isn’t a complete design, but there’s enough there for an initial playtest. We tried it, and the results were promising. Of course, we then had a new list of problems to solve. Good! Problems are our signposts in the vast and trackless land of game design.

We iterated on this cycle of problem-solving and playtesting (with Dave Chalker doing much of the heavy lifting) until we didn’t have any more problems to solve—or at least, until we were able to live with the remaining unsolved problems. The result is a cute little card game called Criminals.

Money, Love, Originality, and Fun

With this concrete example in place, it’s easier to see why the desire to make money is unlikely, in isolation, to lead to good game design. That desire will never help me come up with a specific idea like the one that lies at the core of Criminals, because it doesn’t (and can’t) tell me where in design space to search. The desire may be an excellent motivator, but it’s a terrible navigator.

If I declare that I love Werewolf and would love to design my own psychology game, my desire is also unlikely, in isolation, to help me design Criminals or any other interesting game. There are millions of ways to modify Werewolf, and almost all of them are bad. I need some methodology that actually helps me figure out what to try, and why.

The honest desire to create something original is similarly useless, because it has nothing to say about how to find non-derivitave moves through design space. If the only clear problem I can articulate about my current rule-set is that it’s too much like some existing game, my solution is not to search for ways to differentiate it. My solution is to scrap the project. Otherwise, I’ll end up with a derivative result which differs from its inspiration in ways that exist only for the sake of differentiation, and likely make the game worse. I want an actual methodology that helps me find unexplored, high-quality regions of design space.

Finally, the honest desire simply to create a fun game fares no better than any of these other motivations. If the only clear problem I can articulate about my current rule-set is that it’s “not fun enough,” I’m strongly inclined to return to an earlier, better iteration and branch out from there, or scrap the project entirely. “Not fun enough” is navigationally useless, unless I can translate it into a specific, unambiguous problem-statement that doesn’t include the word “fun”. If I can do that, great! Now I have a problem to focus on which will likely suggest new ideas and directions. Otherwise, I’m just wasting my time.

Closing Thoughts

Why might I design a game?

• To make money.
• To pay homage to an existing beloved game.
• To create something original.
• To create something fun.

There’s nothing wrong with these motivations, but they’ve never helped me design good games. I’ve always obtained my best results when I’ve ignored these motivations and focused on solving interesting problems and answering interesting questions.