Posted on Leave a comment

Tips for Playtesters

I’ve seen plenty of posts over the years about “how to playtest your game”, but relatively few on “how to be a good playtester”, so I thought I’d post some thoughts about this subject.  I am probably the last person who should write this, because I violate almost all of the items below on a regular basis.  But having been a part of Spielbany for a number of years now, and having benefited from having many great playtesters try my own games, I think this list of suggestions may be helpful.


  1. While the game is running, write down, rather than vocalize, your comments and suggestions.    This has two benefits.  It keeps the game on track, preventing it from getting bogged down by a lengthy discussion about this rule or that system.  And, it gives the designer something tangible to take away from the session, in case his mind or note-taking is inadequate to fully keep up with the discussion.
  2. Be constructive.  Very few games are completely hopeless.  Be sure to tell the designer whatever good points the game had, because even if the game is awful and needs to be scrapped, there may be good mechanisms or good ideas that the designer could port over to another game.
  3. Be honest.  On the other hand, don’t sugar-coat negative feedback.  Be honest about the things that aren’t working, and say them, as politely but as directly as possible.
  4. Be specific.  Too many testers simply say “that was interesting.  What are we playing next?”  Try to give concrete examples of aspects of the game that worked well or aspects that you found problematic.  Saying “I didn’t like the auction mechanic” is vague; saying “I didn’t like how the once-around structure of the auction forced me to guess what later players were likely to bid” is specific and helpful.
  5. Emphasize your experience as a player.  Avoid talking about your aesthetic appreciation for the clever blend of mechanisms, or the really original theme he came up with (or at least, talk about these things only briefly).  Comment instead on your visceral reaction to the game.  The reality is that for a game to grab a publisher and the game-buying public, it has to make a strong impression.  Avoid using vague and bland words like “fun” or “interesting”.  Don’t exaggerate (“that was completely exhilarating!”), but talk about how the downtime between turns caused your attention to drift from the game, or how losing that battle in the 4th turn due to a bad die roll was frustrating, or how the decision to buy or sell that stock share was agonizing.  Don’t tell the designer the game was “good”, or that you had “fun” — was the game merely “pleasant”, or was it “a nail-biter”, or was it “hilarious”, or something else?  Try to communicate the level of enthusiasm (or lack thereof) the game produced in you, and be specific (see point 4) about the elements of the game that contributed to that experience.  Anything that got in the way of a high level of enjoyment may be superfluous or counter-productive, so the designer should look to remove these elements, in favor of the ones that produced a favorable reaction.
  6. Describe areas of confusion.  In-progress games can be rough, and as the game changes, the designer’s facility with teaching it may be less than with a published game with a fixed ruleset.  But these considerations aside, what about the game made it difficult to learn, and what rules did you find confusing?  At what point did your confusion about those aspects subside (or are you still confused about them even after playing?)?  What about the physical presentation in the game made it easy or hard to play?
  7. Call attention to other similar games.  Designers haven’t played everything, but they need to know about other games with similar themes or similar mechanisms, to ensure that they aren’t recreating something that already exists, and to be aware of other games that may compete for players’ attention, and dollars.  Mention elements that the games share and point out differences.  Resist the temptation to say which game is “better” — saying “your game is way better!” sounds patronizing, even if true, and saying “the published game is better” is unnecessarily discouraging; of course the designer already knows his game still needs more work, so there’s no benefit to him to hearing that he’s not there yet.
  8. Focus on problems, not on solutions.  This sounds counter-intuitive, but it’s true:  you are not responsible for fixing the game for the designer.  Tell the designer what isn’t working in the game, and leave it to him to find a solution for it.  (Certainly, if he asks for suggestions about how to fix the problem, you can offer any that you have thought of).
  9. Make suggestions sparingly.  Too often, a playtester provides lots of suggestions for ways that the game could be different, without necessarily making it obviously better.  I am terribly guilty of this.  There is benefit to this sort of brainstorming — it may nudge the designer to think in different ways than he had previously.  But it can also lead to a lot of parallel moves in design and development, and as a designer, games take long enough to develop, and playtester time is sufficiently precious, that you don’t want to meander too much; you want design progress to be unidirectional.  Make your “list of other things you could think about or try” the very last, and least important, thing you say to the designer, or perhaps simply write them down (see point 1) as a bullet pointed list and hand them to the designer, for him to contemplate.
  10. Understand the designer’s goal for the game, and take this into account with your comments.  A designer who is working on a light press-your-luck game may not really benefit from your suggestions for ways to make the game deeper and more strategic.  Ask the designer to lay out his vision for what the game is supposed to be in its final state, and aim your suggestions and feedback along the lines of helping him to achieve that vision, rather than making the game more like your own personal preferences.   Although it’s difficult, a good playtester can hang up his own preferences at the door, and accept and critique the game exclusively on the game’s own terms.






