Structure vs Mechanics

So, Dan Maruschak recently posted to Story Games (the G+ community, not the forum; which you would think they were the same thing, and they are – except they aren’t) about the frequently expressed view that too many/too complicated rules are bad in a roleplaying game. Now, his post had a point all of its own, which I shall ignore because I want to talk about something else. Take that, rules!

Anyway. In discussion on the said post, I arrived at the view that there were two types of “rule”, which I shall here call structure and mechanics. Why is this relevant? I shall tell you if you would accompany me to the next paragraph…

Glad you could join me! The point I was responding to in making the above distinction was that sometimes, rules make roleplaying easier. Take a simple example. Fiasco has almost no in-scene rules. It essentially leaves the job of running scenes completely unconstrained – sure, one person sets the scene while another bunch of people decide the broad outcome (or vice versa) but everything else is down to whatever you collectively want to do. And the thing is, that works for some people, but for others it leaves them lacking direction and unsure when they should jump in. You have to develop the kind of culture that improv groups make use of all the time, and developing that culture can be challenging.

In contrast, Fiasco makes generating the overall scenario for the game much easier by providing a basic setting and a bunch of simple rules for generating story elements. You take turns, and nobody is in doubt about what they can and can’t do during this stage of the game.

So, weirdly, the most rules-heavy bit of Fiasco is in some ways the easiest and smoothest part of the game. All those rules didn’t get in the way after all!

…which brings me back to my point about structure and mechanics. See, I think Fiasco’s set up phase is not really a “rule” as traditionally conceived in roleplaying games. This is a bit of a vague concept which I’m having trouble articulating, but what I call a mechanic – the traditional RPG rule – is a very well-defined procedure for taking a well-defined input and generating a well-defined output. “When you are hit by a short sword, roll d6 and subtract it from your hit points.” “You can take two half actions or one full round action every combat round.” …that kind of thing.

In contrast, the Fiasco set up isn’t really like that. It’s all “before you start the game you should create some elements to use in play”. Now, I’m contradicting myself here slightly (did I mention I’m having trouble articulating this?), because the element generation tables have all the hallmarks of what I’m calling a mechanic, and the rules about how you arrange relationships and other elements around the table look like that  too. But the overall effect is merely to guide play towards a relatively ill-defined form: a structure, if you will. Similarly, Fiasco’s two-act structure and its token-based scene resolution are designed not truly to constrain play but to provide a framework on which to hang your story. Likewise, defining roles (is there a GM? What do they do? If there isn’t, how does that work?) is more about setting a framework rather than fixed procedures. This is all what I call structure, and although it kinda fits in the category of rules, it serves a radically different function.

Now apropos of Dan’s discussion, I’m not saying that structure is good while mechanics are bad. But it seems to me that roleplaying games have historically had a tendency to major on mechanics and leave structure to the GM to work out. And, furthermore, they have tended historically to err on the side of too much mechanic (for some people’s tastes) but very rarely got even close to too much structure. Even Fiasco, which is quite a structured game by RPG standards, is in my view not structured enough.

So in principle: more rules is neither good nor bad. But in practice, more mechanics is often going to turn out to be too much, while more structure is very unlikely to be too much. That may not stay true, if RPGs continue to develop and diversify, but even post-indie revolution it’s still the case for most games , in my opinion.

Author: rabalias

Rabalias grew up wanting to be a pirate. But a band of evil bureaucrats kidnapped him and forced him to work for The Man. Even so, Rabalias was patient and cunning. He escaped by gnawing his way through the walls of his prison and concealing the hole behind a picture of cthulhu. He fled to the coast, and stowed away on the Black Armada, where he worked his way up to the rank of Admiral.

