I was listening to one of the Metatopia panelcasts from last year, and the panelists[*] mentioned that there are different types of feedback and wouldn’t it be nice to have a way to say what kind of feedback you wanted. Well, I agree, and it’s something I’ve been meaning to write about. So here goes.
Before I start, let me say that when I send my games out for feedback (playtesting, normally) I always provide a list of specific questions. This is partly to ensure that specific things I’m wondering about get covered; it’s partly to avoid feedback I’ll find unhelpful; and it’s partly to provide a structure to help people think about the play experience. But anyway. Let’s talk through different kinds of feedback.
- Drafting feedback. This includes identifying spelling and grammar errors, as well as areas where language might not be as clear as it could be. You might want this when your game is in its final draft form. You probably won’t find it that useful before that point, because you’ll be redrafting anyway.
- Comprehension feedback. This is a bit like drafting feedback, but a bit higher level. It’s asking whether there are aspects of the rules that are confusing. Can you understand the game? This might be particularly useful for an early draft read-through. I normally check on it with playtesting as well.
- Experiential feedback. What did the game feel like to play? Was it humorous or scary? Was a particular mechanic hard work? Did you get emotionally invested in your character? This is generally a key component of playtesting for me. I want to create a game that feels a particular way, and so I need you to tell me what it felt like to play it. That’s much less useful if you’re just testing out a mechanic in isolation, though. You also might not need it so much if, say, you’ve already playtested the game quite a bit and you’re just testing a modification to the original design.
- Mechanical feedback. What happened, mechanically? Did you seem to crit fail constantly? Was there an exploit where you could build up unlimited bennies? Did some mechanics just never get used? Did anything break down at the table? You’ll probably want this sort of feedback at some point in playtesting, unless your game is super freeform. Some people like to playtest mechanics individually, outside the context of a full session. It’s not something I do, but worth considering.
- Design advice. It is often said that it is very annoying when people try to design your game for you through their feedback. And generally, I do agree with that. But, sometimes that may be exactly what you want: you know something isn’t working in your game, and you want suggestions on what to do about it.
So, when you’re asking for feedback on your game, be clear which kind(s) of feedback you’re looking for and, where appropriate, which kinds you aren’t looking for. I would add that you can, and probably should, say which specific bits of your game you are asking for feedback on. If there’s a particular mechanic or aspect of play you want to hear about, say so! Even if there isn’t one particular aspect, you might want to break your game down into specific areas you want covered.
Of course, it bears noting that you might not always realise that you need feedback on something. Maybe you think your mechanics are working perfectly and you don’t need feedback on them. If a playtest reveals they broke down completely, I’d hope my playtesters would tell me that, even if I was only asking for experiential feedback.
I hope that’s useful. I’ve probably missed something. Comments welcome!
[*] I don’t know exactly who said it. Panelists included Emily Care-Boss, Julia Ellingboe, Avonelle Wing, Shoshana Kessock and Amanda Valentine.
3 thoughts to “Game feedback: different kinds”
Re 5, although I’ve only very rarely actually used a suggestion that someone gave me, the suggestions they make often help me to see a problem in a new light, which leads to a better ability to solve it myself. I find it pretty useful mostly, and not annoying, provided the suggestion givers aren’t precious about their suggestions being used 🙂
Re 4, I think it’s risky to rely on this as your main (or only!) source of analysis about your mechanics. You can analyse mechanics pretty thoroughly using static techniques, i.e. methodical analysis of all the possible branches, probabilistic analysis of the outcome distributions, etc. etc. This is a much more reliable way to do it IMO than relying on a small and almost certainly statistically insignificant number of playtest games. Similarly, I’d want to have identified any mechanics that “never get used”, or are otherwise flawed, in internal playtesting, well before I ship a game out to playtesters I’m not going to directly oversee. (Ben Lehman made an interesting, if somewhat sensationalist, post about this stuff here: http://lumpley.com/index.php/anyway/thread/565)
To my mind, this is the least useful type of feedback to request for those reasons. (Though like you, I’d still ask and expect my testers to proactively alert me if anything went drastically wrong.)
Addendum: Ugh, that thread. Read only if you have a strong stomach. But it does also say some interesting things about the other types of feedback, as well!
Oh, this applies to all forms of game feedback, not just external playtesting. You’d obviously hope to catch most mechanical problems before you even start playtesting, but some stuff will naturally only come out through a second pair of eyes and/or playtesting.
I think you’d be surprised, though, how often these things do come out in the external phase – I think a lot of properties of a game (well, most RPGs anyway) are emergent from the combination of psychological and social factors and the totality of the rules (which might be different from the individual rules). It’s easy to miss some aspect of it, and even if you’ve extensively internally playtested that’s vulnerable to the fact you’re in the room, potentially helping to cover up issues with the game.
I think the Ben Lehman post underestimates the extent to which, as he puts it “the parts of your game where the mechanics and processes of your game interface with the players at the table” pervade play. Even ostensibly simple mechanics like “pick a stat and a skill and add them to a d6 roll” require interpretation and use. At any rate, I found the playtesting for Lovecraftesque (which is my main point of reference, of course) immensely useful. I really don’t think that’s a matter of luck. I agree with his broad point that playtesting doesn’t solve all problems, but I do think it’s pretty much indispensable as part of the design and quality assurance process.