I’ve got a lot to do and not a lot of time, so let’s blaze through the disclaimers quick-like.

This feature is part of my master course in adventure and campaign design, True Scenario Designery. Each builds on the last. If you ain’t been reading them in order, fix that with this handy dandy course outline.

The True Scenario Designery Course Index

This course is based on a bunch of assumptions about the role of Game Design in tabletop roleplaying game adventures and campaigns. I’ve spelled them out. You’re free to disagree with them and do things however you want, but you won’t find anything in this course to help you and you’re just gonna hate it. No one in my comment section cares and neither do I. Do us all a favor and find something else to do.

I’m inventing my own lexicon of terms for this course and words mean what I say they mean. Don’t like my terms? Think they have different meanings? No one in my comment section cares and neither do I. Go bother someone else.

Consider yourself warned. I’m done debating every damned thing I say.

Designing On Purpose

Welcome back to my amazing master class on the art of scenario design: True Scenario Designery. Yes, I know design is already a noun and doesn’t need an -ery. It’s called parallelism, dumbass. And didn’t you read the warning about arguing with me about my words?

I wish I could say we’re done with the introductory, conceptual bullshit. But I can’t. If you’re going to build your skills of a scenario designer, you need a grounding in the fundamentals of game design and how they relate to tabletop roleplaying game scenario design. And I’m gonna spend the next three-ish lessons crowbarring that crap into your cranium. I’m gonna tell you how games work and how to make them. In the very general sense.

This shit ain’t fun. I know you want to draw maps and fill them with monsters. I do too. But — and this is today’s theme — drawing maps and stocking dungeons without deliberation and understanding won’t get you the best damned adventures you can possibly build. And that’s the goal, right? None of this perfectly adequate, serviceable adventure garbage for you anymore.

Because this conceptual introduction crap ain’t a lot of fun, I’m gonna do my level best to get us through it as quickly as possible. Which, as you know, is something that does not come naturally to me. If I seem a little rushed in my tone today, that’s why. I’m just gonna explain ideas and move on. There will be no fighting, justifying, arguing, deriving, analyzing, or convincing. I’m just gonna tell you how it be.

The pile of concepts I want to address in the next three-ish lessons forms one giant, ugly, interconnected Gordian knot of a mess. I’ve tried to stick the related ideas together and put them in a logical order, but that’s not totally possible. We’re gonna bounce around a bit. Not so much today, but in the two follow-ups to today. So if something’s confusing or unclear, just wait. It’ll probably click once I’ve taken the full and complete game design dump on you.

To make this shit easier to grok, I’m going to focus heavily on examples and hypotheticals. I know that’s asking for trouble because gamers get so obsessed with nitpicking examples they miss the underlying concepts. Please don’t.

This shit’s eating into my word count, so I’m moving on to the real topic du jour of the day: Designing on Purpose.

The True Designing on Purpose Lesson Starts Here

Scenario Design — or Adventure Design or Campaign Design or whatever you want to call it — is Game Design. Tabletop roleplaying games like Dungeons & Dragons aren’t games by themselves. They’re just piles of disconnected mechanics. When someone like you comes along to write an Adventure or Campaign or whatever — and it doesn’t matter whether it’s for personal use or publication nor whether you’re writing a beautifully complete document or some scrawled notes or just a couple of stats and maps because you already know what you’re gonna do at the table — when you write a Scenario, you’re finishing the Game Design process. You’re designing a game.

I know this is well-trod ground. Stay with me.

Game Design is all about building satisfying gameplay experiences. I promise you’ll understand the anatomy of a gameplay experience by the end of this three-ish lesson blitz so just smile and nod right now.

Building a satisfying gameplay experience ain’t about the story or the simulation. Tabletop roleplaying gameplay experiences include those things — you can’t ignore them — but they’re secondary to the gameplay experience.

