Some small percentage of interesting decisions are always going to be fun. Some interesting decisions never are. Most, though, are fun only when given a context in which they can shine. It’s vital to understand what situation a decision needs, and to test your game accordingly.

Many well-known, big-budget games have decisions that work as gameplay specifically because of how they’re presented. Choosing where on the screen to click with a mouse, for example, is completely trivial in a turn-based environment that allows the player to take as much time as she wants. Yet, that activity supports the entire FPS genre, because it’s not at all easy to click just the right spot under extreme time pressure.

Fighting games are of the same ilk. Lots of fighting game decisions are easy once the player understands the game (“I should parry this projectile, that’s strictly better for me than blocking or jumping”). Others are more-or-less math problems: there are two options, with the first having a higher expected value than the second. On paper, the player alway makes the right choice. When one has to find the right move in a sixth of a second, doing the math or executing the correct action is a lot harder—and the difficulty helps turn what would otherwise be a trivial exercise into a tense journey through donkeyspace.

Both of those examples rely on time limits, but there are other contexts that can affect whether a decision is interesting. While in school, for example, I worked on a game loosely based on regattas. Players formed teams, and then teams rowed against each other to win a race. We were to discover the hard way that that has the potential to be interesting . . . so long as the game isn’t an entirely cooperative game about rowing in tandem.

If you’ve ever been out on a boat yourself, this probably doesn’t surprise you. Rowing can lead to beautiful scenery, it can be a kind of moving meditation, one can use it as a social event. It’s unusual, though, for the actual act of rowing to be intellectually challenging. We struggled for weeks to build a system that would make coordinating a team of rowers fun in and of itself. Two weeks went by with the team rowing boats using different systems, just by ourselves without any opposition, searching for a way to turn that into a fun puzzle.

Mercifully, that process ended (as is so often the case with design problems) when we gritted our teeth and took our not-really-working game out to playtest. The results were dramatic—it was great fun! Players enjoyed it, we enjoyed watching them play, everyone had a good time. What had happened, to bring about such a remarkable change?

All we did was change the context in which the same decisions were made. Throughout our internal design work we played a cooperative slice of our cooperate-to-compete game. In doing so we put all the weight on the puzzle, and the puzzle couldn’t bear the load. It wasn’t deep enough to be a game unto itself.

A competitive environment, on the other hand, made the relatively simple puzzle we had built deeply rewarding. It was hard enough that players sometimes made mistakes, and those mistakes now existed in a context where they mattered. At the same time, it was easy enough to allow for successful cooperation more often than not, and players enjoyed solving each turn’s puzzle in order to progress in the race. Competition made the exact same mechanics fun.

Our game didn’t have the wrong decisions; we’d just been testing those decisions in the wrong context. If you can predict that your game will work best when certain things obtain, be sure to test in that context. It’s worth saving those two weeks of heartache!