How to start play testing?
Eric Pruitt:
Hello Everyone!
If you don't want to read the wall of text, here is the TL;DR version When and how do I start play testing?
This is my first post, I've been a lurker for a long time, but just now had a reason to start a topic. I expect my post count to stay low because I don't often reply to threads when someone else has already expressed my views.
I'm sure this has been asked before, but for some reason the search function will not work for me, so a link to an appropriate thread would be great if you don't feel like re posting information.
I'll include a link to a google doc at the end of my post. It is just an outline and a general setting idea. Basically I'm attempting to recreate cyberpunk/shadowrun to fit the needs of my group. I'm not including more of my rules for a few reason. First they are in a ton of different documents (roughly chapters) to help me stay organized. Also, I don't think this question is rules specific, but I may be wrong there. If that is the case then I'll post more rules as required.
My question is this: When in the design process should I start play testing, and how do I start play testing? I'm getting a decent amount of rules down on paper, but I don't feel like I should keep writing if they aren't going to work. Also, how do I do the play testing? Do I give my players the rules for whatever we are about to test and see if they understand it, or do I tell them how it is supposed to work and go from there?
I hope this makes sense, and thanks for any help you can provide.
https://docs.google.com/document/d/1JEMundqQVas5UqWAIF4mqbIrVmKms1I-fXqRvyoA57E/edit
Christoph Boeckle:
Hello there, and welcome to the Forge! Any real name we can call you by?
Ben Lehman (author of Polaris and Bliss Stage among others) posted his views on playtesting, which generated a bit of controversy, but as far as I'm concerned, I think his ideas make a lot of sense.
I think it's a good idea to have a solid rules-set laid out before finding a group for testing: you don't want to annoy people with wrecked rules, else they'll drop out on further testing. As Ben says, playtesting should be about seeing if the rules are fun, not if they are fail-safe nor if the probabilities are right.
First thing, try formulating clearly what the big picture goals of your game are on the one hand, and what people do moment by moment on the other hand (you don't necessarily need to get very technical yet, though you will later eventually). Be sure that these things work together! See this article by Vincent Baker for more detail. Somewhere in this process, you ought to be very clear what is supposed to draw people into playing (in terms of cool "colour" and what they can get out of the game, see what Ron Edwards said here in a very succinct manner, you can search for more detailed and applied discussions searching for the terms Color and Reward).
Once you get the basics down, you may then try to draw a map of how the rules components interact (be sure to count specific things prepared by the GM and particularly important kinds of "free play" on that map, since that definitely factors in on how the game is played.) For an example of this, you might want to check out what Steve Hickey did for Poison'd. This map highlights what features of the rules make play turn in virtuous circles, and more importantly how. If you see that some element of your rules gets isolated, be sure to address this according to the initial questions of how the scales work together, and what your game is about in the first place.
Finally, try playing some situations out in your head and see if you get stuck at some point.
I hope I'm not scaring you off with this abstract outline and link-dumping. I hope it gives you some ideas. Feel free to ask questions or come in with concrete examples taken from your game.
If for some reason you can't search the forums, try google with "site:http://www.indie-rpgs.com/forge/" in the keywords. Maybe you need a minimum number of posts before accessing the search features. The private messages and the signature at least are blocked until you have three messages.
Kyle Van Pelt:
Hey there.
Christoph put out a lot of good points, and those links will help you. My only recommendation at this stage is to have your play group view the rules and make suggestions, with the understanding that not only are the rules incomplete, but are open to mutation. Make sure you state that clearly, as well as what goals you have in mind for the brainstorm, since that's what's happening. It's not going to be a pure playtest when the rules aren't solid and laid out, so call it a development session or what have you. Try to get them involved in the process so that they understand what you're trying to accomplish, then bounce ideas off of them and see what sticks.
I know that working in a vacuum is trying, since during the stages of game development you not only need ideas, but encouragement and meaningful feedback. If you're doing this for your group, why not involve them in it? At the very least, you'll get a good idea of what they want out of the game, which will help you design it.
I don't know if this is an answer you wanted, but I hope it helps.
David Berg:
I think it's hard to suggest an approach without knowing what your options are. Do you have playtesters, or a plan for finding some? If you have some, are they willing to try whatever you ask of them, or do they demand that they actually get to play a fun game?
If you like audio, here's a podcast about playtesting, where I ramble about various things I've seen and done, while John provides some concrete tips from his Usability Testing background. My overall take is that some form of contact between your game and other people can help in some way at any stage of your design, as long as you know what you're looking for in that stage.
One specific thing that jumps out at me from your G-Doc is that you list 4 different types of resolution (Skill, Combat, Social, Hacking). I'd suggest that, before you take these to a group, you think through what each player at the table will be doing when each of these is invoked. If Hacking is a solo mechanic that takes a while for one player, you may want to test it with a single person, rather than inviting a whole group and then having them wait around during Hacking.
Eric Pruitt:
Thanks for all the suggestions. I really appreciate it. Sorry it has been a week since my last post. RL gets in the way of all the fun stuff. Oh and my real name is Eric so feel free to call me by that. :-D
I'm going to start going through all the links that Cristoph provided, and I'll listen to that podcast while I'm doing that. Don't worry Cristoph, you didn't scare me away. I think that doing some of these abstract exercises will probably help me focus everything.
To answer David's question about play testers since I'm really just trying to make a game that makes my group happy they will be my play testers. They are willing to do whatever I ask them too, and my wife is very excited about the project so it is easy to do some one-on-one testing with her.
Once I go through all the links and listen to the podcast I'll post again with any questions I have.
Thanks again!
-Eric
Navigation
[0] Message Index
[#] Next page