This post is not about the Fudge RPG, but since play testing should be a common part of designing a Fudge game or supplement I felt that it was appropriate for this blog. Recently I was invited to play test a module written by one of my friends who plans on selling the work to a publisher. I will not mention names, but this friend has had his materials published in the past and I have no doubt that this module will be published as well. I happily agreed to take part in the play testing and I have greatly enjoyed the game so far.
Yet during the last session I was frustrated and bored. The module is written for Dungeons & Dragons 4th Edition, and the problem with D&D 4e is that combat takes way too long. Plus you need to take extended rests in the game in order to have access to your most powerful abilities during play. I felt that the last session had a pacing problem, and because there was not a good opportunity to take an extended rest my PC only had access to the basic powers of the character during the last encounter of the session.
I made this clear to my friend, because as a play tester I believe it is my job to let him know exactly how I felt about that game session. My friend responded in the best possible way: he listened. He did not defend the module, nor did he attempt to explain how the situation might have been different. He just soaked up my complaints and asked questions in order to understand those complaints even better.
Because my friend listened and asked relevant questions about why I did not enjoy the session I am confident that he is going to produce a great module. His willingness to take criticism and to try and understand why I criticized the module is exemplary of good game design.
It also got me thinking more about what I as a play tester need to do in order to make this module the best that it can be. Here is what I have decided should be the top three goals of a play tester:
- Break it. When you are play testing a system, a module, a new rule, or any game component you should be looking for ways to exploit the material and turn the entire work into a smoldering wreck. This is not done as an act of malice, but for the purpose of quality control. The designer needs to find those weak spots before the product is published, and if you do not attempt to break the product when you see the potential to do so you are not doing your job as a play tester.
- Complain about it. You will probably be friends with the designer. You probably do not want to upset your friend by complaining about their work while it is still in production. You need to complain though, and you need to be blunt with your complaints. Do not try to be diplomatic, and never attempt to soften the blow. The only taboo is to be insulting, but the rest is fair game when complaining.
- Praise it. This is the easiest part of the play tester’s job to overlook. You need to get every single complaint out in the open, but you also need to mention every single part of the product that you like. You should be just as generous with your praise as you are with your complaints. Why? Because a good designer will sacrifice something that you like in order to fix something that you complained about if the designer does not know what you like! Every complaint you make threatens an element of the product that you like. Nullify that threat with praise.
Those are my goals as a play tester, and those are the things I expect of my play testers as a designer. What do you think a play tester’s goals should be? How do you handle play testing of your designs?
Bonus question: do you want to see more posts that might not be directly related to Fudge on this blog? I want to keep the blog Fudge centric, but I feel that I’ll attract a bigger audience if I tackle some common issues with all RPGs as well while still serving the Fudge community as a whole.
3 Comments
Direct questions work well, but it takes a certain… idunno, dickishness to offer really helpful negative input. That, or an objective record such as a recording of the AP of a testing session. The ostensible point was for me to clarify how I was explaining FAST as drafted, but also I was looking for cases of excessive GM fiat, unfairness in refereeing, de-awesoming the system. And lo, those were all found in spades as well…
As I listened to M—’s points of how he wasn’t able to create the character he wanted, I could see how what I was doing was really all about my personal design agendas rather than creating a system that fulfilled it’s goals on it’s own. Setting that agenda aside, I now have 6 different system ideas to play with and develop as I find time. If I’d just used what he’d said at the time, I’d have simply killed Buffs and been done. The meat of the comments I found useful came from in-play and some casual bits during a quick pee & soda break. (BTW – buy him a tasty beverage for me next time you see him, si vous plais)
The process wasn’t that invasive – I set out the recorder and asked everyone’s permission for my intended use and hit start. I don’t believe anyone really gave it a second glance after that.
As to goals, I really believe it depends on the stage of development. With the last bit I did with you at UGG, I was looking for input on how to present the chargen system, how the variable dice work, Buffs etc. – I needed to make sure that my ideas were clear enough for others to understand. If I were to break d100 out for testing at this point, I’d be looking at speed of implementation and resolution and integration of the math section of the system. I’d examine the time between the sounds of dice and the narration of outcomes as well as the looks one everyone’s faces as they figure out HxW. If it were a module, I’d be looking at how well it achieved it’s purposes in narrative v. how much fun the players had/how much shaft-u-lation was inflicted.
When I’m testing for someone as a player, I’ll ask what the ref’s goals are. If she needs breakage, I’ll break her as best I can. Support? I can do that as well. Casual testing to see if the small things fall apart? Often much more useful than nerfing the system with the goal of breaking it through over-powering it. And sometimes, I’ll offer happily accidental takes on the rules as written that better serve the spirit of the rules as intended… but that’s another story.
Fudge-centric: I’m more interested in the development end than any affection for a particular system. However, you did make a commitment to the cult of #4dF for 2010…
When you mention play-testers, you should really also talking who they are play-testing for. If the play-tester feels uncomfortable giving their criticisms because of the way the designer responds, then the whole thing can be lost.
I think it’s also important to *state* in advance what you are trying to test or understand from the session. This way the play-testers have guidelines for what they be looking at one.
The first time I took Lost Heroes out to play test with friends, one of my friends decided to do his best to break it. You’re rule number 1. The problem was, I wanted to take it out for a test drive, see how things flow. If it didn’t work, then I thought that would be fine, I could patch it on the fly for the players. They were friends and it’d be fun. However this one player purposely breaking it only end up creating a frustrating experience for all involved. And the way he broke it was IMHO against the spirit of the system anyway (like complaining Fudge isn’t like DnD) and so was mostly useless (and also end up leaving a bad taste in everyone else’s mouth).
As for rule 2, yes complain, but do it at the right time. Doing it every five minutes during play will ruin the whole session. It’s up to the play tester when to do this of course and sometimes it’s better to make notes and tell the GM at the end and sometimes during play (so that other players can chime in). The same sort of applies to rule 3 too. The GM needs to know what worked and what didn’t.
I wonder perhaps if there is a more practical approach to managing this sort of stuff? Tell or give the play-testers a guide to what is being tested this session. Gather as much info about the session as possible (such as recordings). Give some breathing room during and after the session to get a subjective feel of how the players are enjoying it and then give the players a chance to provide actual feedback in person and possible via a questionaire/survey as well.
I understand the points being made, but I believe that some issues are being confused here.
Recording a play test session is great, but the recording does you no good unless you have vocal and interactive play testers. A video recording might be more effective than an audio recording, but it is also more distracting. You need good play testers.
As for play testers who are trying to derail your game (I do not consider that the same as breaking the product) or who complain at inappropriate times, well that is more of a social issue. Gamers are labeled with a certain stereotype for a reason. A lot of us are rude, and rude people make bad play testers. Again, you need good play testers.
Obviously this begs the question “Who is a good play tester?” For me the answer is someone who is going to pursue these three goals for the purpose of improving the product. Someone who is trying to derail the game is not trying to improve the product, but someone who devises a way to kill the big bad evil guy during the first scene and does so knowing that it will gut the rest of the session and does so any way is actually improving the product. They found a flaw in the product and exploited it. The designer can now revise the product as needed.
A good play tester also understands that their enjoyment is not a goal of play testing. Good play testers understand that there will be retcons in the game, and that the same problem might need multiple sessions of play testing to resolve. If the play testing is fun that is great, but that just means that the product is nearly ready to be released.
@Keith – The UG&G game was fun, but I played it with these three goals in mind. I broke it (from the beginning I saw how an Adept could unbalance the game), I complained about it (you got my feedback on what was wrong once the game session had ended), and I praised it (I told you what I liked about the game and why). I think that because I was deliberately pursuing those goals you were better able to spot the flaws in the design. The session was fun for me, but I was serious about my play testing and I hope it helped you improve upon the product.