Looking for play-testing tips and strategies

[Vordark]

I announced my project in First Thoughts with an eye toward cultivating that wonderful fruit, "general feedback".  I also had some questions concerning how to maximize the benefit of play-testing in my own sessions and it was suggested that on this latter point I might do better posting in this forum.  For reference, my system is here:

http://www.chaosphere.com/genesys/

Although I'm pretty sure my questions are generic enough to not be system-dependent.  What I'm looking for are your tips for making each play-testing session count.  We've got rules and we've got players.  How can we use these players to vet the rules of our systems in a way that:

1.  Maximizes our coverage.  In other words, makes it more likely that we'll hit every rule and/or many, many rules combinations.

2.  Does not conflict with the overall goal of making the game fun.  I think part of play-testing should be to test whether the basic function of a game is satisfied (is everyone having a good time).

I'm searching for any advice from the trenches, so to speak, or even thoughts along the lines of "One thing I've always wanted to try in my play-test sessions is..."

Any help would be much appreciated.

[Lance D. Allen]

When the goal is playtesting, take fun off the list of priorities.

If the game is fun, fun will happen. But that's not the motive at this point. Making sure it all does what it's supposed to is what's important.

When you sit down to playtest, think about what your specific goals are for that session. Make those goals explicit, up front, so that everyone is on the same page. If you want to test the subsystem that handles sentient yam wrangling, make sure everyone is on board with that.

Also make sure you schedule time for talking about what happened in the game. What went right, what went wrong, and why, for both. If the game isn't fun, but you get some good insightful feedback, then that was a successful session. If you had a rockin' time, but none of your goals were met, then you've failed. If you can manage both good feedback and fun, then awesome.

[Vordark]

When the goal is playtesting, take fun off the list of priorities.

If the game is fun, fun will happen. But that's not the motive at this point. Making sure it all does what it's supposed to is what's important.

When you sit down to playtest, think about what your specific goals are for that session. Make those goals explicit, up front, so that everyone is on the same page. If you want to test the subsystem that handles sentient yam wrangling, make sure everyone is on board with that.

Also make sure you schedule time for talking about what happened in the game. What went right, what went wrong, and why, for both. If the game isn't fun, but you get some good insightful feedback, then that was a successful session. If you had a rockin' time, but none of your goals were met, then you've failed. If you can manage both good feedback and fun, then awesome.

This is precisely the point I was wondering at:  whether others view play-testing as just another gaming session, only you are keeping your eyes open for where improvements might be made to the system; or your prioritize "Here are the rules we are going to test." and work through them without much regard to being entertaining as well.

From what you write above, it seems you are advocating the latter position.  If there's a way to sort of have my cake and eat it too (make the session both fun and productive) I'd like to find it, but this was pretty much where I thought I'd have to go.

Let me ask another question, then.  When you are choosing which rules or mechanics to test, how do you do so?  How do you prioritize?  Are there certain things you make absolutely sure to test earlier rather than later?

An example:  my personal thinking was that it was best to try to test the task-resolution system, outside of combat, before moving on to hard-core testing of the combat system.

I know I'm being idealistic to think that I could satisfy all of my playtesting requirements, for all of the various rules and plug-ins I'm building with some kind of set check list, but I'd really like to have a more structured way of testing the rules so that, at the end of the day, I can be satisfied that I ran through enough things that I didn't leave any glaring omissions.

Does this make sense?

[Michael Desing]

I've found that it's best to approach it in layers. If you try to work out several things at once (dropping the characters into a combat situation where they get to use a number of unique options), and it doesn't work, you can never be quite sure WHY it fell apart. If you are still working out the rudiments of the basic resolution mechanics, then it's tough to also play and have fun. If your players are willing to play test, they probably already understand that fun is going to be a secondary concern. I've found that if I start off by saying it may be a few hours of bouncing ideas, everyone is cool about it and is willing to help out. My problem now is that people ask "are we play testing tonight"? and I usually say, "uh, no... just playing!" They are so used to the rules being a work in progress (for the last five years or so) that they can't quite get the concept yet that we can play just for fun. For them, the fun has come out of the social interactions at the table, and the interspersed fun moment in game (which got more and more frequent the better the system got). I think that during play testing (especially early on), I was a lot more lenient with outside of game speak and tangents at the table. I knew that the guy playing the gnome illusionist had fifteen minutes of stuff to tell me, and if the others got off to talking about school or work or whatever, it was all cool. Eventually, we'd get back to the game.

Make sure that your players understand not to fall too in love with their characters, either. It's hard to tell someone who loves her arcane archer that you've changed the rules for arcane magic... and archery... and that the cool thing she could do last session is now balanced so she can no longer wipe out hordes of orks without having to roll any dice.

You definitely want to work out fundamentals first, and get those settled as you add more layers. For instance, in a fantasy game, make sure the basic fundamentals of the magic system work BEFORE you work out lists of hundreds of spells. You don't want to create a situation where you hesitate to fix something because of all the time you've already invested into a section... "gee, I know that the fundamental magic rules are broken, but I've written 30 pages of cool spells using that system, and darn it all, I'm keeping it!" That's never a good rationale for a design choice.

Good luck!

Mike

[Vordark]

You definitely want to work out fundamentals first, and get those settled as you add more layers. For instance, in a fantasy game, make sure the basic fundamentals of the magic system work BEFORE you work out lists of hundreds of spells. You don't want to create a situation where you hesitate to fix something because of all the time you've already invested into a section... "gee, I know that the fundamental magic rules are broken, but I've written 30 pages of cool spells using that system, and darn it all, I'm keeping it!" That's never a good rationale for a design choice.

Thanks for your reply!  It definitely highlights some things I need to go over with the players (I have one player in particular that gets attached to his characters easily), though the above quote I think is a damn good piece of advice.  In general, I've been able to throw things away that were broken without too much internal grumbling, but I do have a fair amount of the rules written already.  It hasn't been a brick wall against progress, but I have found myself hesitate before changing something because of having to either re-tool or completely throw away other systems that are dependent on what I want to change.

I think I need to make sure that "changing this rule will mean changing a lot of other things" isn't part of the decision-making process as to whether or not to throw out a broken mechanic.

[Lance D. Allen]

Michael has posted most of what I'd have answered, and probably said it better in the bargain.

To add a little something: Once the fundamentals work reliably, and produce the effects you're looking for, choose the features that have had the least contact during the foundational play, the ones that seem questionable to you, or the ones that you think are really cool features of the system. The first, because it's the least tested thus far, the second for obvious reasons, and the third because if you think it's really a cool feature, then it definitely needs to work right so that other people will think it's cool too.

To double-highlight something he said as well: DON'T be attached to your mechanics. If it doesn't work, it doesn't work; Change it. If it almost works, you can fiddle around with options to make it work, but if it simply doesn't work no matter what you try, you may want to try something else entirely.

Once you're pretty sure the game works as intended when you run it, then try to get one of your friends to run it. That will reveal whole new areas to improve upon.

[Vordark]

To double-highlight something he said as well: DON'T be attached to your mechanics. If it doesn't work, it doesn't work; Change it. If it almost works, you can fiddle around with options to make it work, but if it simply doesn't work no matter what you try, you may want to try something else entirely.

I'm actually in the process of tossing a couple of fairly big ideas out the window.  Namely skill complexity and the Trades system for Genesys.  These edits are...significant.  Initially these things seemed to work well, but it's clear to me that, no matter how "neat" they may be, they are just not going to work the way I want them to.