Posted on Leave a comment

Talents – a new economic game

There was a discussion in the design forum at BoardGameGeek about designing a game starting with the mechanisms, or a new designer looking for suggestions about how to get started, or something like that.  Anyway, although my general design approach is to start with a theme and think of mechanisms to go with it, as a result of this thread I had the thought to try mashing up a Dutch auction with worker placement, and to see whether a theme could be found that could make sense of this odd combination of mechanisms.  (A Dutch auction is a sort of “reverse auction”, in which the price starts high and gradually comes down until a person stops the bidding and buys the item).  The one I came up with would have made my wife proud — the idea was that players were spending the day hunting for treasures at estate sales and garage sales.  At each sale, several items would be sold via Dutch auction, but the longer you wait for the price to come down at one auction, the less time you’re allowing to go and participate in the other sales.  I think this theme is kind of cute and maybe in some ways better than the one I’m pivoting to.  (And it isn’t really “worker placement” in the strictest sense, as the workers are more like “units of time”; perhaps it’s a bit more like Thebes, with its time track than worker placement).

Separately from this, I had the idea that it would be neat to have a series of games in Belltower’s line based on Jesus’ parables, and the parable of the talents seemed like it had potential for an economic game.  The parable of talents is found in Matthew 25:14-30, and is basically this:  a master gives each of his three servants some of his wealth, and instructs them to buy and sell with it while he is away, to try to maximize his profit upon his return.  Two of the servants double the master’s investment, and the master commends them, but the third buried the talent (a vast sum of money in the ancient world) to avoid any loss, and earns his master’s condemnation.

I’m interested to see whether this auction game could be the economic game about the parable of talents that I was looking for.  And here’s how it would work.  Each player starts with some money, and each turn, a player receives 12 “time tokens”.  There are a series of Dutch auctions; in each, one player presides, and draws and reveals a number of item cards equal to the number of players in the game less 1.  Then he starts the “clock” by placing a pawn at the maximum price, and gradually sliding it down, decreasing the sell price as he goes.  Each time it passes a “chip” icon on the track, all players who wish to stay in must pay one of their time tokens.  At whatever point a player wishes, he may call “stop”, pay the current cost, and take an item.  Then the auction resumes for the other players.  Players then have an opportunity to sell items they’ve collected, with sets of cards of a given worth progressively more the larger the set.  There’s a bit more structure to it than this, but basically, that’s it.  It’s a pretty simple game, that should play pretty quickly.

Design questions that linger include:

Should all of the item cards that will be available for auction each round be visible, or only those from the current auction?

I am inclined to start with only the current auction, to avoid information overload, but being able to see all of the items would help with strategic planning, so it’s something to consider.

Should the money come in the form of cards or plastic coins?

There’s something thematically cool about having actual coins, and actually there are some neat opportunities thematically above and beyond this, so I’ll discuss more about this in a future post.

Does a multi-item Dutch auction actually work?

Your guess is as good as mine!  If not, perhaps the auctions are for several items, or the auctions could each be for a single item, and perhaps instead of collecting sets of items, which have a rigid payout, you could be trying to fulfill “buy orders”, which call for a certain item at a certain price, but these change in value, or new buy orders are dealt out, each turn.