Game Design: When to Write a Rule

Are you designing a game and writing rules for stuff?  Here's a rule about when you should write a rule and stick it into your rulebook.

• Only write a rule when it is better than what you could come up with on the fly.

Better in this case can mean:

• More interesting.  By this, I mean mechanically (but it can be flavor-wise, too).  Green slime is a tricky thing to adjudicate.  I'm glad I spent some time brainstorming a good green slime mechanic and writing it down.  Now, when green slime happens to my players, I can refer to that mechanic, which generates interesting choices better than what I would probably come up with on the spot.
• More balanced.  Perfect balance is silly, but referring to a recorded rule reduces the chance of you making a sloppy ruling--one that easier than you would like, harder than you would like, or inappropriate (like a player is trying to turn a giant crank, and you call for a Dex check, realizing a minute later that a Strength check would have been more appropriate).
• More consistent.  If the party fights an ogre that is HD 2, and then later fights an ogre that is HD 6, they no longer no what to expect when they bump into a third ogre.  (Knowledge is an important resource, like lamp oil.  Make it count.) 
• Objectivity.  It helps keep DM bias from creeping in.  I'm not (only) talking about fudging dice, but the subtle psychological biases that you have little control over.

If it don't fulfill one of these needs (compared to what you could come up with on the spot), don't write it down.

by Alexandre Chaudret

This is why I have rules that assume a number exists (like an orc's Str or Dex, when trying to shove an orc) but don't actually give you that number.  Because that's something a DM should be able to adjudicate.

More accurately, I'm not going to write down the Str for an orc, because the number I come up with in the middle of the game isn't going to be any better than the Str I come up with now.  Both will be pulled from my ass.

Sure, some guidelines are nice.  Human = Str 10, Orc = Str 14, Ogre = Str 18, Giant = Str 24.  Now I don't have to include Strength stats in my monster manual.  But this is just a yardstick that DMs can use to generate Str scores on the fly.  It's me saying "You know those orcs you saw in the LotR movies?  Those dudes were Str 14."  It's not me saying "All the orcs in this game have Str 14."  It's a calibration standard that DMs can use to generate the Str score for orcs and alligators.  It's not a reference for orcs and alligators.

There's a trend in this hobby for completeness.  When a person writes an entry in their monster manual, there's a drive to include all the numbers that might possibly be relevant, partially because all of the other stat blocks used those numbers.

That's why you sometimes see entries like this.  "Talking tree. . . Move 0', Fly 0', Swim 0'".  That author has chosen completeness over usability.  

The same trend leads to setting books that include populations for every town, including percentile breakdowns by race.  "Shropshire, pop 370, 80% human, 17% half-orc, 2% dwarf, 1% halfling".  And that's awful.  It's boring and it gets in the way.  Leave it at "Shropshire, town."  If the 17% half-orcs are significant, mention that.

Never write anything down unless its better than what you could come up with on-the-fly.  The default should be rulings, not rules.

by Alexandre Chaudret

So here are some reason's why you shouldn't strive for completeness. (Why you should have more rulings and fewer rules.)

• More usable.  When you look up the stats for a talking tree, you aren't looking for it's flight speed.  The less irrelevant stuff you have written down, the faster you can find what you're looking for.
• Less wasted space.  Do you really need to write four paragraphs about what humans are like?  Do you really need to record the fact that eagles have Wis 15 and hawks have Wis 14?
• *Pathfinder is a famously over-complete game.  Not because it's crunchy (crunch is often good), but because there is so much data that must be handled by the program (the DM).
• It's not hard to imagine a bird bestiary being published, with hundreds of slightly-different stats for mundane birds.  You want your bestiary to be the opposite of that.
• More tailored.  In your game, orcs might be just green-skinned humans with bad PR, and so a Str of 10 might be appropriate.  In another game, orcs might be formed by demons raping gorillas, and so Str 14 might be more appropriate.  It gives the DM more leeway to make the stats fit closer to the concept.  
• Yes, DM's can always overwrite a number if they don't like it, but that's difficult when the stat block is already in front of you.
• Yes, this means that two different groups will be playing slightly different games.  But this is a feature, not a bug.  When one DM runs B2, it'll be slightly easier than another DM running B2 (because their orcs have different Strengths), but that's okay!  It never was the same game in the first place (there are so many differences besides orc Str scores) and trying to hard-code perfect balance into your game is a futile task.
• Fewer knock-on effects.  By introducing rulings as they are needed, you can assign a sane, logical procedure for settling them.  By hard-coding all of your rules into the game book, you are potentially creating situations that could conflict in strange ways, or create weird outcomes.  Have you heard of the peasant railgun?  Or pun-pun?
• These are problems in systems that are assumed to be complete.  With the peasant railgun, it is assumed that if there is no rule limiting how many times an item can be passed in a round, then there is no limit.  The assumption is only made if the system itself professes to be complete.  With pun-pun, that's just a bunch of small rules interacting in a way that was unforeseen by the designer.  Yes, these are very extreme examples, but smaller ones happen all the time.  

If you were programming, which variables would you want to hard-code into the program, and which variables would you want to generate at run-time?

So there's a koan of game design for you.  The best game is not the most complete game.