Building a satisfying gameplay experience also ain’t about just throwing situations at your players to see what happens. That’s also part of how roleplaying gameplay experiences work out, but it’s also secondary to the experience you design. True Scenario Designers don’t leave shit up to chance or the wild whims of idiot players and they understand that Player Agency ain’t about tossing a bunch of monkeys in a sandbox to see what ends up covered with poo.

Yes, we’ve been here before too. Don’t tune out.

The knock-on effect here is that you — the True Scenario Designer — must be capable of turning anything into compelling gameplay and that anything you include in your game must accommodate compelling gameplay.

And that’s the idea behind what I’m calling Designing on Purpose, but which you might call, if you want to sound all academical and boring, Purpose-Driven Design.

And it’s easier to explain what that means with an example.

Merman’s Mystery: A Lesson in Designing on Purpose

So, this happened in the Angry Supporter Discord Server a few weeks ago…

French Rice Merman — 06/06/2024 6:06 AM
Say you’re running a mystery and the players come to the wrong conclusion. Do you tell them?

From a gameplay standpoint, there’s one correct answer to that question. It’s yes. Yes, you must tell the players if they have the wrong conclusion. Why? Because, in a game, the players have to know whether they’ve won or lost. That’s just how it be.

Don’t read too much into that. And don’t read any words I didn’t say. I ain’t saying you’ve got to stop the action and announce in your exposition voice, “You have answered the mystery correctly!” and play the Final Fantasy Victory Fanfare on your soundboard. I ain’t saying you’ve got to interrupt your players as they’re discussing their theories and say, “Guys, stop, you’re barking up the wrong ass.” All I’m saying is that, once the game’s over — the encounter or adventure with the mystery — the players have to know whether they did good or not.

It’s your job, Madam or Masseuse True Scenario Designer, to recognize such gameplay needs as, “The players must be able to assess their successes, failures, and progress,” and build your game to fill those needs.

In my module — The Fall of Silverpine Watch — there’s this murder-mystery side deal the players can attempt. They don’t have to solve it, but doing so makes getting one of the module’s two Success endings easier.

At the end of the module, I tell the Game Master to use the party’s Escort Quest NPC Buddy to ask the players what they think happened and why there was a ghost and all that shit. She’s curious about their answer to the mystery. Once the players give their Final Answer, the Game Master is told to give one of three responses.

If the players mostly got it right, the NPC says, “That makes perfect sense. We’ll never know for sure what happened, but I bet you got it right.”

If the players got close but missed key details, the NPC says, “I don’t know… it sounds like you’re missing something. It doesn’t totally add up. Too bad we’ll never know because we have to move on.”

And if the players are totally wrong, the NPC says, “What you’ve just said is one of the most insanely idiotic things I have ever heard. At no point in your rambling, incoherent response were you even close to…” you know the rest. And no, she doesn’t really say that. I’m being funny. But she does say, “I totally don’t buy that theory. Sorry. But it doesn’t matter because you killed the ghost and we’ve got to move on.”

That little scene exists in the module solely because I — as a sexy gaming genius — know that players have to walk away knowing whether they did a good job or not. Even if the mystery’s just an optional bonus side quest. And I found a way to build that into my adventure. One that fits the game’s story — Oona is curious and good-hearted by nature and she spends the whole adventure asking questions — and that fits the world’s simulation — Oona never outright tells the players whether they’re right or wrong, just whether their theory makes sense to her.

That’s Designing on Purpose. That’s recognizing a gameplay need and building compelling gameplay around it. That’s accommodating Game Design principles in every aspect of the game.

The Power of Purpose

Now, this shit ain’t just about meeting the basic needs of game design. Designing on Purpose empowers you to tweak the gameplay experience to whatever goals you’ve got. You can use it, for example, to avoid problems or even to adjust the gameplay difficulty.

Say your ghost story murder mystery ain’t just a side thing. Say, instead, that your Scenario starts with a ghost beseeching the players’ characters to avenge his murder so he can move on. That’s the win-or-lose adventure goal. And we’ll talk more about Goals in another lesson.

