Harking back to some earlier thoughts about immersion, immediacy and other things, one thing I didn't cover in any detail is what makes rules playable. And for that matter, what defines 'playability' as a concept.
First off, let's look at what makes a rule mechanic playable - by a mechanic I mean the actual process by which one models an action/effect using dice. For an example, consider, the Warhammer family d6 to hit/wound/save in combat, or the Dreadballl throw/catch mechanic, or the Principles of War combat roll + table. There are two tradeoffs, essentially - first off how convincingly does it model the process, and second how easy is it to apply repeatedly during the course of a game?
 |
| from WWPD.net, used for review purposes |
Amusingly, it's possible to mess up both - Flames of War seems to do a brilliant job of having a pretty complex model which should, you'd think, have the potential to be at least fairly realistic…
The Holy Grail, though, seems to be to luck into or hit upon a fairly simple mechanic which models the process well - the current ones I really love are Op: Squad's interrupt system, the CoC patrol pre-game and Dreadball's throw/catch mechanic, all of which are childishly simple yet just plain work. This is why rules designers like Rich Clarke, Jake Thornton etc are precious and rare commodities, because while that sounds simple? it really isn't.
But even when you do that right, and some will argue, for example, that the Warhammer hit/wound/save mechanism is pretty close for the likes of WAB, it's still possible to mess it up. How?
Special cases.
Special case code is the bane of my life as a programmer: dealing with different means of applying postage in the UK and Germany, for example, makes me greyer and crazier every day.
It tends to rear its head in wargames with (but not exclusively) supplements - in order to distinguish force A from force B (and, as the cynics around here will no doubt be adding, sell more figures) there is the temptation to add a special rule for force B, or for one unit in force B. Note that this is subtly different from making elements of force B stronger or weaker using the stats that the games core mechanic is designed to work with: the distinction between (say) adding 1 to a DreadBall player's throwing skill and awarding them something like a Never Misses special rule which says they never miss a throw. You can do the former within the mechanic of the game. The latter is a special case.
"But that's fine," you say. "It's only one force." Except
- it never is, because once you've set the precedent you're doomed, and
- special case rules interact with each other
Let's suppose we have another DreadBall team whose Guards have exceptionally long arms, and give a minus to any throw passing within a hex. How does that interact with Never Miss? Which rule takes priority? Does 'any' throw include 'Never Miss' throws? It does say 'any' after all.
Sure, you can clarify that easy enough. But…
Let's move on a few years in the evolution of our game (and let's not call it DreadBall any more, because I'm sure you can think of at least two games I dislike that this next describes much better!). Your game's a major hit. Supplements galore, You have maybe a hundred special rules dotted through 10 books. Every special rule has the potential to interact with every other: there are 100 squared - 10,000 - possible interactions. Even if a percentage can't possibly interact, the number that can is proportional to the square of the number of special rules. In mathematics, it's an O(n2) problem (order n-squared). And the instant reaction of every programmer to an O(n2) problem is to want to make it go away very fast! But all you can do is desperately try and document every one, and outthink our enterprising player base.
Hello really annoying complexity. Good luck with that :D
O(n) problems are bad enough -- the more special cases you have to remember, well, the more you have to remember. Reference sheets only go so far.
ReplyDeleteI'm still working on Tin Soldier and I recently carved off a substantial chunk of rules that, while interesting, didn't pay off in gameplay the cost of complexity.
As a programmer, you soon learn that you spend 90% of effort on 10% of cases. But I agree - you don't want individual special cases as they add complexity to the game without adding to its playability, nor even to the play, if you take my meaning. My own approach to this sort of thing is to ask myself: does this proposed rule/ game mechanic/ system add anything substantive to the game. If not, it's gone.
ReplyDeleteI found Infinity went too far down that path. Really great core rules, D20 with the ARO system, over complicated by special rules
ReplyDelete