Fate Core Thought of the Day: Pacing Mechanisms in Fate
So, this is something I've wanted to write for a while, but haven't gotten around to. Until today.
What's a pacing mechanism?
One of the things I see some confusion about in Fate are the various pacing mechanisms available - Conflicts, Contests, and Challenges, or as I like to call them, the 3 Cs.
So, I call them all pacing mechanisms. What the heck do I even mean by that? That seems to imply that they're all related to each other, but they're clearly not, right??
Okay, so time for Rob to get pedantic (like that's new). We roll dice in Fate to answer a question. Technically, if we wanted to, we could answer any question, no matter how big or small, with a single die roll - probably an Overcome.
Hell, if we were running Star Wars as a Fate game, we could do the entire game as a single Overcome roll against the Empire! But... what fun would that be?
And fundamentally, that's the point of pacing mechanisms. They're nothing more, and nothing less, than a tool to make the resolution of a single question take longer than one roll of the dice/action resolution.
(And if you hear me refer to stress as a pacing mechanism, that's why - stress determines, to a great extent, how long a Conflict will last).
But why call them pacing mechanisms? For instance, aren't Contests really chases? Isn't that what they model?
Nope. Contests don't "model" anything. They just drag things out, and provide an ending condition. Sure, their mechanics map reasonably well to how you'd model a chase, but that doesn't mean that they actually model chases. In general, you're best off if you use the pacing mechanisms as pacing mechanisms, and leave the modeling to the narrative level. Roll the dice, figure out the results, and then narrate the results in a way that makes it clear that one side or the other is getting closer to achieving their goal. In Fate, the "fiction", the shared imagination and view of what's going on, informs the mechanics rather than the other way around.
So, which one of these do you use? This seems to be a common question, and one that I think has a pretty simple answer, if you look at the question from a slightly different way.
Much like Attack vs. Overcome isn't based on what you're doing, but rather whether you're trying to Take Out your opponent, which pacing mechanism you choose isn't determined by the actions that are being undertaken, primarily. It's determined by the nature of the opposition.
I'll start with Challenges, since they have the generally easiest criteria. Use a Challenge when you don't have active opposition over the entire Challenge. This could mean that that the opposition is the environment (barring Fight Fire and the like). This could mean that the opposition is unaware and inactive (see the Contest section for what I mean by that). This could mean that you do have active opposition, but only for part of the Challenge (in which case you can either model that as an Overcome, or as a sub-Conflict/Contest as appropriate).
Zird warding off the zombies meets these criteria. The zombies are (mostly) a passive, environmental challenge, and at any rate he's really barring the door to them. Convincing the townspeople is arguably active opposition... but they're not interfering with the majority of the challenge, and so is an Overcome. Casting the ritual is simply environmental, and is an Overcome.
Now, part of a Challenge may involve active opposition - such as the villagers being convinced in the Zird example. In that case, you can either treat it as a simple Overcome within the Challenge (remember, that all pacing mechanisms are basically stand-ins for a single resolution), or you can expand it out further into an inner Conflict/Contest if appropriate.
But what if you have active opposition - some individual or party that is directly opposing the question that you're trying to answer? That leaves Conflicts and Contests, which is where a lot of questions seem to come up.
If your opposition is active, and direct, you use a Conflict. By direct, I mean that the goal of both parties is to get the other to back down in some way - either by getting knocked out and killed, by surrendering, by fleeing, etc. For a Conflict, the two things should be true:
1) Both sides are committed to getting the other side to back down
2) The "question" of the conflict is either:
a) whether a particular side will back down in some way
b) something that the winner can accomplish if the opposition isn't there
So if you're trying to capture some bad guys (or the other way around), that could be a Conflict, so long as both sides are exchanging blows (by choice or because no other option exists). If you're trying to get past guards to defuse a bomb, that's a Conflict, up until the guards run off to save their hides, or you do.
If your opposition is active and indirect, choose a Contest.
By indirect, I mean simply that both sides aren't engaged in mutual annihilation. The obvious cases would be races, or a chase. It could be trying to capture someone, so long as they're trying to evade capture. It could even be fleeing from a shooter (where the question becomes "Can I make it to cover before I get shot/killed?"). But the key here is that there are still two or more active participants/sides - you generally don't use a Contest if one side is unaware.
aside: You might choose a Contest with an unaware side, if that side is actively doing something that would bring the Contest to a close - a sorcerer opening a gate to an evil realm, for instance, might be in a contest with the adventurers trying to make it to his sanctum to interrupt the spell, even if the sorcerer is unaware of their presence. The real key here is the active bit.
In general, any time you can phrase the question you're answering as "do I <my desired goal> before they <their desired goal>" is a Contest, unless both of the desired goals are "beat up the other guy".
Choosing Based On Context
So that's the basic way that I divide up the pacing mechanisms. And it's interesting, because some high-level actions may fall under any of the three pacing mechanisms, based on the context of the action.
As an example, let's say you're a sniper, and what to shoot someone in the head. Is that a Challenge? Is it a Contest? Is it a Conflict?
If the target is unaware of what you're doing, and there's no enemy awareness of your presence, it's a challenge - there's no active opposition, so there's no "other side". There's certainly some passive opposition that must be overcome in some way or another, but you're not dealing with an active opponent.
If the target is unaware, but there's a patrol in the area that's hunting you down, then it's a Contest - "do I shoot my target before the enemy patrol finds me" definitely falls into the Contest template described above.
If you're in the middle of a firefight, and trying to snipe one of your opponents, then it's a Conflict, pretty clearly.
These three pacing mechanisms do a pretty good job of covering just about all situations. Some might requiring a bit of coercing to get into place, but they're all basically workable. I don't know that I'd mix them - shooting someone that's running to me seems mostly like a Contest, so I don't know that I'd necessarily mix Stress/Consequences into that. And again, they don't really "model" anything. They're about pacing, not modeling.
And obviously there's other ways to handle pacing besides these three. If there's something that really bugs you, come up with another mechanism to handle it! But I'd keep the general idea of these being pacing mechanisms intact, and keep the modeling in the narrative.
20130903 Fate Core Thought of the Day Pacing M...
Shared to the community Fate Core - Public
+1'd by: Van Davis, Sean McLaughlin, Marty Gentillon, Gabriel Fua, Hani Musallam, Tony C, Christopher Ruthenbeck, Juanma Barranquero, David Rourke, Peter Meyer, Iván Tomás, Heather Rasmussen, Rob Thornton, Jürgen Rudolph, Ville Makkonen, Angela Robertson, Porter Williams, Patrick Rowley, Jon Tate, Chris “Callisto” B, Matt Kay, Jacob Possin, Wil Hutton, Paul Kießhauer, Eric Willisson, Sean Smith, Jonathan C. Dietrich (jcdietrich), Brian Boring, Michael Langford, Jack Gulick