As a True Scenario Designer, you know this whole solve the mystery to win thing is likely to turn into a Perpetual Adventure if you’re not careful. What’s a Perpetual Adventure? It’s one the players can just keep trying over and over again for as long as they want. Either it doesn’t have a firm failure state or the players don’t know when they’ve failed.

Imagine the characters go to the ghost and say, “We’ve solved the mystery. It was Eustace Polyglottus of the Lexicographers’ Guild that killed you and we’ve put him in his grave.” But they’re wrong and the ghost doesn’t vanish into the ether. Now, they can take another stab at the mystery by stabbing another suspect. And another. And another. They can just keep stabbing suspects until they finally get the right one.

I’m being facetious in the example so skip the comments. But the problem’s a real one. Perpetual Adventures are terrible. And by knowing that, you won’t build one. You’ll invent some reason why the players can’t keep solving the mystery over and over again. Maybe the ghost has until midnight to ascend to the heavens or else he’ll be shackled to the material plane, unheard and invisible forevermore.

That’s Designing on Purpose to forestall a problem.

As for adjusting difficulty, imagine the players get but one chance to deliver their solution. They go to the ghost at midnight and say, “Eustace did it,” and the ghost either ascends to the heavens or is trapped in torment for eternity. There’s nothing inherently wrong with such a high-stakes you get one shot at this adventure — some players eat that shit up — but it’s an unforgiving challenge that can frustrate folks. There’s no way, in that game, for the players to recover from missing a piece of evidence, drawing a wrong conclusion, or failing to spot a lie. Adding an Oona-like companion character to poll the players periodically and say things like, “That really doesn’t make sense; are you sure you didn’t miss something?” gives the players some margin for error and a chance to rethink things before they lock in their answer.

Don’t Mistake Mechanics for Purposes

Here’s a warning that’ll separate the True Scenario Designer wheat from the Mere Adventure Builder dross…

True Scenario Design is about finding unique, creative ways to fill your gameplay needs. Which is what makes it so hard to get it right. The temptation is always to find one-size-fits-all mechanical solutions to gameplay problems. We want solutions we can apply over and over again, every time the same problem arises. We call that “Building Tools.”

Consider the Ticking Time Bomb solution. Need stakes so every decision matters, even simple decisions about smashing doors instead of picking locks? Need to prevent Perpetual Adventures? Just add a Ticking Time Bomb to every adventure. You’ve heard that advice, before, right? Every adventure and every encounter needs a timer.

The problems are real. Ticking Time Bombs are a solution. But they’re just one of many possible solutions and they’re too specific and too constrictive to work in every Scenario. When you’re doing Scenario Design, your focus needs to be on this problem in this Scenario and finding a unique, creative solution that’s perfect for it. That’s hard to do, but it gets easier with practice.

That ain’t to say System Designers can’t help. A good System Designer must identify the likely gameplay problems that’ll arise based on their game’s genre and style of play and all that crap. And they should build tools to solve those problems — or help Scenario Designers solve those problems — without being so limiting and constrained they force the Scenario Designer to hamfist their designs. My Tension Pool and John Harper’s Clocks from Blades in the Dark are examples of good, general-purpose tools that solve common gameplay problems without overly constraining Scenario Designers. Compare them to the Ticking Time Bomb solution or something like Dungeons & Dragons 4th Edition’s Skill Challenges.

State Your Intentions

I’m going to make a giant-ass logical leap here and I don’t have time to connect all the dots for you. You’re just gonna have to trust this crazy assertion I’m about to make…

To properly Design on Purpose, you must first identify your Purpose, and second, Design.

Crazy, right?

I’m gonna keep coming back to that idea through this course. It’s pretty central to the whole Purpose-Driven Design thing. But today, I want to introduce the idea of a Design Statement. Especially as a first step in Scenario Design. Before you can design a Scenario, you’ve got to know what the hell you mean to design.

