L2Playtest

So the hot topic in NERO in Ohio these days is the extensive use of Playtests by WAR. In addition, they brought Nature Magic back from the grave. For those of you interested, you can find all of WAR's policies and playtests here.

While there has been some proper discourse on the subject of these playtests, I must say I am somewhat alarmed at the number of people, on both sides, that do not understand the concept of a playtest. Hell, I don't think that word even means what they think it means.

The most common, and most successful, model for game design is called Iterative Design.

Iterative design consists of a cycle of several steps. The first step is designing the product. Minds come up with what they can from a cloud of ideas to put a basic structure and goals together. The second step is prototyping. This is where you take the cloud of ideas that you prefer, and turn it into an actual product that can be used. This usually thins out vague concepts and forces designers to make hard choices. The third step in the design cycle is playtesting (or beta testing). This is where you give the user the product, see how it actual works compared to theoretical models, and get user feedback. The fourth step... well the fourth step is back to design, silly!

Most (good) designs uses this model. It just so happens that products with limited application (tools, parts, etc) often stall out at a point where the playtesting reveals no new information. However, it turns out that extremely complicated products (software) and games both exhibit an essentially infinite cycle. For software, the high complexity and internal referencing in the programming means that when you fix a bug, it will probably create another one. In some gaming, the application space is so large (whatever a player can think of within the rules) that there will inevitably be a lack of balance or holes that cause problems within the game. The tighter the ruleset (chess, go, checkers), the less playtesting is required. The more open the system (Tabletop and LARP systems), the more playtesting is required.

In summary, a playtest is intended to obtain feedback on a design prototype, and the results of that feedback will be fed into the next level of the design. So the WAR "Playtests" are actually prototypes. The process of testing them is the playtest.

Now you know what a playtest is and why it exists. Now I'll show you an example of doing it wrong.

Playtester - "So your prototype sucks. It sounds dumb. You're dumb."
Designer - "Your mom's dumb."

This is an example of poor feedback. If the playtester does not give reasons for their qualms and rely on subjective reasons ("This doesn't feel right."), they are not doing their job. This offers no real value to the designer.

Sometimes I'll hear this exchange as well. Once again, this is a sign of poor playtesting.

Playtester - "It appears that using X/y/z together creates a rather unbalanced situation. How do you plan to deal with that?"
Designer - "We expect our players to know not to do that."

In this example, the designer forgot the goal of the playtest is to make the game better. Playtesters are expected to try and break the system. Ignoring valuable feedback keeps the playtest from doing it's job. A prototype that ignores feedback is a (poorly) finished design.

So here's an example of a proper exchange regarding a playtest.

Playtester - "I know I haven't had a chance to test it yet, but it certainly seems like base 10 celestial damage is going to be a little bit excessive. I'm somewhat concerned about how powerful it will be when used by NPCs, especially against lower level players. Please test this."
Designer - "We will try and do some realistic testing in those situations to see if it's really as bad as it sounds. I appreciate the feedback."

And another...

Playtester - "It appears that using x/y/z together creates a rather unbalanced situation. How do you plan to deal with that."
Designer - "Well, from our feedback it appears that y is a bit too powerful, and z simply isn't going to make the cut. While the combo of x and nerfed y is still pretty powerful, we feel it is more in line with the other options a player would have."

So, as we can see, it's a playtester's job to find actual problems (or apparent problems) and voice their concerns. It's a designer's job to take actual player feedback and, you know, design around it. Playtesters voicing concerns to others and not to the designer is a bad idea. Designers ignoring honest feedback in regards to your prototypes during the playtest is a bad idea.

So let me ask this.

WAR (or OOC) Players using playtested skills - Have you given any feedback to the WAR Ownership regarding those playtest and how they function, whether written or verbal?
Out-Of-Chapter Players - Have you given any feedback to the WAR Ownership (or someone to take to the ownership) regarding the playtests and how you would expect them to function, whether written or verbal?
WAR Ownership - Have you honestly read, analyzed, and made decisions regarding how the new rules fit into the game, and whether any of them need to be dropped/modified?

If you answered 'No' to the above questions, then you have two options.

1. Either give feedback to the ownership (or someone to take to the ownership) or take a minute to read the honest feedback.
-or-
2. Shut the hell up.