When Devs Break Their Own Rules

“Sorry about the mess.”
— Han Solo

It’s been a while since we’ve delved into any of the broad concepts surrounding rules interpretation.  And, honestly, this is one that I would rather not have covered at all, or at least not needed to cover.  But with several elements of the recent FAQ rather directly contradicting the rest of the rules set, it’s a subject that’s worth broaching.

The Example
Even though I think there are at least three examples of this in the current FAQ rulings, I’d like to focus on what I hope will be the least controversial one.

Proximity Mine: When a ship executes a maneuver, if its base or maneuver template overlaps this token, the token detonates.
Q: If a ship barrel rolls or boosts onto a proximity mine token, does the token detonate?

A: Yes

I think the problem with the ruling here is pretty obvious.  Boost and Barrel Roll are not maneuvers; they do not trigger effects which depend on maneuvers.  But in this case, they do.  The ruling pretty directly contradicts the rules and card text as printed.

How To Play It
Let’s get the important thing out of the way first: this is the right way to play it.  Whether we like it or not, whether it follows the rules or not, the FAQ tells us how to play this particular interaction.  It is a binding rules document, and I expect that no TO in the world would find you very persuasive if you tried to argue that it should be played otherwise.  If you want to argue it, it’s always your prerogative – but don’t credit me when you do 😛

Rise of the Problems: Precedent and Interpretation
So if I say to just play it as printed, why does it matter if it’s right or wrong?  We know what to do when a ship lands on top of a proximity mine token after a boost.  What’s the big deal?

The problem with this sort of “Because I said so” ruling comes into play when we try to extrapolate it to other parts of the rule set.  The question of what to do may be obvious, but the question of why we do it remains unresolved (if it has an answer at all).  We know this ruling doesn’t match with the printed rules and our understanding of them, but we don’t know where the difference emerges.  That opens the door to all sorts of problems.  Different people will identify different causes, and take different steps to try and reconcile those issues.  Some players will attempt to exploit the ruling as precedent for advantage in unrelated cases.  Others will bend the rules into pretzels to try and make the ruling make sense, then apply that pretzel to other parts of the rules.

In short, the bad ruling erodes the foundation of our understanding of the rules.  Depending on the rules in question and their ability to be used as precedent this may have more or less impact, but it will always be there.

This is especially bad in a game like X-wing, where so much of our understanding of the rules is derived or implicit.  We don’t have strong definitions of timing, or the difference between “when” and “after” or what “Immediately” actually does when it’s used on the card.  Most of our understanding of these abilities are derived based on abilities.  Strange rulings can dramatically shake our understanding of the entire rule set.

Dealing With It: The Player View
So how do we, as players, deal with it?  I think there are two parts to it.  First, we have to recognize a bad ruling when we see one. That’s why I picked the proximity mine ruling, since it’s easily the most obviously wrong one in the FAQ.  Second, and more importantly, we have to be cautious in allowing odd rulings to propagate into our understanding of the larger rule system.  Does the proximity mine ruling mean that any ability that triggers on “after executing a maneuver” will trigger after a boost?  Does it mean that barrel roll is now considered a maneuver?  While I’m sure some might go down that road, I think that’s a mistake.

We, as players, have to be capable of recognizing these sorts of rulings and putting them in their own little box, walled off from our understanding of the game system.  Play the proximity mine like the ruling says, but that’s it.

Dealing With It: The Developer View
As a message to developers, the only plea is to please not do this.  If a particular interaction isn’t working the way you intended to, then make appropriate errata; don’t just drop a ruling that conflicts with our understanding of the rules.  “If a ship’s maneuver template overlaps this token, or a ship overlaps it at the end of its Perform Action step, the token detonates” would be perfectly reasonable errata that accomplishes what seems to be the intended goal, and does so without leaving the many questions about the players’ understanding of the rules.

When I started this blog series, I did it on the “Teach a man to fish” theory.  Sure, we could keep telling people over and over that they don’t lose a Stealth Device when they overlap an obstacle, or that Elusiveness goes before Han, but we’re all better off if players understand the why of things.  Tell a man that Elusiveness goes first and he’ll be back with a question about Sensor Jammer; teach him about attacker/defender order during the Modify Attacker Dice step, and you feed him for…  well, it’s not as elegant as the fish parable, but you get the idea.

Developers should strive for the same thing when they’re creating rules.  We play complex games and it’s not always going to be perfect, but “Because I said so” rulings that contradict rules in obvious places will only increase the number of “I guess FFG has to answer this one” questions.

Sadly, few developers seem to share that view of the rules they make, and FFG certainly isn’t turning out to be one of them.  So in the mean time, it’s up to us as players to recognize the out-of-bounds rulings when we get them, and make sure that we aren’t breaking our fishing poles in the process of trying to understand them.