That might seem obvious, but it’s really easy to start with a very incomplete Design Statement and not even realize it. In the next lesson, I’m going to talk about the Anatomy of a Scenario. That’ll help make this shit a little clearer. For now, understand that, at the very least, when you sit down to do some Scenario Design, you must first describe the Scenario’s Goal, Starting Point, Outcomes Plural, and at least one Challenge. Usually the biggest Challenge.

What does that mean? It means that “The players have to kill a dragon,” is a woefully incomplete Design Statement. Instead, you need something like…

A village lies under the thrall of a dragon. The heroes arrive and the villagers beg them to defeat or drive off the dragon. The heroes must confront the dragon. If they kill it or drive it off, they save the village. If they fail to kill it or drive it off, the dragon burns the village in a rage and then flies off to find a new settlement to terrorize.

For every Scenario you design, you must state how it starts, the players’ goal, and the different ways it can end for good and ill. And you’ve got to have at least one Challenge in there. And, to really do it right, that’s all you want in a Design Statement. The more you bog it down with shit that goes beyond the minimum, the less room you leave yourself for actual design later. Writing a good Design Statement is about doing exactly the minimum. No more, no less.

Unstated Design Statements

I’ll let you in on a secret: Design Statements aren’t just for Scenarios. They’re for everything. Every element you put in your game — every character, every encounter, every reward, every scene, every random roll to determine whether the characters blunder into a hazard while they’re out dicking around the countryside — everything’s got a Design Statement. But that doesn’t mean you’re gonna write a paragraph for every game element. That’d be stupidly inefficient. For all the little shit, you’re gonna leave your Design Statements unstated.

The point is, everything in your game’s got to be there for a reason. If I point at the goblin encounter in Room 14B and say, “Why’s that there,” you better have an answer. Same if I ask you why there are random encounters in your forest or why there’s a town scene between your two dungeon delves.

That means that starting now, before you put anything — and I mean frigging anything — in your game, you’re to pause and ask yourself, “Wait, why I am even doing this?”

And now comes the part where I break your brains…

Game Design Über Alles Is Not Game Design Vor Allem

Let me ask you something: that dragon adventure you’re writing? Why are you writing that adventure? You could be writing any adventure. Why did you pick kill the dragon?

And that inn in the village? The one with the matronly only landlady who lost her sons in the war and so dotes on her guests in a sweet but obnoxiously cloying way? Why did you put her? Why is there an inn at all? And why’s it staffed by doting grandsmother?

There’s always a reason for the choices you make. Often, people go through their days making choices without really knowing why. Lots of folks will shrug and say, “I don’t know. I just kinda want to do a dragon adventure?” Or, “I guess I just thought she’d be a fun character.” And those are okay answers. They’re a specific kind of answer that I call a Tentpole Purpose.

I taught y’all that game design must rule over all, right? But that doesn’t mean game design always comes first. It just means that game design counts the most. It’d be ridiculous to say that every Scenario you design must be chosen by the needs of the game. The game doesn’t care whether it’s about killing a dragon or solving a murder. Generally, anyway. Sometimes it does. I’ll get to that.

There are lots of reasons to throw things into your game. For example, I mentioned Tentpole Elements. Tentpoles are elements you want to include because you want to include them. They’re often central elements you think are cool and want to build a Campaign or Adventure or Encounter around. A particular monster, a particular location, whatever. They’re called Tentpoles because they’re usually the flash-of-inspiration type things that get you excited to build a game off of.

Sometimes, though, you’ll need to build around a specific Goal. If your campaign’s about killing Beezlybub the Archdevil, you might need an adventure in which the players acquire the metal to forge the Devilkiller Greatsword. Or, if you’re building a heist adventure, you might need an Encounter about getting through the backdoor of the baron’s manse. Goals can even be really abstract. You might want to run an adventure about the heroes gaining the respect of the people of the realm. Or an adventure about killing a big honking boss monster. A good, old-fashioned kill quest.

