Playtesting Best Practices

Sunriver Games is just starting a new round of playtesting games we’re considering publishing, so this week’s column is about what seems to work best (and worst) in playtesting – for the author, the publisher, and for the playtester. I’m happy to take input on any and all of these, and so develop a better “best practices” list.

Being the Playtester
First, if you’ve never tried this game out, even playing it yourself, tell me up front. If you’re a good friend and we’ve playtested each other’s stuff, some of the following rules can be broken at any time. =)

My Core Set of Values. I prefer to see decent graphics and a prototype that is more than just felt tip pens on blank cards or butcher paper. If you have an idea for theme, I want to hear it. It absolutely helps get me in the mood of the game. I don’t need written rules, but a player aid is nice in case I forget some of the rules you explained to me. If there’s scoring at the end of the game, give me a reminder that shows me what I’m shooting for. Spelling errors take my attention off the game, so please check the cards, tiles, or whatever before we play. If you have several versions of mechanics, let’s concentrate on what you want to test today – later we can discuss the other stuff.

After the Game. If you have some standard questions you ask everyone, write ‘em on a note card. I played this game to help you, so I’d like you to be a good listener if you do have some questions. It’s okay to explain why you chose a particular path, but if you argue with me about why your way is “right” you might lose me for next time. It’s not bad for you to write down my input and come back to me with more discussion later. The more work I do for you, the more likely it is I’d appreciate being listed in the credits if you get published, or getting a good price on a published copy.

Being the Company
We’ve decided as a company to look at designs in-house and out-of-house. This time we’ll be looking at two multi-player games and one or two 2-player games. Our goal is to gather data to then compare against similar results from last year’s playtests.

Live Testing. We meet as a company and pick a couple dates a month out or so. We pick a nice place, like a meeting room at a library, business, etc. that has tables, bathrooms, good light, and will allow food. We announce the dates on our Website, in the groups we play with, and to our email list of interested people. At the event we do name tags, shuffle people around from game to game, and provide food and drink during the day. We also have some door prizes or other ways to say thanks for giving us a day.

The games are usually nice prototypes with copies of rules and player aids for each player. The whole room plays game A, then game B, etc. so we can explain the rules and answer questions once as a group. We tell ‘em what we’re looking for, and have feedback sheets to fill out so we can capture a lot of data for later review. And we usually provide an optional dinner at day’s end for people who want to talk out some of their ideas.

Blind Testing. After we selected HAVOC as the first game we’d publish, we asked for volunteer game groups to give it a try. We sent out seven sets for blind testing, paying Priority Mail and International Mail Rates. We offered support by email, our website, and by phone. We made sure we had a primary contact, and we included questions we needed answered, with feedback sheets to fill out to capture the data.

Upside. Groups played HAVOC more than once, with different mixes of numbers or types of players. They gave us great feedback on which rules were hard to get, or ideas on how to fix those. We got feedback on some newer rules we weren’t sure about. And they didn’t all like the game. That was a bonus for us, since they were willing to say what they didn’t like. Honesty is awesome.

Downside. Some groups didn’t even try our game for a month. Some groups never played it as far as we know. Even though we paid return postage, we never got back some of the prototypes. Some groups returned the game with little or no data on who played or their comments. We waited too long for feedback that never came.

Next time we’ll try to fix some of what went wrong. One clear message: Please don’t sign up if you’re not sold on helping the company that asked you. It slows the process when someone says yes but means, “I think maybe I’ll consider helping if I feel like it when the game arrives.” If you said yes but find you can’t do the work, just tell us right away so we can ask the next group.

Being the Designer
Here’s what works for me. I conceptualize a design somehow, usually with lots of notes and drawings. If I have rules I write them down, at least the critical ones. Before I even consider foisting this new game on my friends (who I want to keep as friends!), it’s critical to test the game myself. I can do this a few different ways.

Do it all in my head or on paper. This is the worst for me, so it only works on very simple games. I recently designed a kids’ game based on Badger Badger Badger. It was simple enough – draw tiles from a bag until you decide to stop or get stopped by the game (drawing bad tiles). So this one I could self-playtest just by envisioning.

Make a paper copy. It just has to be enough for me to sit in the living room and simulate three or four players playing the game. Early copies of Pizzza were tiles cut out of typing paper, played on hex-grid paper.

Play on computer. I use Excel for most of this. I can shuffle cards or tiles, simulate blind draws or bids, have basic graphics if needed (like for tiles that rotate).

Once I self-test the game, it’s ready for a real world test. I generally prefer to make a decent-looking prototype since it’s what I prefer to playtest of other people’s games (see above). I can make cards on card stock; a white on the back is OK unless the card back is important. I can make tiles by printing to label stock and pressing the labels onto report covers or even cheap floor tile to give them a little heft. I’ll make rules, but usually only player aids or score sheets for first round testing.

I’ll take the new game to groups I play with, and usually at the start of the game session I’ll let people know I brought it. Sometimes it will get played, sometimes not. That’s all part of friendly group dynamics. I try to be appreciative of anyone who gives a game a try, and listen to any feedback. I will also take new prototypes to game cons like Portland’s Game Storm, Seattle’s Dragonflight, and Dallas’ BGG.con. For cons, I write down names of players, emails if I can get them, and player feedback. I have a few “convention friends” that will come see what new games I have every year!

OK -- a long post today but I felt I wanted to get my basic set of ideas out there for all three playtester groups. Thanks in advance for your feedback, whether posted here or emailed to me.