... now with 35% more arrogance!

Tuesday, August 11, 2009

System vs. Mechanics

Two bloggers today wrote about system: Clash Bowley at I Fly By Night wrote about the need to tailor system to a setting, and Jeff Rients at Jeff's Gameblog begs us all to stop arguing passionately over trivial D&D system differences and just pick a version, mod it to taste, and not make a big deal about it. What I want to address is something buried deep in both posts: neither one is really talking about system, but about mechanics.

I define "mechanics" as any physical or computational procedure used to get a result in the game. Roll this die, spend these points, compare these numbers, play rochambeau... these are all mechanics. Almost every RPG player thinks of system as being identical to mechanics, in particular the resolution roll, although there are other mechanical parts to D&D in any version: the chargen mechanic and the experience mechanic, for instance.

I've argued before, though, that the resolution mechanic is the least important part of and RPG. You can substitute one mechanic for another without much trouble. You can even add mechanics for specific situations -- houserules, or setting-specific subsystems -- and the game will still be recognizable as D&D or whatever system you started with.

What you can't change, without creating a different system, is the structure. Things like "create a character with six attributes and a class and race, then send him with other characters on an adventure to defeat monsters and retrieve treasure, which earn experience that raises your character's level." It's a specific set of activities, conditional statements, taboos, and requirements that define how you play the game.

Mechanics are not System. Structure is. The bulk of the D&D system -- the real system, the structure -- has actually stayed the same, so it's pointless to argue about mechanics, even though it matters to me personally which I use. This is Jeff's point. The slight differences in the actual system (structure) between versions are another matter. One tiny change in structure matters far more than replacing all the mechanics in the game.

Don't argue about mechanics, but do argue about structure. Accept that it's OK for people to want a different system, but the systems are still different, and this is where system matters.


  1. Good point (I think?), let me see if I understand you correctly:

    Mechanics vs Structure. Using D&D vs BRP (basic role playing) as an example.

    The mechanics of these two games are very similar in that resolution is based on a d20/d100 roll under/over (doesn't matter) using skill/ability as the basis.

    The structure is very different: one uses classes & levels, the other does not.

    So far, I think I'm following you...

    Now what mechanics that make the 'system' unique to that game (or the atmosphere it is trying to present)? For example, Warhammer Fantasy role playing (WFRPG) uses a form of dice-pools for their magic (mechanics). But magic failure brings with it nasty effects that harm/scare witnesses. This mechanic reinforces the 'magic is bad/witch-hunts' atmosphere envisioned in the Warhammer world.
    Is this mechanics or structure/system?

  2. By coincidence, I deleted some extra material about D&D vs. BRP (and also T&T).

    On your first point: I think you have the right idea, although it's not phrased the way I would. The skill mechanics of D&D 3e/4e and BRP are different; however, noth games say "determine success or failure of tasks, using skills to set the odds". That's part of the structure. In contrast, character advancement for the two games not only use different mechanics, but different structure ("earn experience to increase level, which grants better class-based abilities" vs. "successfully using an individual skill earns the right to check if it improves after the adventure".)

    On the second part: "if a spell fails, it causes nasty effects" is a conditional statement and thus is a structure that defines a particular subsystem (spell failure.) It's not the mechanics that make the system unique, but the set of conditions, requirements, and taboos that tell you when you need to use mechanics and how to interpret them.