Skip to Content
 

Playtesting, with the designer watching?

8 replies [Last post]
Tue, 03/27/2012 - 01:22
Shane
Offline
Joined: 03/26/2012

Hey everyone, I'm a couple weeks away from playtesting with a prototype version of the game. So far, I've always been one of the players when testing the game (primarily because only I knew the rules and was still figuring out the mechanics to ensure the game was as smooth as possible).

However, I'm almost at the point of letting others play test on their own and I was wondering what your guy's thoughts are on being around when others play test your game. Should I be in the room watching? Should I let players play on their own and then QA the results/thoughts after? Should I film sessions and treat them like a focus group?

What has worked most effectively for your games?

Top
Tue, 03/27/2012 - 09:17
#1
Orangebeard
Offline
Joined: 10/13/2011
Mixed approach

Hi Shane,

Personally, I favor a good mix of playtesting. Like you, I initially play the game alone and then with other people. Later, I play the role of referee or consultant during the game and, eventually, fully blind testing. Below are some of the things that I usually see at each stage;

Playing alone - Does the game work? Are there any major missing elements or game mechanics? Have I considered all of the required pieces? (crap! I forgot to make a game board!)

Group Play - This is both a chance to play and teach the game. Ultimately, teaching the game will help you write clear, concise rules and may help you develop some "flavor" text that helps grab player's attention. You will also learn very quickly if your terminology is confusing or if the rules need to be presented in a particular order. A few rounds of play should expose any major flaws in the design.

The "Referee" - I'm in the room with the players observing. In some cases, I will clarify rules; in other cases I will not clarify what I meant, but will instead see how the players go about resolving the confusion. I like to use this time to observe any emerging strategies, design flaws that lead you to "negative" game play (ie "kingmaker"; catch-22; impasse) or themeatic elements that don't make sense (the fire mage can only cast...lightning bolt?). I also look for issues with the game pieces (for example, most players "fan" their cards when they are holding them; this only works if general information about the card is written in the corners or edges; otherwise the players are constantly flipping through the cards trying to figure out if they can play them). At the end, I try to do an exit interview with the players.

Blind testing - Where the rubber meets the road! The players get the rules, the game pieces and no additional input from me. Don't forget to include the playtesting results form! Since you aren't there to observe, you need a clear method for collecting details about the game. I try to get as many details as possible; similar to a game play journal or log. Who won? Why? Who lost? Why? Did all the players use the same strategy? Was there a single strategy that is clearly dominant? Did the game end suddenly as the result of a lucky card or play? Was it a fight to the finish or did the early leader crush everyone? Try to capture this information at ALL stages of playtesting.

As always, take notes on everything! Observing a player reading a card 2-3 times might indicate a place where the rules need to be clear. Players grabbing calculators to calculate their current life total might indicate a simpler system is needed. Confused looks, indifferent play style and big yawns might suggest that the pace of the game needs to be adjusted.

And don't take it personally when they say "that sucked"! But don't let them get away with that either! If they think it sucked, try to get them to explain why; they don't need to "solve" the game issues, but they should be able to explain why they didn't like a rule or mechanic.

Good luck with your testing!

Top
Tue, 03/27/2012 - 09:19
#2
Dralius
Dralius's picture
Offline
Joined: 07/26/2008
I find that being present but

I find that being present but non-obtrusive provides me with the best results. Sitting nearby I listen to the conversation paying attention to the players emotional states before, during, and after the game.

Was the player that complained the game was too long obviously fatigued?
How much laughing & joking went on or was the game quiet and intense?
Are the players discussing the game afterwards?

These are the kind of questions that can’t be answered with blind testing.

I’ll then ask a series of questions based on my observations and what I’m trying to get out of the session.

Top
Tue, 03/27/2012 - 12:15
#3
Shane
Offline
Joined: 03/26/2012
Thanks Orangebeard and

Thanks Orangebeard and Dralius, you both have some great advice. I'm excited to start diving in as soon as I get this prototype printed up (and the last few cards designed). I'll be sure to post my results.

Top
Wed, 03/28/2012 - 02:32
#4
Traz
Traz's picture
Offline
Joined: 04/06/2009
testing...testing...

As mentioned, there are many methods to jump your game through the hoops. I discovered another one two years ago with my own GODS ALONG THE NILE at a Design Contest.

I had been demoing GATN at a number of Cons with rave reviews and wonderful acceptance. Then I took it to the Design Contest and it was hard slogging.

