This Feature is part of my long-running series about advanced adventure and encounter design for tabletop roleplaying games. It’s called True Scenario Designery. If you haven’t been following it from the start, use The True Scenario Designery Course Index to catch up.

This specific installment is part of a several-part section of the series about planning and outlining roleplaying game scenarios that the players can play, win, and lose like actual frigging games. Crazy, right?

Momentum: Building Victory

Today’s True Scenario Designery lesson echoes the last one on Inertia even though it’s basically about the opposite of Inertia. At least game design-wise. Remember what I said last week about not using what you know about physics here.

The reason these two lessons are gonna look the same is because I’m purposely writing them that way. And why am I doing that? It’s because Momentum and Inertia complement each other.

In anatomy, you’ve got this idea called antagonistic muscle pairs. You see, muscles can only do one thing; muscles can only tighten up. Well, technically, they can also relax but that’s just not tightening up. Relaxing doesn’t create movement. If you want a joint — like that knee in your arm — to work, you need two muscles. One tightens up to bend your arm and the other tightens up to straighten it. In anatomy, the paired muscles are designated the pushicus and the pullicus. Or whatever. Who gives a crap?

Though I’m sure some dumbass in the comments is gonna tell us so they can score internet points by being the smartest person in the room. After all, it’s not like I stopped all the people with tiny… senses of self-worth, let’s go with that… from explaining physics last time.

Anyway…

Momentum and Inertia are the pushicus and pullicus muscles of the gameplay world. Inertia pulls the game toward failure and Momentum pushes the players toward victory. The interplay between the two creates the gameplay dynamic that makes games feel so awesome.

Momentum’s actually the easier of the two to explain, but it’s weirdly tricky to apply it to roleplaying games once you actually do understand it.

Let me start, though, by getting you to understand.

Momentum: Defined and Undefined

Like last time, I’ll start with a nice, clear definition…

Momentum — in game design — is a gameplay force whereby once the players start winning a game — a scenario or an encounter or whatever — they’re more likely to keep winning.

Unlike last time, I don’t need two different definitions with a clumsy distinction between them. There’s no Hard and Soft Momentum. It is what it is. Once you — a player — start winning, you’re probably going to keep winning until you win. All things being equal, anyway. Momentum is like a compounding force of success. Every good move you take and every round — or whatever — you win makes it more likely you’re going to beat the game and get the good ending.

Honestly, this idea’s so super obvious and totally intuitive that I find it utterly baffling that roleplaying game designers struggle with it so much at every level. And yet, they almost never get it right. I was absolutely floored when the designers of Dungeons & Dragons’ 4th Edition showed enough insight about this Momentum crap to completely change how magical items worked — which 5E later copied — but that’s a story for another heading later.

The point is that, as crappily as roleplaying game systems and scenarios handle Inertia, they positively suck nine kinds of ass when it comes to Momentum.

Gameplay Dynamics, Not Game Mechanics

Last time, I said, “You dumbasses love to conflate game design concepts and ideas with Game Mechanics,” and then delivered a whole rant about the difference between Gameplay Dynamics and Game Mechanics. Remember that? I sure frigging hope so because I ain’t doing it again.

Momentum ain’t a Game Mechanic. There’s no Momentum Mechanic.

Except when there kinda is…

I’m gonna let y’all in on a secret now that I’ve gotten you to grasp the difference between Game Mechanics and Gameplay Dynamics. Though, if you think this is gonna confuse you, just skip to the next section and pretend Gameplay Dynamics are not and can never be Game Mechanics.

Sometimes a Game Mechanic is a Gameplay Dynamic in and of itself. That is to say, sometimes, there’s this rule or system in a game that literally does nothing except to create one, specific Gameplay Dynamic. Remember when I said, for example, that Hit Points and Spell Slots interact in lots of ways with lots of things so they’re never just affecting one Gameplay Dynamic? Well, sometimes there is a Game Mechanic that does just one thing, and that one thing is creating an important Gameplay Dynamic.

How does that happen? Sometimes, it’s because one Game Mechanic is all it takes. Sometimes, it’s because a game designer realizes there’s a missing Gameplay Dynamic and patches something in quick-like to fix it. Or they’re working with a decades-old game system and need to fix a specific issue in the smallest way possible.

