Some Play-tester Tips

 Some Play-tester Tips


Hey y'all! I don't have a ton of experience with play-testing. But I will say that I've play-tested for Fantasy Flight Games and their most recent Star Wars Armada expansion wave (the Venator, Pelta, Providence, and Recusant), as well as play-tested 4 games for one of the bigger companies out there. So I've got enough that I feel comfortable offering the following tips if you'd like to be a helpful play-tester! I'm sure I'll think of others as I get more experience and as I move into play-testing stages with my own designs, but for now, these'll do!
  1. Ask what you're testing for. What I mean by this is you should ask the play-test organizer what questions they want answered. It may be something as broad as "how did the game make you feel?" or "was the game suspenseful for you?" or it may be something as specific as "how did you feel about this single scoring formation we're testing?" or somewhere between the broad and specific such as "how did you feel about the length of the game?" If you are not given targeting questions before playing, ask. There are a lot of other things going on for the play-test organizer and the designer(s) and they may have forgotten to tell you what questions they're trying to answer, because every play-test has specific aims in the design process. I've never once met a designer or organizer who minded my asking this question before a play-test. Also, even in shorter games, it's possible that when these questions are asked at the end, you may have been so involved with other aspects of the game that you don't really have any solid information or data to offer them during the debrief. During the last thing I play-tested, I forgot that one of the objectives was new and I hadn't paid it much mind during the game. If I hadn't known we were testing for that one objective and taken a couple of notes as to why I hadn't bothered with it, I may not have had useful feedback for the designer. So go into each play-test knowing what questions the designer is seeking to answer. It's super helpful for everyone around the table and in the design space!
  2. Take it seriously. By that, I'm not saying there shouldn't be any joking around or that you shouldn't have fun, but I do mean that too much fooling around can skew the data. Ever play a game that should only take 20 minutes, but instead it takes 35? What about playing a mission of Descent or some other campaign game that could've been over in an hour, but lasted 2 and a half instead? Yeah, we've all been there. And in those situations, I might start checking my phone, getting bored, be ready to move onto something else...it can just be very frustrating for players around the table. Oftentimes, designers are trying to nail down how long their game actually lasts so they can closely consider the rhythm and pace of the game. They may be trying to figure out what timeframe they should be stamping on the side of the box. It's likely that other peoples' impressions of the game are skewed by how long the game is taking because they've got other stuff to do or because the design isn't meant for a 75 minute session and so players may feel bored and that colors their reception and feedback. Joking around and thinking through one's moves has been encouraged in every play-test in which I've participated. But there's definitely a limit, and beyond that limit, data points start skewing in ways that don't necessarily reflect the design. So things that don't need to be changed might get changed as a result. Also, it's frankly just irritating when someone is trying to ask a game-related question and everyone is interrupting or talking over that person. It should absolutely be fun! But try and keep in mind that there's a purpose to the play-test beyond the fun.

  3. Be specific in your feedback. Specifics are important. It's not enough to say that you were bored with the game. Why were you bored with the game? Too much downtime? Not enough interesting decisions? Were you lost and just didn't know what to do because you didn't understand the rules? Each of those are valid reasons to be bored and the designer definitely wants to know if you were bored because nobody buys boring games! But there are different solutions to each of the three reasons for boredom that I listed above and there's rarely a solution that answers all three questions in one go. Your experience with the game is valid, whether you enjoyed playing it or not. But it was only your experience, which means you need to offer specifics if anyone else is to understand and address your feedback. I've definitely played games in which I ended the game feeling one way, but after debriefing, someone offered some feedback that clicked with me and changed my opinion. Maybe I don't swing hard from "I hated it" to "Oh! It turns out I actually loved it!", but my feedback might change. I have played Stonemaier's Scythe exactly once and I did not enjoy it. Honestly, it was so long ago that I now cannot recall exactly what about it I didn't enjoy. I'd like to get back to playing it at least one more time because everyone else I know really enjoys the game. So I think I'm missing something. I know that I expected to use those mechs to do battle and that's just not the game at all. So I walked in with expectations that were not met. That absolutely colored my experience. So much that my next play will be totally different? I couldn't say. But I can say that I'd like to give the game another shot because it bothers me that I didn't like it, but I can't specify the why.
  4. Think through your feedback. Concise feedback is the most helpful, in my own experience. It may sometimes be difficult to get a handle on a thing you liked or didn't like about the game or how it played and talking through it sometimes helps. But I've also heard a lot of meandering and mulling over a topic during the debrief and honestly, it just kind of kills the mood people are in to offer feedback. I become less enthusiastic about offering my own feedback and hearing feedback from others when one person is dominating the conversation and just sort of theorizing their way through their experience. There's a time and place for that, and I find that I'm more forgiving when there's some sort of preface: "During those last two turns, I felt like I didn't have any options. And now that I'm looking back, I think I can see where I got that impression even though it was false. And I'm not sure if that's a thing that can be addressed through the rulebook or a disclaimer or just mechanical design of the game, so I need a minute to sort of talk it through." Thinking through feedback also helps piggyback on what other people offer - they might offer a solution to another problem that actually applies to some of your own feedback. Thinking through why you're saying what you're saying can really help you stay concise and clear so the designer knows and hears what you're thinking instead of having to sift through a diatribe to see whether or not what you said was valuable or just blowing smoke.
  5. Don't play to win so hard that you tack an extra 30 minutes onto the game. Seriously, y'all: don't do this. There are some games that reward such careful thought, but more often than not, we get caught up between two choices, the difference between which is basically six to half a dozen. Play to win the game, but don't forget that winning the game is not the objective; the objective is playing the game so that the designer can collect data. Winning is fun and how people win during a play-test is important data. But sometimes, we just need to play the dang thing, yeah?
  6. Try to break the game. This one is important, but there's sort of a time and place for it and how you do it. While breaking the game, please abide by the tips I outlined above. No designer wants their game out in the world for a week before someone finds a fool-proof strategy that invalidates any other choice a player will make. So breaking the game during play-testing is huge. If you find a combination and can't figure out why you wouldn't just do the same thing every single time, that's worth exploring! But don't spend a million years during game play figuring out the perfect move. Odds are that if you're thinking about it that long during the game, you haven't actually found the thing that breaks the game. It's possible! But it's unlikely. Also, it's obnoxious. If you really need the time to think through that, ask the designer to save the board state or make a note about it so you can revisit it. It's not worth blowing up an entire play-test if it's going to take you an extra hour or so to figure out exactly how to break it. The feedback, though, is invaluable! So don't just forget about it! I'm just saying that consider how you approach it.
Honestly, in my experience, those are the biggest things to consider. I'm sure there are things I didn't think of and I'd love to hear from you if there's anything big you think I missed! I consider it a great privilege to play-test games. It's super cool to see games (for me, anyway!) develop and evolve. Being present in the early stages of a game and seeing how far it might come is really fascinating. And if the end product is a game I like, then I got to be part of this industry I love and contribute to someone else's joy in playing said product. Not everyone feels the need for that and that's cool! But for some of us, it's something pretty special. When the New York Giants beat the Patriots in 2007 to win the Super Bowl against all odds, ending the Patriots' undefeated season, I got all sorts of phone calls and texts congratulating me. I don't work for the organization and I never have. I didn't help them earn the Lombardi Trophy in any way, shape, or form. But as a proclaimed fan of the team, I get to be a part of that win. I get to feel the highs of that win. It's really damn cool. That's some of the deal here, except I actually get to be part of that development. Maybe I offered some really useful feedback and maybe I didn't. I won't always know. But I get to be a part of that win, because honestly, publishing any game at all is a win. And that's pretty damn cool.

Comments