Chief Technical Officer
|
The first one had actually been fixed a while ago, before the current PDF edition of the rulebook, but it didn't get a FAQ because it's cosmetic. I just FAQd the second one.
Great finds Malcolm! I agree that it's important to get play-by-play examples correct for new, first-time customers. It also saves on support costs for company staff having to answer questions in forums and create, edit, and post revised PDF files.
I think you've also illustrated that since the game is built around "exceptions to the general rule", it's important to review every card and character sheet when writing the play-by-play examples, or at the very least, error checking by stepping through the completed example with every card to see if it still works as written.
There is the small possibility that the cards and character sheets were altered between the time the play-by-play example was written vs. submitting final versions of the cards to the printer. Of course, the counter-argument from the customer perspective is that this is the fourth release in the Adventure Card game line, so the play-by-play examples should be written correctly for a well-understood game system - it's a little harder to expect this level of performance with specific card & rule terminology because of cut-n-paste errors from outdated files, different thoughts about what specific phrases mean to each customer, and the individual differences between each designer (Mike phrases the concept this way, but Liz phrases it that way....)
Here's another oddity: each of the four rulebooks mentions "entering" or "leaving" a location under the Move step description. I don't recall any powers on locations or other cards that use those two terms; they only refer to moving to or from a location.
See my other post on the subject (Crypt of Air/Sandstorm).
I think that for consistency with the wording of the powers on the different cards "entering" or "leaving" should be replaced by "moving to" and "moving from" respectively and IMHO that the following rule clarified in the rulebook:
... Moving then triggers any effects that happen when you enter or leave a location. When you choose to move, you must always select a new location, although it is possible for some effects to move you to the same location you came from. If you do not change locations, your character is not considered to have entered or left a location. Some effects may cause you to move whether you want to or not, and other effects may restrict you from moving. If an effect would move you while another effect restricts you from moving, do not move.
... Moving then triggers any effects that happen when you move from your previous location, and then triggers any effects that happen when you move to your new location. When you choose to move, you must always select a new location, although it is possible for some effects to move you to the same location you came from. If you do not change location, you are still considered to have moved but you do not trigger any effects that happen when you move from or to your location. Some effects may cause you to move whether you want to or not, and other effects may restrict you from moving. If an effect would move you while another effect restricts you from moving, do not move and in this case you are not considered to have moved.
|
Chief Technical Officer
|
There is the small possibility that the cards and character sheets were altered between the time the play-by-play example was written vs. submitting final versions of the cards to the printer.
I can assure you that the possibility is not small—it's 100%. (I'm not saying that that necessarily caused any of the specific issues mentioned in this thread, but it did cause this one...)
Ugh. I thought as much.
It sounds like the play-by-play examples could be a real maintenance headache for the rulebook. With a living document used across sets, you want to touch established sections as little as possible.
Malcolm Reynolds was spot-on with the observation that familiarity blinds you to some problems.
The Quality Assurance suggestions I can immediately think of is adding a "review play-by-play example" to the final proofreading checklist, and perhaps, tracking the cards and characters referenced in the rulebook examples so a review is triggered when those cards are altered. For example, in a bug tracking database you might have a boolean for "rulebook example". When it's set to true, the bug resolver has indicate in the notes whether a rulebook update is required as part of the solution - if the example needs updating, then a new bug should be opened up against the writer/editor responsible for the rulebook.
Of course, these suggestions all depend upon how important it is to avoid these kinds of problems in the grand scheme of things. The errors potential impact might be too low to make the extra work worthwhile.
Ugh... Another suggestion might be "locking down" the layout by including a picture of the card referenced in the example. That way, you wouldn't have to care about which cards are in which sets. You would only have to edit the rulebook once because most of the examples would just work at that point.
Again though, this depends on how important it is to avoid errors and proofreading & writing investments for each box set.
|
Chief Technical Officer
|
Ugh... Another suggestion might be "locking down" the layout by including a picture of the card referenced in the example. That way, you wouldn't have to care about which cards are in which sets.
We always want the main Example of Play to demonstrate whatever new twists are appropriate to that AP when we can, so we really can't lock it down.