This is where, by the by, I caution you not to give a single, solitary iota of crap about actually classifying purposes. Some of you — and I know you by name — can’t help but classify every damned thing. And you’re already trying to figure out the difference between building an adventure around the Goal of killing a boss monster and the Tentpole of slaying a dragon. Don’t worry about it. They’re different. But it doesn’t matter.

Sometimes you’ll have particular Narrative or Fantasy Purposes. Maybe there’s a story theme or plot development you need to build around. Like you want to build an adventure to highlight your setting’s corrupted nature or an adventure in which the villain’s motives are revealed. Or maybe there’s something you think your world needs. Hell, most of the shit you drop on a town map is there to ensure the Fantasy’s intact. A village has got to have a butcher, right?

And then, there will actually be times when you are driven by some Gameplay Purpose. Maybe you want to build around a particular mode of play — like an Exploration-based adventure — or a particular Gameplay need — like an NPC the players can check their answers with so they’re not stuck with one chance to solve the mystery and no way to recover from a mistake. As you follow this course, you’re gonna find yourself more clued into this Gameplay Purpose shit. It’s important. It’s the most important. But that doesn’t mean it always comes first.

Any Purpose is Okay, But Game Design Rules All

You can add any element to any game for any reason. And there’s actually good gameplay justifications for adding elements for Narrative and Fantasy Purposes. I’ll give you those justifications in a lesson or two. But anything you add must also serve some good from a gameplay perspective. And I ain’t talking fake internet morality good. “It doesn’t make the game worse,” doesn’t count. Good means more than not bad. Anything you add to your game must improve the gameplay experience.

I’ll be talking a lot about what that means for a lot of months.

This is why the first thing you do in Scenario Design is write a Design Statement. It doesn’t matter why you’re building the Scenario you are, but you must ensure you can turn it into a compelling gameplay experience. The Design Statement is a kind of sniff test.

Even when you’re working with smaller elements, though, it’s still important to pass the improved gameplay experience test. Hence, every time you ask yourself, “Why am I doing this thing,” you have to follow it up with, “Is this good gameplay?”

Game Design Über Alles

Designing on Purpose is about knowing why you’re doing shit and making sure everything you do makes for a better gameplay experience. And it also means spotting the gaps in your gameplay experiences and filling them in. It means recognizing the players have to know whether they won or lost and therefore you’ve got to build a grading system into your mystery Scenario. It means recognizing that, no matter how open your open-world game is, you’ve still got to clearly highlight the players’ goals and put them on course to complete those goals.

You’re gonna end up putting shit into your games purely for Gameplay Purposes. Did anyone ever tell you that every Encounter should advance the plot? Well, that’s a load of bullshit. Encounters can serve lots of purposes. They don’t have to advance the plot. But they do have to serve a Gameplay Purpose.

Piss and moan all you want, but if you’re running modern Dungeons & Dragons, you’ve got to chew up your players’ resources periodically. That sometimes means including Encounters just to include Encounters. And if you don’t want to do that, you have to recognize the Gameplay Need you’re leaving unfulfilled and find a different way to fill it. You can’t just shrug and say, “I can run my game however I want; I don’t care about adventuring days.” I mean, you can say that, but all you’re really saying is, “I can’t be assed to run a good game.” There’s something to brag about.

Economizing and Elegantifying

The best gameplay solutions — the best gameplay elements in general — do lots of shit at once. Oona from The Fall of Silverpine Watch provides the players a final grade on their mystery-solving prowess, but that ain’t all she does. She part of the adventure’s Goal, she provides Exposition, she teaches gameplay concepts, and she’s a Fantasy element so the players have an element of the world with which to interact. For a tiny, middle-aged halfling, she does a lot of heavy lifting.

When True Scenario Designers find unmet gameplay needs — as in, “I have a mystery and there’s no way for the players to check their answer” — the first thing most do is to look at existing gameplay elements for something that can carry that load. And after they’ve got their Scenario Design done, they’ll usually look for gameplay elements they can merge together. That’s because, in general, a Scenario with fewer multi-purpose elements is better than a Scenario with lots of single-purpose elements. You don’t invent a new NPC to give the players a clue when the butcher in town can do it just fine.