6 thoughts on “Structure vs Mechanics”

  1. Weird – I was just having a conversation with another friend where he made a very similar (but possibly not identical) distinction. I’ve never made such a distinction before – seems a bit of a strange one to me, but I’ll think about it. I feel a blog post coming on…

  2. Intriguing post! In practice — outside Fiasco, say in D&D — have you experimented with adding more structure? Do you have thoughts about experiments you’d be interested in seeing? I’d like to see this fleshed out with more examples.

    My initial thought is that RPGs of necessity will be much less structured than board games (which I also love) by their nature, in order to allow improvisation and player authorship. The most structured RPGs I’ve played were probably my teenage dungeon crawls in the 80s, where we all understood that the only choice was: fight the monster in front of us, then loot, then identify magic items, then choose the next door…until we’ve explored the whole maze. In other words, we knew what the party was to do next (with minor decisions like how regularly to check for traps, and which door to try first).

    I can’t off the top of my head think of additional structure that might enhance my regular group (running house rules based largely on Iron Heroes and 3.5)…but I wouldn’t be surprised if others could suggest things we’d appreciate.

    Actually, there’s something our GM introduced at the beginning of most sessions that might fit your definition. We’re often given a small bit of homework (think about a memorable moment from your character’s childhood, what’s your most treasured possession, what was your first experience of combat & what was it like for you) that we then take a minute to describe, in character, before the game officially starts.

    Anyway, thanks for the p0st. I’d love to hear more examples (either that you’ve tried or that you might try).

    1. Hi Jeff. Thanks for commenting.

      I think in more traditional dungeon crawl-type games, the structure is actually pretty clear – albeit usually only implied by the rules texts. As you’ve described, it’s basically a map; the story moves from room to room with whatever is in each room being resolved in the order the rooms are entered.

      But that’s far from the only structure a game can take, of course. Even within the sphere of relatively traditional games, you’ve got games like Shadowrun which will take more of a mission structure (client gives you mission; you research the target, maybe; planning; execution – though admittedly execution can be quite dungeon-like). Or Call of Cthulhu and other investigative games, which are often more like a series of rolling events which the players hear of and get to investigate, leading to some climactic encounter either when they uncover the truth or perhaps when they fail to do so and the big bad becomes unignorably powerful.

      But a lot of the above is kind of implied by the genre of the game in question. I’m not sure whether Shadowrun sets out a formula for their story structure (maybe they do, I’m not sure) and even if they do, it’s strictly optional – this is simply the default way of approaching a story in those games.

      By comparison the Fiasco structure is mandatory. And it’s far from the only game which works that way. Here on Black Armada you can find my game FarmTopia, which is a game I wrote for a 24-hour design contest (see “free games”) and has a similar 2-act structure. I’m currently working on Disaster Strikes!, which is not yet out but which you can read about (see “designer diary” among the categories list). Other published games like this are Dog Eat Dog, which requires a scene-by-scene approach in which each player sets up a scene centred on their character. Or Durance, which is similar but instead the scene-setting player poses a challenging question for one of the characters (“how will Bob punish Pete for burning his house down?” – notice the implied arson, heh).

      I guess the point of all this is: if you deviate from the built-in structure of these games, you aren’t playing that game anymore, so it’s more than just guidance. It is in a very real sense a rule. But it’s clearly totally different from the mechanics we are familiar with.

      By the way, I think the question of who has the power to do what vis-a-vis the game world also qualifies as structure. E.g. Many of the games I’ve mentioned above (not coincidentally) do not have a GM. Instead the GM’s traditional powers are somehow handed out amongst the players. Again, clearly a rule but not a mechanic, I would argue.

  3. Here’s a structure that you can use for all games. When you’re framing a scene, do the following:

    × The GM starts describing the place with one sentence.
    × Another person add something new to the scene with one sentence.
    × The rest are then allowed to either add something new or add details to something more described. Only once sentence at time time.

    In a D&D game, let the players describe their own rolls AFTER the roll. How does the character fail at sneaking? What kind of information will a History check bring? The game master may add consequences to failed rolls or add more information to successful rolls.

    Structures and mechanics are two things that I talk about a lot, and also procedures and directives. I myself prefer to have directives sorted in structures, just as procedures. One example of this is investigator skills in Esoterrorist/Trail of Cthulhu. They are nothing more than directives hidden in procedures. They aren’t skills – they are a technique.

    1. Hey Rickard. Thanks for commenting, and apologies for the delay in responding – your comment came in while I was away on holiday and I’ve only just got back to comment-processing.

      An interesting selection of system-elements you have there. I think you’re right that there is something in common between the directive/procedure distinction and the structure/mechanic distinction, although I’m not certain they’re the same – I’m still feeling my way around this concept a bit.

      I’m not sure I agree that ToC investigative skills are a directive, though; I would suggest that they operate mechanically i.e. if there is a pre-decided thing you could discover and you have a point of investigative skill left, you can spend a point of investigative skill to discover that thing. That sounds pretty procedural, and it definitely isn’t mere guidance. I’d also say it’s mechanic rather than structure, for a similarish reason. The structural aspect of it is: ToC is a game about piecing together clues, and the process of uncovering them; it is not about whether the characters can uncover them in the first place. Investigative skills are the mechanism through which this game-structure is realised.

      Actually, thinking about it (and I’m possibly being pedantic here, which is me trying to figure out what I think about this concept, not being critical) I’m not sure that your other examples aren’t mechanical. “When the GM describes a scene, take turns to add a further descriptive sentence” sounds pretty mechanical to me. The corresponding structure is something like “divide the game into scenes and begin each scene by describing the situation”. “Roll the dice then describe what happens” also seems like it could be a mechanic, though the fact that the player gets to describe the whole action including the outcome might be verging on the structural.

      …I think I need to work on this some more! Thanks for giving me food for thought. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *