Art of DMing: Hacking Systems

I am intrigued and excited by the movement to hack (aka house rule, mod, reconfig) RPGs that's taking off. Done with respect and support." - @boymonster (Cam Banks)
I found the above quote in my twitter feed yesterday during a discussion of the popularity of Vincent Baker's Apocalypse World as a platform for game-hacking.  It almost didn't make sense to me: the entire hobby is based on a hack of a wargame, for Pete's sake.  Many - maybe most - of the games since then have been hacks of D&D or reactions to it in some way.  So in some ways the "movement" started thirty-six years ago. and is almost synonymous with the hobby.

"A game that isn't being hacked isn't being played."

We all hack the rules every time the books hit the table - no game can cover everything in infinite detail, so there's always going to be some room for interpretation.  But let's talk about deliberate hacks, when you decide to fire up the sawzall and welding torch and really get down to work.

Part of making a good hack is a thorough understanding of where you are coming from.  You're building on a foundation that already exists, so you need to know where it can support what you're trying to do with it.  Or maybe you're trying to solve a problem that doesn't exist.  I can't count the number of forum threads I've seen where someone excitedly "solves" the problem of probabilities in Savage Worlds while ignoring the fact that they're bogging down and complicating the game system in order to "fix" a problem that occurs in a tiny handful of very specific cases.

So, my first rule of hacking is this: Play it Straight, First.  Forget about the hack for a session or two and see how the game runs as it's presented.  And I seriously mean forget about it: don't spend the time thinking or taking notes on how your hack would work with this game or you'll never see what's actually there.  Go without preconceptions.  Make sure you understand the rules as they're written.  Sometimes you'll find out your hack isn't needed, sometimes you'll find out the way you wanted to handle it wouldn't work well, sometimes you'll find something else that turns out to be a better idea.

After you've gotten a feel for how the system works on its own, in play, that's when you should start seriously thinking about your hack.  The rules for making a good hack, anything from a minor house rule to a complete setting overhaul, are a lot like the rules for making a good game. Here they are (stolen and repurposed from Mr. Sorenson):

1. What is your hack about? What are you trying to accomplish?  Do you have a clear goal in mind? (You'd be amazed how many hackers don't.)  You should consider, if you can forgive the corporate speak for a moment, a "mission statement" for your hack, to keep you on track.
2. What in your hack makes it about that? "Grittiness" and "realism" are favorite subjects for hacks, but do the changes you're proposing actually make the game any more realistic or gritty?  Another common hack is grafting the setting of one game onto the system of another, but often hackers will try to emulate the system of the original game.  If drain codes show up in your GURPS Shadowrun hack, you've moved past emulating the setting ("magic tires you out") and into modeling the system.
3. What behaviors are rewarded? The focus of this question is a little different then when you're using it to play games but it's still a great one to ask.  Are you sure the hack you're making will lead to the results you want when you introduce it to the players?  You may want a detailed and realistic system for gun combat, wound trauma and hydrostatic shock, but if you pulled out a giant binder of house rules my first thought would be: "I am going to devote all of my character's energy to preventing a gun from ever being fired because I never want to have to wade through that."  Presumably, that's not what you wanted when you designed the system.

The next thing to do is test and be merciless.  Play your hack.  Compare it with playing it straight.  Afterwards, think about those questions and decide if you're going to change your answers.  Maybe you find out that it rewards the players for doing something different than you thought it would - does that fit in with your goal?  Is there a better way to handle it?

Repeat and refine.  Circle back to the earlier steps often, especially if your hack has gone through a couple of generations.  Make sure you're still on target.  Make sure it's still rewarding the right behavior.  For that matter, make sure it still plays better than the unmodified original.

So there you have it, my own personal set of guidelines for hackery, whether it's a house rule or a setting transplant.  The bigger the hack, the more important these guidelines become to me.  Like the hacks themselves, I keep refining them as I try new things - and discover new pitfalls.  What have I missed?  What have you learned hacking games?