This doesn’t change the fact that Gameplay Dynamics and Game Mechanics are two separate things and that Gameplay Dynamics only exist when players play games. It’s just that sometimes, the entire interplay is coming from the players playing with one, specific Game Mechanic.

Don’t do that shit if you can avoid it. Yes, it’s sometimes fine and it’s sometimes all you need. And yes, sometimes, you realize way too late in your adventure design there’s no Inertia to it all or something, so you throw a timer in there and call it a day. But it’s always better if you have these dynamics in the back of your head from the time you start designing so you don’t end up having to do that crap.

That’s why we’re talking about this.

Momentum Isn’t Progress

Last time, I warned you not to confuse Challenge and Inertia.

This time, I’m warning you not to confuse Momentum and Progress. They seem like they’re the same thing, but they ain’t.

Say, for example, your adventure’s all about getting through a dungeon of minions, confronting a boss, and killing it. Technically, every Encounter the players cut through brings them closer to victory, right? Because they’re now closer to the end and because there are fewer obstacles to face, the probability they’re gonna win the whole adventure is higher than it was before. That ain’t Momentum, though; that’s just making Progress.

Hell, even if the goal’s just to kill every monster in the dungeon, each kill still ain’t Momentum just like every mile you cover in an adventure about getting to the next town is just Progress and not Momentum.

Momentum is about how your Progress empowers you to handle the Scenario’s major challenge. Go back to that example and imagine the boss is a lava monster. Killing its kobold minions doesn’t make the players more likely to win against the boss, does it? But what if one of those kobold minions had a scroll of ice knife or some shit like that, some single-use magic item that the lava dragon’s vulnerable to. Now killing the minions does make fighting the dragon easier.

Likewise, if, on the way to Townsville, you overcome a traveling halfling farmer’s suspicions and he agrees to give you — or sell you — extra food, now you can stretch your rations another day. That mitigates the risk of getting slowed or delayed. That’s Momentum.

You must grok this crap. Progress isn’t Momentum and it’s on you, the Scenario Designer, to figure out how the players can build Momentum by making Progress. Merely overcoming obstacles and getting closer to the finish line ain’t enough to count as Momentum.

Pandemic: An Okay Example of Momentum

Last time, I brought up Pandemic — the 2008 board game designed by Matt Leacock and published by Z-Man Games — as an example of a game with a strong Inertia Dynamic. Unfortunately, Pandemic ain’t the strongest example of the Momentum Dynamic — and I don’t even think I really even need an example; you’ve probably got this shit already — but for the sake of my commitment to parallel construction, I’ll talk about it anyway.

Pandemic’s got two okay-ish examples of Momentum. The first has to do with Research Centers. The players start with one Research Center in Atlanta but can — and usually do — construct more around the board. Because actions are super valuable in Pandemic and because movement is wasted action, the players really want to be close to the outbreaks — so they can deal with them — and close to the Research Centers — where they make the cures for the diseases. So you can see how having Research Centers scattered around the globe increases the odds of victory.

A bigger example is how, once you’ve actually come up with a cure for a specifically colored disease — that’s Progress, by the way — you can remove all the cubes of that color in a given city with one action instead of just one cube. Each cure you make, therefore, not only helps you progress and empowers you to eradicate each disease, but it also makes it easier to deal with outbreaks until its eradicated.

I should note that Pandemic’s Inertia Dynamic is a bit stronger than it’s Momentum Dynamic and that ain’t an accident. Pandemic is a challenging game. It’s meant to feel like things are always one crisis from disaster and that you’ve never really got a handle on anything. Not even when you’re making headway. That just goes to show how these Gameplay Dynamics affect the Playfeel of a game and how balancing these Dynamics depends on your vision of the game. You’re rarely going for one-to-one complementarity, even if you could actually, quantitatively do such a thing.

Like I said though, this shit’s easy to grasp and you probably didn’t need those examples. Easy to grasp as it is, though, Momentum is tricky to turn up in roleplaying game systems and scenarios.

Getting Help from the System’s Designers

Unfortunately, as with Inertia, this Momentum crap is on you — the Scenario Designer — to figure out. You’ve got to design adventures so the players’ odds of success increase as they make progress and that ain’t always as easy as it seems like it should be. Now, you’d hope that roleplaying game System Designers would know how important Momentum is and thus give you some tools to work with, but, as they say…