The difference? At the Cons, I was able to explain the game slowly in a comfortable atmosphere. At the Contest, it was a pressure cooker and I had to force feed the game system. Slow and amiable doesn't expose design flaws, but force feeding does [with a vengeance].

WhatI thought was a clever game mechanic was actually a hard concept to teach and ultimately affected the pacing. Based on the experience and the awesome feedback cards I got, I recognized the problem area. I tweaked the mechanic, simplified it, and...

VOILA! Not only did it resolve the problem [that I wasn't seeing], but it simplified the game without sacrificing anything. It also improved the flow of the game [shaving 30 minutes off playing time!!!] and introduced a basic level of player interaction - which was the biggest complaint.

I wouldn't have discovered this on my own, but the pressure cooker atmosphere brought the flaw to a boil and tenderized the entire experience to where GATN is one of my best games now!

If you don't have access to a Design Contest, try explaining [and getting the max number of players to play your game] within 2/3 normal playing time. Set the clock and stick to it. Pass out feedback cards and ask nicely for honest, blunt opinions. It'll do you good! Even if everything comes out great on the other end, you'll have put your game through the paces and confirmed that everything is exactly where it needs to be.

Top
Wed, 03/28/2012 - 09:46
#5
HandwrittenAnthony
HandwrittenAnthony's picture
Offline
Joined: 12/01/2011
OrangeBeard's overview is

OrangeBeard's overview is pretty extensive, and close to the same that I put my games through.

It's a good idea use the right kind of playtest for the design issue that you are getting feedback for. Blind testing is great for getting feedback on usability and themes, but sitting-in can provide better data for mechanics and victory conditions.

As a rule of thumb; if I'm testing the mathematics of a game, I'll guide the session so the real numbers can get a proper workout.
If I'm testing the language of a game, then I'll sit out and allow the game to (try to) communicate for itself.

Top
Wed, 03/28/2012 - 11:02
#6
larienna
larienna's picture
Offline
Joined: 07/28/2008
After play testing alone many

After play testing alone many dozens of time, when you have a working game, you can start to test with real people.

You can play with the people, but sometimes it's more demanding because you need to watch the game while supervising everybody.

If you do not play, it is important that you watch. Because this is how you will observe the behavior of the players. You will be able to see if players prefer to do something instead of some other things.

When you are at the final stage of the design with a solid rule set, do not explain them the rules, make them read rules and play. You will be able to see the things which are not clearly explained in the rules when the players are confused, or do not do the right thing.

Remember that a game requires at least 50 playtest (which includes solo test)

Top
Wed, 03/28/2012 - 13:05
#7
Shane
Offline
Joined: 03/26/2012
This is all awesome advice,

This is all awesome advice, especially for someone new to board game design. Larienna, you answered my next question which was going to be "how many times should you play test before you feel comfortable saying it's ready for production?"

I'm the type of person who always finds something to nitpick. As an artist, I'm never satisfied with a sketch, design or painting. Reading all these comments makes me so happy I joined this forum. The wealth of knowledge is fantastic.

Top
Wed, 03/28/2012 - 16:35
#8
Matthew Rodgers
Matthew Rodgers's picture
Offline
Joined: 03/01/2012
It's Never Done

Making the call to cut off changes to the game is very hard... I think larienna's advice is good, but I would be leery of saying a certain number... some games may need many more than 50 tests and some (very few) might be able to get away with less.

Most of your initial revisions will be self-starters (either in eigen-testing or in regular playtests)... even in "supervised" playtests you'll notice players struggling with something and know that's something you must address. Once you move into blind playtesting, you've got to divide issues into "failures of communication" and "changing design goals". Every failure of communication is an issue you must resolve, it is your fault that the playtesters didn't understand the rule or where to put the piece or whatever. You've got to make changes (maybe to wording, maybe to graphic design) to prevent that issue from coming up.

However, when playtesters report something wrong with the game engine, then you have to evaluate whether something is broken or if the complaint is part of the design goals. When playing a game, we may bitch about making hard choices, but hard choices are what makes strategy games fun and interesting... don't automatically capitulate on these issues, evaluate and see if maybe the tester has preferences that just don't match up to your design goals. Eventually, you'll get to a point where the communication is resolved, when you get to a point where you're only getting design goal feedback, then you're nearing the point when you can say "can't make all of the people happy all of the time" and call it done.

Top
Syndicate content


forum | by Dr. Radut