Playtesting and Usability Testing

About eight months ago, I started creating a card game called Fortune Valley. It’s a game about running a casino in a fledgling casino town against other proprietors who seek to build their own thriving gambling dens and attract the most gamblers — think Benny Binion’s Las Vegas or Atlantic City in the 80s.

Unsurprisingly, I’m learning that making a game is a lot like designing software: cyclical iteration combined with regular testing and observation affords a more informed refinement process. While the goal of the exercise in both instances is the same, some of the outcomes and premises differ and I’ve learned to adjust for these diversions.

Peel Back the Onion

Whether or not you’re participating in the playtest, observation is critical. Like a usability test, you can ask participants to stop and explain their thoughts before or after taking an action. If they’re stuck on a rule or confused about whether a play is legal or not, it’s important to encourage them to articulate why they want to perform an action. It’s times like these where I’ve discovered the most interesting opportunities to tweak mechanics to better suit the expectations of the players or provide a clearer set of choices in a given scenario.

The Object of the Game is the Goal

Games are unlike software in that we build certain software to solve problems (e.g. Yelp, because you don’t feel like cooking) while we design games to present problems (e.g. controlling an entire city’s worth of real estate in Monopoly) that a player must solve in order to achieve a win condition. In other words, users of software are experts in identifying the problem, but are not always experts in solving those with a particular piece of software (at first, of course, in the context of a usability test). Players may be experts in certain game mechanics like bidding systems or combat dynamics, but they’re not experts in the problem that the game presents them with; for example, building the most prolific electrical power network. It’s the game designer’s job to make clear both the rules of the system and the problem that the player is trying to solve to win. Playtesting helps to achieve clarity in both rule and problem definition.

Constraints Are Less Pronounced in Analog Media

A user can interact with a digital interface in a finite number of ways. These affordances are (hopefully) clear to them and provide a pathway to helping them solve their problem. The same cannot be said for analog interfaces. Think of a simple card game with a standard 52-card deck. Holding the nine of clubs, for example, you consider how to lay it on the table to play it. If you lay it face up, it could mean one thing while face down signals another. Some games require you to change the orientation of a card (e.g. “tapping” in Magic: The Gathering) or cover it with other cards. Cards can be held in the hand, stacked, splayed, or arranged in numerous ways on a table. The rules of a game should provide the player with a clear set of physical constraints so they can spend their energy thinking of strategy instead of grappling with the placement and orientation of the game pieces.

I’ve been through about ten playtests so far with Fortune Valley, and even in those relatively few sessions I’ve made extremely positive strides in both clarifying the rules and creating more entertaining scenarios. I expect the similarities between usability testing and playtesting will continue to reveal themselves throughout the rest of development.