Of course, you can’t always do that. And it’s possible to overdo it. One villager can handle questgiving and exposition and grading and tutorializing and selling supplies, but that’s going to detract from the gameplay feeling of exploring a village.

But What If I Can’t?

Scenario Design is about identifying gameplay needs and finding creative ways to fill them, right? That’s one of the seventeen or so things I’ve said Scenario Design is about. But what if you can’t? What if, try as you might, you cannot find a good-feeling and sensible way to let the players check their answer to the mystery before locking it in? Or, at least, communicate to them whether they won or lost the adventure? What do you do then?

You throw the fucking adventure away and design something else because the one you wrote doesn’t work. That’s what you do.

If there’s a hole in the gameplay and you can’t find a way to fill it, you’ve got a bad game. Put it to torch and start fresh. There’s no shame in that. It happens. You’re not a bad Scenario Designer if you run into a problem you can’t solve. It happens to everyone. Except me. I’ve never thrown away an unworkable Scenario because of the perfectness that I am. But you’re not me. You have to hold yourself to the reasonable standard of a normal, mundane, mortal designer. Sorry.

Does this mean there are some adventures you just can’t build? Yes. It does. There are lots of things that just don’t work at the table. Labyrinths, for example, just suck in tabletop roleplaying games. I’m not saying some designer can’t find a way to pull it off, but the trick is finding that way. If there’s a way, I haven’t found it.

Likewise, if there’s a game element that isn’t serving a Gameplay Purpose in your Scenario, you gotta cut that shit out. You might think it’s not hurting anything, but it is. Remember, shit can exist in your world without appearing on camera and wasting game time. Villages need butchers, but that doesn’t mean the game needs an encounter with the butcher. Powerful dragons roam the wilds of the world, but that doesn’t mean the players have to meet them.

But recognize there’s a double standard here. If your Tentpole Encounter doesn’t work from a gameplay perspective and you can’t find a way to fix that, it’s got to go. And maybe the whole Scenario needs a rewrite. But if there’s an encounter that only exists for Gameplay Purposes — like a fight with rats because the game needs a fight and the characters are low-level — that can stay. It’s fine. It makes for a better game no matter how Story- or Simulation-driven you claim to be.

To Summarize…

I know I bounced around a bit and rushed through some things and left a lot of stuff for the next lesson and the ones beyond, so let me do my damndest to tie a neat little bow around today’s lesson.

Scenario Design means knowing what makes for a good gameplay experience and finding clever, creative ways to provide one. That starts with knowing what you want to put in your game and why. And it requires you to recognize that everything you put into your game must enhance the gameplay experience.

It’s important, therefore, to start every design by identifying your purpose in designing it and then describing the gameplay experience you mean to build around that purpose. At a minimum, this Design Statement must include the Scenario’s starting point, the players’ goals, the various possible outcomes, and at least one challenge for the players to overcome. Those requirements are the same whether you’re building an entire campaign or a single encounter. You won’t always write out your Design Statements, but they should always exist in your head.

The gameplay experience is your design’s sole limiting factor. Everything in your Scenario must serve a Gameplay Purpose even if you included it to serve some other purpose initially. If you can’t find a clever, creative way to make that happen, cut out that element. It’s got to go. Likewise, if there are any unmet gameplay needs in your Scenario, you’ve got to meet them. If you can’t find a clever, creative way to do so, scrap your design and make something else.

To summarize the summary… Scenario Design is a creative problem-solving exercise. It’s about finding clever, creative, unique ways to turn the shit you want to make games about into actual good games and about finding clever, creative, unique ways to plug the gameplay gaps in the games you want to make.

To summarize the summary of the summary… if you’re waiting for a checklist, formula, or step-by-step guide, you’re playing the wrong game. That shit’s for Mere Adventure Builders.