Take the 2-minute tour ×
Role-playing Games Stack Exchange is a question and answer site for gamemasters and players of tabletop, paper-and-pencil role-playing games. It's 100% free, no registration required.

I've been writing my own RPG, mainly to address some of the flaws / frustrations I've come across in other games. Luckily, I've found a few willing participants to help test the rules and mechanics in mini play tests, but this has lead to two problems:

  1. Some mechanics quickly appear broken - should I rewrite the rules on the fly (likely to not be that well thought out) or skip over the mechanic entirely, or "GM" override the result.

    An example of this situation was where both the PC's and NPC's couldn't hit / damage each other - the odds were far too remote.

  2. Not all the player actions have been anticipated, so how do I constrain the characters actions without, without stomping on their idea / enthusiasm.

    In this case, the combat system was similar to D&D / Pathfinder, but I hadn't limited the number of "attacks" of opportunity, so as a gang attacked the player wanted to keep reacting out of their normal round action.

Apologies for the questions being a little woolly, I just really like some general suggestion on how to deal with any rules that are obviously a work in progress?

Advice from anyone involved in any RPG, regardless of system would be very welcome. Does the same situation apply when people create add-on content for established RPG's like D&D?

share|improve this question
    
It sounds like you are trying to run a game just like you would with any other rpg. Is that the case? –  Leezard Nov 21 '12 at 23:29
    
At the moment, we're playing fairly short, limited scenarios to test the most recent additions to the rules. The trouble is, even in 'basic' sessions, players seem to do a very wide range of activities. I'd like to encourage that, but the rules don't stretch that far yet. –  Mikaveli Nov 21 '12 at 23:31
    
Are the players' expectations set for this being a "play test". I mean to say, are they expecting something more polished then what you have at the moment? –  Leezard Nov 21 '12 at 23:38
    
They know what to expect - but I'd still like it to be an enjoyable session for them, not just a grinding 'help figure out someone else's game mechanics' session. –  Mikaveli Nov 21 '12 at 23:41

5 Answers 5

up vote 9 down vote accepted

I've only play tested new systems a few times and never was I the game designer. I have used a great many house rules and those should be play tested before being made law. That's my caveat.

As a play tester, we were asked to take notes when problems came up. Sometimes we were asked what we would do to resolve the problem. In these cases the rules didn't change on the fly. We noted the result and a rule revision would later be worked out and slated for play testing later.

When I was play testing for and implementing house rules I would take a moment and stop the game and talk to the players a few minutes to get reactions and input. Then make the call and move on with the session. This process would be repeated until I felt the house rule was in order.

In so far as limiting the players' actions, I would shy away from that and try to come up with a "general rule of thumb" such as a base skill/stat check or a roll of luck to cover such actions in the moment. Afterward, you can sit down and think out the rules to cover stuff that came up in a more robust fashion.

There are also some guides and advice for play testing a new system:

Some Rules for Developing and Playtesting Tabletop RPGs

Playtesting RPGs (more about setting up a play test but the point about getting someone else to GM is worth including it)

share|improve this answer

Two ideas about playtesting:

Test the rules, not the fun

Remember the point of the playtest is to see if the rules work, not necessarily to have a fun game (I mean, yes, the end goal is fun, but you need the rules working to get there...).

So if you find the mechanics are broken, stop the game say, "Oh, that's broken, let's just say XYZ happens, and go to a scene where we can text these other mechanics." If those broken rules are going to come up a lot, you should probably stop the playtest, get feedback, redesign it, and playtest later.

Being open about the fact that you're doing this lets the playtesters know not to judge this thing as if this is the way the game is supposed to work - you can get feedback on the parts that are working, rather than everyone harping about the part you already know is busted.

Under Construction and Adaptability

If there's a full type of rules you don't have, let the players know up front. "I don't have any rules for magic, so we're not going to use magic in this game, ok?" If they run into something that isn't ready during play, say it. "Wow, I don't have anything ready to deal with this - I'll need to note to add something later". Sometimes those players will come up with a simple solution right then and there ("Oh, why don't you make it an XYZ type roll?" "Oh, why didn't I think of that? Yeah, let's do that").

