Playtesting Maxims

If you were writing maxims for being:

a) A good playtester
b) A good designer during a playtest

what would you write? These can be as specific to your needs, or as broad/general as that you think it should apply to anything.

Examples of maxims:
* Playtester: Don't break the game.
* Designer: Don't get angry at people's feedback.
* Playtester: Describe how you felt, not how you would fix it.

Comments

  • edited October 2017
    Playtesters : I dare you to cheat ;)
    Designer : Watch the players, don't ask :|
    Playtesters : Socialize only if it's in the rules. Eat only if it's in the rules.
    Designer : Timeline your notes.
  • For the designer:

    Know your goals; "playtesting" is an umbrella term that doesn't really mean much on its own. Is it even playtesting that you need, or is it outside eyes?

    Don't waste other people's time, that's not courteous. Prepare well, don't playtest until it's actually useful, and respect the people bothering to help you with playtesting.

    When doing explorative playtesting, prep your questions well while being open to different reactions and solutions. If you don't know what you're looking for, you won't notice it when you see it.

    When doing affirmative playtesting, leave the designer out of the game - either you are a player for the duration, or you shouldn't participate at all. Observe, above all.

    Don't waste playtester effort on meaningless feel-good feedback cycles; just get what you need, don't pretend to care about their opinions or experiences if that's not what you're after.

    Don't be after data that is not actionable, that's just wasting everybody's time. Don't test to "find out if they like it" if you do not have an action plan for what to do with the feedback. Playtesting is not for salving your own insecurities or a mere rote to satisfy, that is again just wasting everybody's time.

    Document your playtesting well and prepare to process the data over a long time-span. Not making notes (and further processing those into memos soon-ish) is essentially wasteful of the effort put into putting the playtest together in the first place. It's exactly like archeology: if you're going to go to the effort of doing a dig, you damn well better pay attention and make the most of it.

    If you think that you don't need studio critique and playtest, check your assumptions: are you really so well attached to the drumbeat of civilization that you do not need to test your material before productizing and publishing it? Nobody else can grant you a fresh and useful perspective, and you do not need to see your material in action to know it works? Really?

    Don't ask for critique if you don't want it, need it, or can't handle it. If you get upset by solicited feedback, that's totally your problem and nobody else's; don't expect to find work in the culture industry, we hate primadonnas [grin].

    For the playtester:

    Ask what is needed from you. Don't assume that you know what the playtest process is for, as there are various reasons for playtesting and games at different stages need vastly different work done on them. If you're unclear on what you're supposed to be doing, ask the designer until you know.

    Be a tool for the project, facilitate it. Playtesting may be fun, but that is an accidental byproduct of your interaction with the process; the true satisfaction is in being able to help the project along.

    If you are asked for critique, then do that: observe the project holistically, ask when something does not make sense, tell when you see room for improvement. Be honest, you presumably were not asked to say nice things while knowing better.

    If you are asked for your experiences, also provide useful, succinct background context for the same. Play experiences are always contextual, the designer needs to know your frame of reference to judge the information.

    If you are asked to play the game, then play it conscientiously, focus on it. If you can't (the game doesn't interest you or you're tired or whatever), then log that information with the designer - they'll know if they want you out of the test, or if they can use a non-optimal player nevertheless.
  • James,
    Regarding your "Playtester: describe how you felt not how you would fix it?" If the other playtesters have a lot of experience with RPG's and or design itself, I would say that describing how they felt would be a good and important first step. However, after doing so, and after some reflection on their part, I don't think that getting some ideas from them about fixing things would necessarily be a bad idea or unproductive—especially, if they understood the larger picture, the goals of your game, etc. I definitely do agree that it would be important that they give feedback about how they felt first. BTW, this is an excellent and very useful topic, and you have organize your questions well, and in a way that should provide some great feedback. One thing I would suggest is that others provide context (if necessary) when providing maximums for playtesting and being a playtester; I think that the type of game and the goals of the game might need to be considered in regard to whether or not a given maximum is a good fit for situation. Hopefully, everything I'm saying makes sense; I'm just rambling it off quickly. Anyway, thanks :-)
  • It does! The examples I'm providing are models: my using them as examples neither confirms nor denies my approval of them. :)

  • edited October 2017
    “Don’t *try* to break the game” sounds good to me. If pieces come off in my hands while using it, that’s part of playtesting.

    For designers: what do you want to know? How is it supposed to work? Are you worried your point-buy system is too fiddly, or do you just need help finding exploits?
  • Designer.
    From personal experience.
    Shut the fuck up! :)
    Take feedback as it comes, nod with an air of mysterious understanding, but refrain yourself from explaining/defending the game. Just don't! ;)
  • Designer.
    From personal experience.
    Shut the fuck up! :)
    Take feedback as it comes, nod with an air of mysterious understanding, but refrain yourself from explaining/defending the game. Just don't! ;)
    We have a winner!!!
  • I think in DIY land, designers and playtesters can't always get exactly what they want. Often, compromises are necessary. With that in mind:

    Designer:
    Know what you're testing, and then actually arrange to test that.

    You don't need a 4-hr session to test if combat is balanced. You don't need combat to be balanced to test the character creation and GMing procedures.

    Some really important things really can be tested in 15 minutes with one other person -- do that, rather than organizing a full group game night.

    Playtester:
    Be honest up front about your interests and limits. If you really just want to have fun and play, say so. If you love testing systems for breakpoints and exploits, say that.

    Once the designer knows what you're up for, ask what they're looking for from you. Do your best to provide that.
  • Nice! Agreed in full.
  • Designer: running playtests is only a mediocre replacement for experience with previous art. If there are games out there doing similar things as yours (there probably are some), having played them can help your design more than playtesting it too early.

    Playtester: when you agree to playtest in the absence of the designer you're actually looking at a 2x time commitment - first, actually play/test/ing, then reporting. Don't underestimate the "reporting" part: it's hard work. I've discovered this the harshest way, by trying out people's games and then failing to report adequately because I'd failed to factor in the time - which means I let those designers down (and I'm sorry for it).
  • One way around that is to record the session, and then send it to the designer. i've seen that done in couple of times.

    Another factor, though, is the time you need to learn the rules and the game. I find that easy to underestimate sometimes.
  • @David_Berg
    Very good insights, David.
  • edited October 2017
    Hi @Eero_Tuovinen, these are great suggestions. I was hoping that you could answer some questions about your playtesting comments for those of us with less playtesting experience than you and less knowledge of the vernacular.

    ...explorative playtesting...
    ...affirmative playtesting...
    Would "explorative playtesting" be when you are honing you game and exploring what works and doesn't to fit you design goals...when you are still making major changes? And would "affirmative playtesting" be once you have made a working first draft and are working on more subtle issues and nuanced adjustments?

    ...studio critique...
    What is the difference between a "studio critique" and a playtest? Is a studio critique feedback from a publishing house? Or a playtest where someone else runs the game, preferably someone with more experience, who gives you feedback and a critique of the session? Or something else entirely?

    Don't waste playtester effort on meaningless feel-good feedback cycles; just get what you need, don't pretend to care about their opinions or experiences if that's not what you're after.
    Can you talk a little bit more about what you mean by this, give an example and how it would work and play out in a social context?

    Thanks, Eero. Very much appreciated.
  • Hi @Eero_Tuovinen, these are great suggestions. I was hoping that you could answer some questions about your playtesting comments for those of us with less playtesting experience than you and less knowledge of the vernacular.
    These are just terms I like to use myself - or rather, translations of Finnish terms I like to use. Other people tend to use different (although similar) terms for the same concepts. Good of you to ask for clarification; this is exactly the sort of thing that we've talked about here at SG for years and years, so it's quite impossible to know who find which terms understandable.

    "Explorative playtesting" is when you're trying to figure out how something should work. It is generally only done in tabletop game design. The designer usually has a central role as a player in the game, while the co-players are there to act as a sounding board and development aid. This is a central practice particularly in traditional roleplaying game design, which often occurs as a continuous, iterative process where a GM becomes a designer in an effort to develop their campaign to greater heights.

    "Affirmative playtesting" is when you have something ostensibly finished, but you need to see how it plays out in practice so as to fix unforeseen complications and ensure that the game works under different circumstances (different players, mainly). It is not nearly as important for roleplaying games as it is for some other types of games due to the bootstrappable nature of the roleplaying game; players are expected to understand the game and execute it themselves, which reduces the usability demands on the product. Still, in practice all but the simplest games will require affirmative testing to truly understand the game in action.

    "Studio critique" is when you bring somebody into your artistic studio to critique your work. It contrasts with "media critique" or "review", which is something somebody conducts after you've published your product. In the context of games a studio critique generally means reviewing the design documents of the game (which in the case of rpgs may bear a great resemblance with a final product) without playtest. It is a very useful tool in that a critique is much quicker than a playtest, yet an experienced and knowledgeable commentator can nevertheless pinpoint many issues for you. Playtest and studio critique also synergize well: you may well wish for a good critic to take an in-depth look at your project by playtesting it, simply because they'll be able to provide a precise analysis of their own play experience and understanding of the project, which you'll be able to reflect against your own understanding.

    Don't waste playtester effort on meaningless feel-good feedback cycles; just get what you need, don't pretend to care about their opinions or experiences if that's not what you're after.
    Can you talk a little bit more about what you mean by this, give an example and how it would work and play out in a social context?
    Playtesting is a bit of a sacred cow in game design, because it's such a fundamental element of the development process. Sometimes inexperienced designers do it by rote, not really understanding what they're after. Part of that phenomenon is "courtesy playtesting" where the designer gathers very generic data and doesn't really do that much with it; they're playtesting because they're supposed to, but they're doing it in a meandering fashion because they don't know what they should be doing next in the development.

    A part of this phenomenon is that people sometimes conflate playtesting with generic studio critique, again simply because they expect this to be what playtesting is like: first you play the game, then you talk about it with the players, who tell you about what they think. When this kind of data is not needed (and that's pretty common - most of the time you don't really need to know what the nice people you play with think about things), the process becomes rote: you sit there listening to people analyze your game, but not because you need them to - you're trapped by the conventions of what you imagine playtesting to be.

    The maxim I suggest attempts to shake the designer out of this sort of dogmatic slumber. Think about what you really need from the playtesting process, and don't waste everybody's time on generic questionnaires about play experiences. Especially don't collect data you don't intend to use, that's just rude towards the playtesters you're asking to fill your forms.
  • edited November 2017
    Some things I learned over the years of releasing games, and that I also used after studied usability at the university.

    • If you playtest when your game is done or written, you're too late.
    • You will get your best feedback after your game is released, so release a beta first. Make them pay for it, because then the game has value to them.
    • I.e., the best playtesters are those who wants to playtest.
    • Only write after your playtested, not before. It's only the essential bits that you need to write.
    • Never explain, let the players read it. If they need to ask, ask what they think the text means. You need to rewrite the text the next time.
    • Play with different people, even if they don't know how to play.
    • Let others play the game for you with you as a player.
    • Keep playtests short, if you're playtesting it yourself.
    • Keep playtests focused, if you're playtesting yourself. Isolate different parts of your game as much as you can. In roleplaying games, this can mean that you write an adventure for each subsystem you got.
    • Hasimir is spot on. Only listen. Write down feedback rather than answering back.
    • Tell people that you got a game to playtest, and that you're doing it for someone else. If people think it's your game, then they wont be critical towards it.
    • Reassure people that it's a playtest and that there will be bugs.
    • Have the playtesters feel safe. If you get them to feel criticized or judged by you, then they wont be as eager to give you feedback.
    • Give positive reinforcement when the players critique or find bugs. It will improve your game.
    • Let the playtesters do wrong. Don't correct them.
    • Ask the players what kind of background they come from. It's then easier for you to understand where the critique comes from.
    • When getting feedback from proofreaders, always go with their suggestions.
    • All feedback is relevant. Even if the playtesters "got your game wrong", it's still good feedback for you because it tells you something about your target audience.
    • If you want to ask questions afterwards, don't have questions that can be answered with a simple "yes" or "no". Ask questions where they have to take a stand. "What would you say was the most confusing part?"
  • Great list, Rickard.
  • Here's one:

    If you need to test your game's reward cycle, and you only have a 2-hour slot to do so, do not start your game at the beginning!

    Don't make characters and scenarios, even if that's one of the coolest parts of your game. Don't play through the beginning of the story as the characters encounter the main situations and begin to engage with them.

    Instead, come to your playtest ready with pre-gen characters and a scripted scenario and the action already underway. "You're here because of X, Y, and Z; you've already decided that your best way forward is P; your main choices here are weighing Q vs R. Go!" You can cover the relevant rules right before, during, or after that.

    Now we're engaging with what you need to test 15 minutes into your time slot, rather than an hour and 15 minutes in. Now the playtesters have time to see the cycles of play in action, to see how one use of the mechanics leads into the next and how positioning changes over multiple iterations. Now they can begin to see how they'd play it for real, in a full-length session, pursuing their goals with adequate knowledge of how the system functions. Now you can get useful feedback!

    Of the four RPGs I playtested at Metatopia, I think three would have benefited immensely from some degree of starting in the middle.
  • Did anybody get a copy of the table tent cards at Metatopia this year? (Was this thread started specifically to help generate those?) One side had tips for players, the other side for designers. Obviously not every point on each side was appropriate for every game, but they had some nice tips that would likely reduce tension for newcomers on both sides.

    My own big takeaway for playtesting was that don't run a full session if you need more precise feedback. This calls back to the point made above about starting in the middle of a session, but I think it goes even further than issues of time crunch. Running a full session introduces expectations for things you maybe didn't mean to playtest. Running individual scenes or testing specific subsystems, totally disconnected from an overarching narrative, may be less satisfying, but it may help you more effectively get at the stuff you need to test. (I knew this from playtesting video games, but for some reason didn't really internalize it for playtesting RPGs until last weekend...)
  • @jasonT wins the prize! This was to help drive some initiatives by a group of us at Metatopia. Here's the results of what we made, a collection of feedback sheets and some table tents to help nudge towards a better conversational dynamic for people who wanted it.

    https://drive.google.com/open?id=0B3hSiwKq_vRqWHAyM1dfUHJkcTA

    Thanks all for giving your ideas! We talked over a bunch of them and they were interesting to read.
  • Thanks for sharing this James!
    We are starting a new meetup in the Seattle area called "RPG Workshop. I would like to use/adapt your file (if you don't mind) for our meetups.
    Very useful.
    Thanks,
    Davey
  • Thank you for bringing this.
Sign In or Register to comment.