As we head into the playtesting period for The Strange, I am reminded of an article I wrote last year about what I think makes for a good playtester. Here are the salient points from that article about what sorts of feedback I think a playtester should provide:
1. Appropriate feedback. An important part of being a playtester is the ability to understand what it is you’re looking at, and understand what portion of the process you are a part of. For example, if someone sends you a rough version of just the basic rules just to test the basic concepts, and your feedback is all about typos and information presentation, you are being the equivalent of a pilot trying out an experimental aircraft and commenting on the leather on the seat and the lack of cup holders. It’s not that those things aren’t important, but early on in the process, that’s noise, not signal.
In other words, give what’s asked for. Don’t do extra work that’s not asked for, not just because it’s a waste of your time, but it’s a waste of the designer’s time to get feedback that’s not needed at that time. If you’re being asked about game mechanic concepts for a skill system and you provide feedback about skill names, that’s probably only going to annoy the person on the other end. If you’re being asked for feedback on skills as a whole, I’d say feedback on mechanics, names, or anything else to do with skills is fair game, but I still wouldn’t provide commentary on NPC design, or anything outside of skills.
As an aside, I will add that commentary on names of things or similar “this is what I thought of when I read through the document” kinds of feedback isn’t the most valuable playtesting report you can give. Frankly, as a playtester, I’d probably skip that kind of stuff. If you’re being asked to playtest, you’re being asked to play the game and report what happened. Names of things, rules phrasing, and things like that are part of the game developer’s and editor’s job. It’s important, but it’s not playtest feedback material. Again, let someone else worry about the cup holders.*
On the other hand, if someone says, “just give me any comments you have,” then anything’s fair game. (Although I’d question the competency of the designer who would say that, because playtesters need direction to provide good feedback.)
2. Feedback, not opinions. This is a tricky one for people to understand. If you give me a piece of coconut cream pie to see what I think, and my reply is, “I don’t like coconut,” I’ve given you an opinion, not feedback. It’s honest, but it doesn’t help you with your pie at all. In playtesting rules, know yourself. If someone asks you to test a game that uses a single die, and you love dice pools, and you know that your feedback is going to be “you should use a dice pool mechanic,” you haven’t really playtested anything. If someone’s asking you for opinions, that’s fine, but if they’ve already reached the point where they’re showing you their written up system, they’re probably past the stage where talking about the core die mechanic is of any use to them. Like the piemaker has already decided that he’s making coconut cream, the designer’s already decided what kind of game he wants to make. What he wants from you is feedback as to whether the game as currently written meets the stated goals.
3. Be a playtester, not a designer. Don’t redesign what you’re playtesting unless you’re asked to. (And frankly, if you’re asked to do so, you ought to be given designer credit and a paycheck.) Give feedback on what you’re testing, not on what you wish you were testing. There’s a big difference between saying “Our group thinks that this bonus is too high,” and “What you should really do here is…”
And while we’re on the topic, if you really want to know what distinguishes a great playtester from an okay playtester, it’s this: Don’t say, ”Our group thinks that this bonus is too high,” say, “Almost everyone in our group selected this action every time, because the bonus seemed much better than the other options.” The difference is, you’ve provided a rationale with your data, and you haven’t corrupted your data with opinion of any kind.
Still, I’ll be blunt. A lot of people see playtesting as on opportunity to show a game professional that they have what it takes to be a game designer. I’ve been doing this a long, long time, and I can honestly say that I’ve never seen playtest feedback be a good forum for showing off game design chops. Playtesting is a good way to show off how good of a playtester you are. If you want to show off that you’re a good game designer, design a game.
4. Record but overlook the problems. This might sound like a contradiction with #3, but hear me out. If your group tries the game, and the initiative system doesn’t seem to work at all, don’t just stop. Cobble together some initiative system that works at least passably and then keep playing to test the rest of combat. If you just tell the designer, “the initiative system didn’t work, so we stopped,” you’ve only given one, very small bit of feedback instead of a whole report.
Instead, briefly detail what you did to make initiative work and then give your report on the rest of the game. In light of #3, don’t phrase it as though you’re initiative solution is the only one, and–most importantly–don’t do this unless it’s absolutely necessary to rest other mechanics. Only do this to a small problem, not to the core of the game. To use the extended example, don’t change the mechanic to a die pool and then test everything. It’s a waste of your time and theirs.
*I’m going to get flack from someone who thinks that I’m comparing development or editing to designing cupholders. That’s not what I’m doing at all. I’m just saying that everyone has a valuable role to play, and should be allowed to do it.
