Process vs. Outcome

When developing a sub-system for an RPG rules engine, two qualities of a successful mechanic can fall out of sync. Let’s call these qualities process and outcome.

A sub-system with a strong process is:

• easily learned
• easily remembered once learned
• fast
• engaging

In other words, when you set out to use the rule in play, it goes quickly and smoothly, with a minimum of head-scratching.

A successful rules sub-system must also fulfill its purpose in the game, whatever that might be. In addition to the general goals of the process category, does it achieve the specific goal or goals of this particular project? If it’s a space combat system that’s supposed to feel a little bit tactical and give everyone on the ship something to do, does it achieve that? If it’s supposed to streamline investigative play, does it do that?

When it does, you’ve got a sub-system that contributes a desired outcome to the overall design.

Although DramaSystem focuses on dramatic and not procedural moments, it does need some way to work out whether characters succeed at external, pragmatic tasks, when they arise. Until recently I had a system for this that had good process but an unsatisfactory outcome. Procedural scenes “worked”: they were fun and simple in play. Yet they tended to come out the same way every time: the characters won, after accepting terrible consequences. This represented a failure of emulation; characters in dramatic shows don’t have to pay an awful price for every success. That sent me back to the drawing board. I think the new system has both process and outcome, but then I always think that. More testing will tell the tale.

Sometimes you'll have the opposite problem: a sub-system that gets you where you want to be, but in a manner that is unacceptably complicated, slow, or counter-intuitive. Your audience’s tolerance for difficult rules may change the definition of “unacceptably.”