The Learning Curve

This week I had the privilege of demo-ing my card game with a friend of mine I only see occassionally.  After the game I thanked him for testing for me and his response was this: "No problem.  I think I make a good tester because I am a slow learner."

I thought his comment was at once endearing (there was no hint of false modesty in his face or voice) and instructive to me.  He had fun playing... not merely because the game ran well but because, by his estimation, he understood the game well by the second or third turn.

I took this to be a good sign for a game that is meant to be light-weight and casual.  What I thought was even better was watching over the course of four games or so, he made consistently better plays.  His skill level increased as his experience increased.

There is, I think, a fairly low ceiling for how good you can get at the game.  It doesn't offer the strategic depth of something like Magic: the Gathering or interpersonal skills like Poker.  But there are choices and in most cases there are poor, fair, and good decisions that can be made.

I think that's the strength of my card game (I can't go into much by way of specifics if I hope to get published), but the gist is that the rules are minimal but comprehensive and the cards are fairly easily understood.  You can know everything there is to know in just a couple minutes.  But there is a "feel" to the game, a heirarchy of decision making that comes with experience.  Anyone who has played two games is unlikely to spend more than a minute on even the most labored turn, because cards are easily and situationally prioritized.

I've been told that my game lacks a "ground-breaking inventive mechanic."  I think that's true, but I'm going to continue to pursue publication for a while anyways because I believe it is worth it.  It's novel.  It's a joy to play.  It's a good product.

Hmm... I meant to spend more time talking about the role of "learning" a game than I actually did.  Perhaps I'll tie-in to this in a separate post later.

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.