In the opening post, I talked about GM Intrusions in Numenera, and I’d like to further explore that in this post.
Last time, I asked you to imagine some of the responses to it. This time, I want to examine some real responses and ease the reader into how to look at the mechanic from more of a designer perspective. You may not be familiar with Numenera or game design, but that’s fine. That’s the bridge this blog aspires to be.
Here are some reviews and responses to the GM Intrusions mechanic from various review sites on the web:
While a GM intruding in Numenera can choose to do so for whatever reason, in Fate, this must be in accordance to what is known of the situation, not GM’s whim…
Intrusions are…deeply rooted in the episodic nature of the game. They keep the game flowing like a story. (Alex.8260)
It should also be noted, for those who are particularly allergic to dissociated mechanics, that GM intrusions are incredibly flexible tools which are used entirely at the GM’s discretion: You can use them all the time, you can use them rarely, or you can use them never. (Alexander)
During a typical RPG game I might decide a fight is too easy, so the floorboards suddenly break upwards and more zombies join the fight…it happens exactly when I/we want it to, and it is seamless. It can seem planned, because the players don’t know if I’m making this up or had counted on doing this.
During Numenera, I felt like every time this happened I had to stop, offer the player XP, and engage in this non-in-the-moment discussion…then I bring in the zombies, but now every player knows this is a contrived interjection. (AlphaStream)
You may not easily parse all of those comments for now, but the idea is that as you peruse this blog and others (see my Further Reading tab) you’ll become more and more comfortable with both the games referenced and the terms used. I quote them only to give you a sampling of how these conversations start. The main topic for this post is humble: let’s understand what a “dissociated mechanic” is.
The original use of the term was on a blog known as the Alexandrian (original post here), and can be contrasted with the term “associated mechanic”. In short, a dissociated mechanic is one which is primarily linked to a player decision and minimally linked to a character decision – it is dissociated from the character. An associated mechanic is one which is highly linked to both player and character.
As an example, let us suppose that in Numenera, the GM makes Intrusion where as I’m looking through some important personal records implicating a culprit to some crime, a strong gale picks up and many of the papers are blown through an open window.
If I were to refuse that by spending XP, it would be dissociated – in no way does my character realize he has XP or that he is “spending it to refuse this offensive wind”. That’s all on me, the player, outside the game. The motivations that drive it have to do with me the player – perhaps I’m impatient and don’t want to chase down the papers in-game. Perhaps I’m well ahead of my fellow players on the XP curve and can thus afford to lose some.
If instead I were to chase the papers, using the appropriate dice rolls in Numenera to make it outside as quickly as possible and to seek them out, that would be associated – I the player want the papers, but I the character want the papers in the exact same way. We are pursuing those papers within the in-game universe, without relying on abstract notions such as XP.
You can see how dissociative and associative aspects of a game might exist on a spectrum – whenever you roll dice, there is a degree of abstraction, since of course the character is not rolling the dice and has no reason to be thinking of dice.
I think we can agree, however, that the mechanic for slicing into a monster and doing damage is more associative, more linked to the game world, than a mechanic for ending a scene, refusing a GM intrusion, or for (in a video game) pausing the game.
With that out of the way, we can again return again to the comments above.
As you can see, some folks are fond of dissociative mechanics, and would in fact enjoy more rigorous guidelines for them. Alex talks about how “in Fate, this (meaning the mechanic) must be in accordance to what is known of the situation, not GM’s whim”. This reflects an underlying belief that sometimes giving control over to the GM’s whim may be undesirable.
Others find it unpleasant. Justin acknowledges that many GMs may be “allergic” to dissociative mechanics, and consoles them by offering the idea that they may use it sparingly, or not at all.
Finally, one of the commenters on Justin’s blog gives an example of precisely why dissociative mechanics can detract from a game – for that commenter, letting players know that some of his difficulty increases were “contrived” is a downer on his experience of running the game.
These perspectives are valuable to keep in mind both when analyzing games and when creating our own systems, whether we are making our own games or a homebrewed subsystem of an existing one. We must be ready to address all of those comments as designers.
We’ll be talking about dissociative and associative design more in the next Antology post, in the context of race design.
Featured Image by Andrée Wallin.
alex.8260. “RPG Codex Review: Monte Cook’s Numenera.” RPG Codex, 19 Jan. 2014, http://www.rpgcodex.net/content.php?id=9315.
Alexander, Justin. “Numenera – The Art of GM Intrusions.” The Alexandrian, 26 Aug. 2014, thealexandrian.net/wordpress/35499/roleplaying-games/numenera-the-art-of-gm-intrusions.
Alexander, Justin. “The Alexandrian » Dissociated Mechanics.” The Alexandrian, 20 May 2008, thealexandrian.net/wordpress/1545/roleplaying-games/dissociated-mechanic.