When the rules are working like 80% good, then you can start worrying about how to tweak/alter them to hit the fun parts. A car has to roll before it can go fast, and rules need to simply work on the most basic levels before they can be fun. If you focus too much on trying to make it fun, right now, or making it seem like it's working when it's broken, you're not going to get good feedback or a real feel for the rules you're building.

share|improve this answer

Playtesting should be similar to software testing (or any "product" testing).

  1. Come up with the rules. Bang on it until you are reasonably sure you have the right idea.
  2. Alpha test. Give it to someone else/unleash on players. Write down anything that goes wrong. Since all the players know they are playtesting something, in the case of your combat where no one could hit, I would personally tweak (if possible) on the fly. Otherwise, I would simply say, "OK, this part needs work, let's skip ahead. By hook or by crook you guys killed/subdued/whatever the bad guys, what now?" If someone hits you with a blind-side idea, by all means be open about it. Tell them that you hadn't thought around that contingency. Assuming you don't have munchkin testers they will likely have an idea on how the system should work. Ask them for their input. Most importantly, write down every question, issue, problem, gripe, "holy COW that's cool!", etc. Between sessions/during breaks in the test session, address any issues that come up. I'd categorize the issues as "darn dice" (nothing you can do), "darn rules" (the system is either difficult to understand and needs clarification, or is going to be something grumbled about. See D&D/Pathfinder's rules on grappling), and "darn GM" (you missed a rule or two). In fact, I probably wouldn't even bother writing a traditional session here. I would come in with a few combats, maybe a roleplaying scene or two, a few non-combat skill scenes, and finally a scene that really focuses on the classes you are testing (only testing fighters, don't worry about the magic system; only wizards, who cares about the stabby-part of combat). I would even go so far as to say that the alpha test shouldn't be "fun" unless you like disjointed and scatter-brained stuff.
  3. Beta test. Here's the real test. Give the system to someone else and either get their feedback, or go to the session as a PLAYER. Work out with the new GM that you don't want him asking questions about the game system, sit back and jot down any rule questions that come up. Handle as already mentioned in the alpha test section. This should be the time when you stop really digging into how the players think the system should work and have a good idea yourself, even if you end up having to tweak certain rules. Continuing here, you should have a simple 1 session adventure here. Try to hit all of the points, but make sure that a long combat does not suck all of the fun out of the roleplaying scene before/after. Here I would have a simpler session that gives plenty of opportunities for both action and roleplay/combat avoidance. Don't go for anything deep and meaningful here, but a coherent plot would help most people to have fun here.
  4. Release Candidate. Give the system to someone else and hopefully you don't get any significant issues to address. In any game I develop, this would be the first version that is printed out and not on a word document (assuming a traditional print release method). Likely this someone else would either have a starting adventure like some games do, or would make up a full adventure on their own.
  5. To publish or not to publish?
  6. Profit?
share|improve this answer
1  
and yes, I realize I skipped the ??? stage before Profit. –  Pulsehead Jan 23 '13 at 17:27
    
Thanks, that's really helpful. I'm off to do stage 2 later this evening. :) –  Mikaveli Jan 23 '13 at 17:29

Some of the issues you mention could have been worked out without a playtest, like the odds of hitting: roll up some sample characters, then calculate what they'd have to roll to hit various targets, then look at what their target number to be hit is. Low-fidelity "combat" testing.

I was going to post that as a comment, but then it got me thinking. Maybe that's the real solution: run statistical analysis on as many things as you can before you even get playtesters involved, and then combine that with "ye can't get ye flask" when they go too far off the rails. Something like, "I'm testing the combat system here, so please don't try to parlay with the NPC, I need to know how combat works in a real situation."

share|improve this answer

My initial answer is to use a depth-first testing mechanic. In effect, take a given aspect as far as you can before you rollback and try something else. For me, creating the system is a modular deal. Sure, there's a core mechanic, but I test each new bit on its own, then against what I already have in effect.

As far as the player ideas you don't expect, you have the GM's Perogative on your side. When a player suggests something you haven't anticipated, that's wonderful. That means you say to them "let's try Method A this time and see how it works. I might change it depending on what happens".

My favorite stress test is the Min/Max test. If I can optimize something and it's broken and/or the deficiencies don't seem to come up then it's a problem and needs to be addressed.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.