Hope in one hand, shit in the other, and see which one fills up first.

The problem isn’t just that System Designers don’t understand the need for Momentum, it’s also that they often get it totally frigging backward.

Let me start, though, with an example of a Game Mechanic you’ll find in most fantasy roleplaying games that does provide a good Momentum-building tool. I’m talking about loot. Treasure. Specifically, I’m talking about magical items and equipment.

Players often trip over magical items as they explore. Those items make their characters more powerful in general, of course, which makes them a kind of Character Advancement thing, but those items can also arm the players to deal with specific challenges if they’re carefully placed.

The thing is, though, that Dungeons & Dragons and other games of it ilk have been a little all over the place with this magical item crap, and few designers at either the System or Scenario level think about magical items as Momentum-building tools. In the past, you couldn’t use most magical items until you schlepped them back to town and got them identified. For Character Advancement, that’s fine, but for in-adventure Momentum, it ain’t so hot.

It was the D&D 4E designers who saw the issue here and purposely fixed it. It was that edition — not 5E — that made it possible to identify magical items by just fondling them for a few minutes while taking a mid-adventure breather. While it admittedly took some of the wonder out of magical items, it did make them a useful way for Scenario Designers to equip players for their future challenges.

D&D 4E also had another Game Mechanic that was very directly tied to the Momentum Dynamic. In 4E, every second Encounter was designated as a Milestone Encounter — unless the Scenario Designer wanted to specifically designate certain Milestones — and victory in such an encounter earned each player’s character an Action Point. Players could spend Action Points to take an extra action and they could save them up — and amass them — for really big Encounters.

This Action Point thing actually dodged being a single-Dynamic Mechanic as I talked about above, though. See, when you slept for the night, your Action Points reset. So, if you ran out of resources and had to head back to camp, you lost all the Momentum you built. Thus Action Points affected both the Momentum and Inertia Dynamics and created this tug-of-war we call a Push Your Luck Dynamic. In fact, most Push Your Luck Dynamics rely on the interplay between Inertia and Momentum.

What a shame that 4E was so utterly unplayable. It was chock full of brilliant ideas.

That spiel about Action Points might bring to mind Game Mechanics like Savage World’s Bennies, but those illustrate what I said about game designers often getting shit backward. Many roleplaying games have Bennies or Action Points or Bonus Pools the players can draw on to juice their odds, but they usually start each adventure or session with a bank of such things and then spend them down through play. There’s usually a way for players to replace spent points through play, but the problem is, the whole Mechanic is still working backward. Momentum is supposed to build as the players make Progress and Bennies and Bonus Pools start full and dwindle.

I know someone’s going to bring up the neat Escalation Die in 13th Age — which I find a little too abstract and arbitrary for my tastes, but do admit it’s a neat mechanic — and that’s also an example of a Mechanic that does more than one thing. If the players are winning a fight, the Escalation Die does indeed help them keep winning, but if they’re losing a fight, the Escalation Die helps them reverse their downward spiral, which is something we call a Reversal or Turnaround in game design.

Unfortunately, though, it’s mostly on you to handle this Momentum thing in your Scenario Design.

Next Time: Let’s Actually Design a Thing

Now that I’ve introduced you to the complementary Gameplay Dynamics of Inertia and Moment, I want to show you how to actually use this knowledge.

I’ve subtly hinted a few times now that these Gameplay Dynamics aren’t really things you build — especially not with single-use Game Mechanics — and that if you do end up having to throw Game Mechanics into your Scenario to introduce a Dynamic, you done effed up. Instead, as you design Scenarios — encounters, adventures, campaigns, or whatever — you keep these Dynamics in your head. Ideally, you want them to emerge organically as the players play the Scenario.

Finding a magical item on a dead monster that helps you win a major challenge later, for example, feels organic. Earning abstract Momentum Points feels less so. Running down and tiring out but not wanting to risk resting because you’re afraid the situation might get worse if you don’t hurry feels organic. Running against a Turn Timer feels less so.

So, next lesson, then, I’m going to drop all this high-minded, conceptual crap. We’re going to go into the lab and I’m going to show you how I would design an adventure with these dynamics in the back of my head by, you know, actually designing an adventure. I ain’t gonna build and map the whole thing, mind you, but we’ll come back to the same example when it’s time to map and build shit.

See you then.