As promised, this time we’re going to examine something I call narrative mechanics. These break the model that I’ve already discussed (which separates mechanics and narrative) by combining the two and becoming something new and emergent. I strongly suspect that narrative mechanics—at least as I am using the term—are unique to TTRPGs, which makes them one of my favorite topics to examine.
What on earth are narrative mechanics? They are mechanical elements of the game that inform the narrative aspects of the game. For example, if a game handles PC/NPC interaction purely narratively, but the GM still takes into account that it says “charming” on the player’s character sheet when determining the NPC’s reaction, that’s a narrative mechanic. It’s not “mechanical,” per se, but it is a formalized way of directing the story with narrative content.
But narrative mechanics can also be instances when narrative content informs and affects what would typically just be straightforward game mechanics. For example, if the GM in a game is encouraged to give an auto-success at a task to someone because of their character background (for example, a character who was a miner in their past, knows all about underground construction and doesn’t need to make any kind of roll to gain information about it), that’s a mechanic, but it’s really entirely narrative-based. Even if the rule for electronic lock picking says that a character who watches someone type in the passcode can automatically open that locked door later, that’s as much narrative as it is mechanical.
To look at it a different way, narrative mechanics can replace what would normally be a standard, typical game mechanic with pure narrative. Sometimes, this is just pure adjudication and is handled at the table. The rules might say that the monster chasing the PCs can open any doors they close behind them without slowing down, but if the PCs greased the doorknob, the GM might say that the monster loses some time fumbling with the door. It’s narrative that affected—changed, or even replaced—the rules of the game.
But, for our discussion here, I’d like to stick to game design as opposed to GM techniques (at least for now—we can talk GM techniques sometime in the future if there's an enough of an interest for that.). And from a game design point of view, that means deciding to actually hard code narrative mechanics into the game itself or not.
Nowadays, when you use a term like code, you might think computers and computer games, and my use of that word is intentional only to call out the fact that narrative mechanics are really the purview of tabletop games. A narrative mechanic is one that probably would never work in a computer game, because they require the ability to apply the logic of the narrative to an otherwise purely mechanical situation.
Although to be fair… you could specifically code into a game the kinds of mechanics I’m describing, but you’d have to do it specifically on a case by case basis, and thus it would only work in prescribed (and thus anticipated) situations. So when it comes to tabletop games you can follow suit and codify narrative mechanics either through specific instances (“characters who watch someone type in a lock’s passcode need not make the requisite electronic lockpicking roll”) or you can create narrative mechanics via more general encouragement for the GM (and players) to use logic from the narrative and apply it to the game.
While the latter example would be pretty much impossible to code into a computer game on a meaningful level, it is exactly what I did in Numenera (and later the Cypher System Rulebook). Rather than a lot of corner-case narrative mechanics, the rulebook has a lengthy discussion on the GM’s use of logic and adjudication when running the game.
In fact, most tabletop RPGs that “hard code” narrative mechanics into the game do so through scenarios rather than the basic rules of the game. For example, in a sci-fi game, a scenario about exploring an abandoned space station might say how the game changes if one or more of the characters involved had ever visited the station before it was abandoned (essentially, they would know their way around and might know some of the passcodes, etc.). This is just logic, but the scenario designer is putting it right in the adventure’s text rather than just hoping the GM will do it on their own.
To be clear, a published scenario that doesn’t hard code in helpful narrative mechanics like that isn’t bad, but it should be a deliberate choice on the designer’s part. And it probably depends on the specific rules system the scenario is designed to use. Because a game that leaves no room for narrative mechanics can be thrown out of whack if a scenario puts them in. For example, take a game that requires players to spend the same points to get better at combat and talking to people. If the scenario introduces a narrative mechanic into talking to someone (“if the PCs say the right thing to this NPC, they don’t need to roll to persuade them to do what they want”) but not in combat, for instance, the scenario designer has just told the players that spending points on being good at talking might be a waste of time. At the very least, it’s not treating the two things similarly.
If any of this sounds familiar, it might be because it’s very much the sort of thing I was talking about in Part 1 of this series to explain the important difference between narrative mechanics. And now I’m talking about the possibility of fusing the two. But the point is, you have to be aware of the implications and the consequences. Narrative mechanics or no narrative mechanics, there’s no right or wrong method here—except for not thinking about it. That’s always wrong.
So if narrative can sometimes replace mechanics, are there narrative mechanics that do it the other way? Where mechanics replaces narrative? Maybe, but it’s probably less common.
Consider this situation: the PCs encounter a sphinx and (predictably) the sphinx gives them a riddle to solve. Many games will approach this narratively. In other words, the players need to come up with the solution and have their characters tell it to the sphinx. But a player might say, “Can I just make a roll based on my intelligence to come up with the answer?”
The answer might be yes or it might be no, but if the designer’s done their job, the GM shouldn’t have to guess which is the right thing to do. The designer has to think, does this kind of narrative mechanic fit into the rest of the game? And if taken to its ultimate conclusion, is it okay if the players always use a mechanic like this rather than handling things narratively?
A lot of this has to do with the amount of power the designer wants to put into the hands of the people at the table and how much into the “hands” of the game system. This decision is conveyed by the way the rulebook itself is written, the GM advice provided, and sometimes an overt transparency that might include simply telling the players, “This is a narrative-based game,” or “This is a game that walks the line between story and mechanics.” Or something like that.
The important thing to remember is that narrative and game mechanics have their own uses in this innovative design space, and what I call narrative mechanics can offer a middle ground.
Great three-part series on narrative and mechanics! Monte, if you ever teach a game (RPG) design master course, I am IN! (In fact, I think you should.)