Tuesday, August 25, 2009

Questions for Testers: Designer Debriefing

In my previous post, I suggested a design philosophy that I try to incorporate in my games: Simplicity of Play and Depth of Strategy.


It should be noted that this is not the template for making "a good game."  Lots of "good games" don't adhere to this philosophy at all.  For instance, D&D does NOT aim for simplicity.  You need several books, tons of peripherals (maps, multiple types of dice, miniatures, informational sheets, etc) and one expert (the DM) to basically mediate the entire experience.  Is it a good game?  Absolutely.  In fact, not only is it testing well in longevity, but it has served as the template and inspiration of multiple genres.  I don't think it is a far stretch to say that D&D did for gaming what The Lord of the Rings did for fictional literature.


But, I digress.  The point is, the above philosophy is somewhat narrow and personal.  If you're interested in making good games, you don't have to adhere to that standard.  So, I thought I'd share some more "universal" tools for evaluating a game-in-process.


I think the best metric for the health of a game design is enjoyment.  The only way to gauge enjoyment is to ask people who have played the game.  The challenge here is that "enjoyment" is an effect, not a component of the game.  So to really dig out what is working (or not working) in a game, it is good to see what elements are contributing or detracting from the enjoyment of the game.  I find that a quick debrief with testers after the game can be vital to tuning a game from okay to good to "when can we play again?"


Caveat: No game appeals to everyone.  Some people you may test with might not like the game because it's just not their kind of game.  Figuring out what kinds of gamers will like your game is crucial in making good design choices.

Alright, so here is a list of some of the types of questions I ask of my testers to determine what is making the fun and what is killing the fun:

How was your overall experience? This may not always get the most honest answers if your testers are friends.  They may try to be nice, and that's not always helpful.  Still though, this is a good warm-up question, and once people are used to offering critique will in the long-run become more helpful.

Was anything in the game unclear? This is a technical question, and it's important that you listen to it as such.  However, this is also a way of targeting frustration (which I consider the prime enemy of enjoyment in gaming).

What felt particularly good?  What didn't feel quite right? These are not necessarily technical questions.  But, over all, these are the most important ones because it really helps separate what works from what doesn't.  Sometimes they are mathematical ("I think the barbarian is just hitting too hard"), sometimes they are aesthetic ("I really like the new counters.  Much easier to read.").  Sometimes, they will be maddeningly unhelpful ("I dunno... I just didn't like it that much").  

How was the pacing?  This question may need to be asked in different ways, but what you are secretly asking is "did I ever let you get bored?"  In most cases, it is difficult to make a game too fast, but very easy to make a game too slow.  Also, it is worth noting that in most games, pace increases as player familiarity increases.  This may not be a helpful question in your first session, but it should always be on your mind.

Who do you think would like this game?  More than anything, if someone is able to answer this question you've probably done something right: your game has a flavor.  If the crowd they describe is different than the target you had in mind, you've hit a crossroads.  Either you need to change course to hit your target, or you need to redefine your target.  Whichever you choose, you'll probably be doing some revision before the next session.

Let me leave you with a few closing thoughts about this process:
  • Don't make "knee-jerk" changes.  Sometimes players are unlucky or just don't grasp a concept immediately.  Look for patterns of problems rather than isolated cases.  Make small corrections rather than big ones until you hit the balance you're aiming for.
  • The more specific the responses you receive, the better.  It's okay to ask testers to go a little deeper in their responses, but be gentle and considerate and don't make them feel bad if they can't come up with more.
  • Finally, never forget that testers are doing you a favor. In all things be gracious to them.

No comments:

Post a Comment