Playtesting and Proofreading: Necessary Evils

Editor’s Note: This article first appeared in The Hazmo Horizons, Issue 1. I purposefully do not include a PDF in this document as Chuck and Chad make the Horizons issue available for free. Visit Hazardous Movement to get a download of this, and many other fine articles.

In all of ASL, there are no more thankless tasks than playtesting and proofreading. Scenario designers make their reputations based on their designs. Producers make their reputation based on the quality of their products. Behind each of these lies the countless masses who have playtested a scenario and/or proofread the product. So what goes into it and how do talented designers leverage these to transform good products into great ones? 

Playtesting

This process is just what it sounds like: playing the scenario and seeing how it works out. The first questions most designers want answered are: A) Is it fun? and B) What’s the replay value? After all, no one wants to play a boring scenario. Boring scenarios include those that have little to no replay value, since scenarios played once and put away aren’t very likely to join the pantheon of “classics”. 

Once you have answered these basic questions, scenario designers are looking to see how balanced the scenario is. They want each side to have a reasonable chance of winning. This goal is perhaps the most difficult one to meet. As playtesters, we have to bear in mind the extent to which luck influenced the outcome of our game. Did one side lose their only AT asset? How did that change the game? Did a SAN eliminate one side’s best leader? When providing feedback to the designer, you need to try an account for this variable. Beyond that, your feedback should be honest and focus on the issues. In addition, playtesters have to acknowledge that it is the designer who has the ultimate responsibility for the final product. 

One thing designers have a tough time accounting for is variation in skill levels. If, for example, one player is a very strong player while the other is much weaker, this imbalance needs to be accounted for in the playtest report. This consideration requires players to be very open and forthright about their skill level. All input is valuable, and lack of skill is not a reason to exclude someone’s input, but if the skilled player wins easily over the lesser skilled opponent, you must give some consideration in your feedback or changes to the scenario might end up being for the worse.

Tougher still is trying to balance a scenario across ALL skill levels. What is balanced when played between very skilled opponents might not be balanced when played by players with lesser skill. Very skilled players are well versed in the timing of an attack and how to get the most out of the Order of Battle. Players with less skill may struggle with some or all of these considerations. Designers–especially the best designers–will account for this disparity when receiving feedback. As a playtester, don’t feel slighted by this practice. Keep in mind that the final result is ultimately their product and not yours. 

Lastly, as a playtester, your job is to review the card. Does it make sense? Is the map oriented correctly? Are the setup instructions clear? Are the Victory Conditions clear? The bit of the preamble and aftermath do not affect game play but is good to read, nonetheless. For example,does either summary mention the involvement of an elite unit and, if so, are the elite units reflected in the OB? When confronted with inconsistencies, provide clear feedback to the designer. If you can, provide rule citations or Q&A, as appropriate.

Proofreading

The role of a proofreader is to ensure that the written materials are as clear as possible. Both scenario cards and module materials should be models of clarity. As a proofreader, your job is to remove any and all ambiguities you can find.

It is of almost equal importance that the proofreader knows the rules well enough to recognize when something isn’t covered by the rules or the designer is changing the rules as they exist in the ASLRBv2 to something else. Note that it is not the proofreader’s job to change these things. The designer may have a good reason for altering the rules in some way. Your job is to point out the inconsistency and raise the point with the designer to make sure that perception matches the intent. If it does, remember your other priority: removing ambiguity. Make certain you do so here. 

As you are reading the module materials–particularly for a larger module–you have to make sure they are internally consistent. Does a rule later in the material conflict with something earlier? Again, your job is to raise the concern with the designer, let him decide on his intent, and do your best to remove ambiguity. 

Hopefully, you develop a relationship with the producer over time such that you can ask hard questions. And make no mistake: you have to ask the hard questions. Is this SSR needed or can the rules as written get the same job done? Is the “juice worth the squeeze”? Ultimately, the decision belongs to the designer and your role then becomes one of cleaning up the rule passage and removing ambiguity from the module. ASL is a complex game. If we as proofreaders can provide a simplification by sticking to the rules as written, we should give designers that option and then abide by their choices. 

Perhaps the hardest part of proofreading is staying abreast of Q&A and errata. An understanding of these minutiae can impact game play and you need to make sure the designers are aware of relevant details. Some errata is in the rulebook, while other errata is on the counters themselves. Not everyone removes errata counters from their ASL kit and they can inadvertently end up in a designers scenario. As a proofreader, you need to be aware of these technicalities. 

The single greatest skill you possess as a proofreader is the ability to pose worthwhile, constructive questions. You should be asking questions of the designer constantly. Questions help the designer to think through the process and allow them to respond out loud, which in turn makes the scenario more coherent and consistent . Very few designs start out looking like the finished product. This axiom is especially true of big projects. Requiring the designer to explain various details allows the designer to recognize and correct potential mistakes and provide clarity where needed. 

In sum, I enjoy proofreading and playtesting for designers. Not only does providing my own critique allow me to participate in scenario development, but allows me to enhance my knowledge of the game. Proofreading keeps me in constant contact with Q&A. It helps me identify places where rules clarity could improve. I get to chat with top players and rules-whisperers from all over the world. In the end, that process makes me a better player and is therefore time well spent.