The surprise announcement that I was launching my True Scenario Design course really got you all pumped, huh? Of course, I knew that was coming. Half the e-mails, comments, and Discord messages I get lately end with, “I can’t wait for True Scenario Design!”

Well, your wait’s over. Kinda. This ain’t gonna be a quick thing. Just like True Game Mastery, True Scenario Designery is gonna be a year-long string of once-or-sometimes-twice-a-month lessons. And it’s gonna be splitting content space with True Campaign Managery, in case you were wondering.

But let me ask y’all this… what do you think True Scenario Designery is gonna teach you? Do you know what you’re actually all pumped up for? Do you remember what happened with True Campaign Managery? You were all really jazzed for it and then you found out it was all about hosting meetings, managing a social club, and resolving interpersonal conflicts.

You didn’t think about that, did you?

Well, today’s the day you find out whether this series is everything you’re hoping for or if it’s just another year’s worth of crushing disappointment. Because today’s the day I tell you…

Just What the Hell Is Scenario Design Anyway?

Today starts the third of my three-part master class in Tabletop Roleplaying Gamistry. This is the part lots of have been drooling all over yourselves for ever since I decided it was too big to cram hamfistedly into my True Game Mastery course. This is the start of True Scenario Designery.

As is the norm with any course of study — or any loosely interconnected series of articles pretentiously called a course of study by some dumbass who doesn’t want to admit he’s a glorified blogger and that people stopped reading blogs fifteen frigging years ago — as is the norm for any course of study, I’m gonna start by telling you exactly what I plan to teach you.

Actually, that’s half my norm. Because I’ve also made it the norm to introduce the philosophy that underpins literally every lesson I plan to teach. With True Game Mastery, it was Investment and Ownership, remember? And in True Campaign Managery, I built on those with Keep the Campaign Going Until You Decide It’s Over.

Well, I’ve already taught you this course’s underlying philosophy. Two weeks ago in the stealth prologue to this course, I taught you the True Scenario Designery Mantra. Do you remember it? That’s right: Game Design Über Alles. And do you remember what it means?

Game Design Über Alles: No matter what kind of roleplaying gaming experience you’re looking to provide and no matter what motivates your players, you’ll always get the best experience for yourself and your table by putting Game Design first and everything else second.

That’s the “You either buy it or you don’t” underpinning to this whole damned course. Do you disagree? Fine. I ain’t gonna fight you, but I ain’t gonna try to convert you either, and nothing in this course is likely to change your mind. And nothing in this course is gonna work for you. So feel free to go read some other blog. If you can find one. Maybe just go hang out on Reddit or YouTube or wherever the cool content creators are these days.

For those of you still here — all five of you — for those of you still here — hi Mom! — for those of you still — I’m just kidding; my mother doesn’t read this crap — for those of you — but she always seems to know when the effing Alexandrian has a new update — what was I saying?

Isn’t This Just True Adventure Designery

Let’s be real; I know why you’re here. You’re here because you think I’m gonna teach you how to build roleplaying game adventures. Or campaigns. Or at least, how to make encounters and monsters and combats and puzzles and shit like that, right? This is just True Home Brewery. That’s what you think, isn’t it?

Well,… you’re right. That’s what I’m gonna teach you. All that and more. Because True Scenario Design encompasses all of that shit. At least, it does when I say it does, because…

Words Mean What I Say They Mean

I don’t wanna do this, but I gotta…

Lots of people fight me over terminology. And dumbasses thinking language is prescriptive and flinging semantical arguments and trying to pin down overly restrictive, objective definitions and inventing their own terms and thinking those are real things with fixed definitions, all that shit really triggers me.

The problem here is that there’s not really any good language for talking about Scenario Design in tabletop roleplaying games. There are lots of ideas that need terminology just to make discussion possible, but there’s no single, universal, commonly accepted glossary of terms for this shit. Not even vague, descriptive, qualitative ones.

Don’t worry about why that is.

The point is, I’m gonna have to build my own lexicon here. I’m gonna need to assign terms to things. And I’m gonna do that how I think it’s best. And I don’t want to get bogged down in fights about the terms. It’s happened before. There was a whole, big-ass thing when I said, “Hey, I’m gonna use the word Scene to describe this structural, adventure-building concept…” and everyone wanted to let me know I chose a stupid word even though it absolutely did fit what I was talking about best.

Throughout this series, I’m going to assign words to concepts. And I’m using the words I like. The ones I think fit best. I’ll be stealing terms from the roleplaying game community, the board game industry, the video game industry, psychology, screenwriting, writing-writing, behavioral economics, or any other damned place I want. I will assign meanings carefully so that, at the very least, I’m not asking you to assign a totally opposite meaning to a term that intuitively means something completely different — I am really good at this — and I will absolutely always explain my meanings when I coin a term. I will always capitalize such terms for clarity. And if you’re ever unsure what I mean when I say something, all you have to do is ask. Politely. Just say, “Hey, Angry, what do you mean by Game Construct?” I’ll answer. I promise. I won’t even swear.

But we need some ground rules so I don’t end up tearing out anyone’s aorta. Because, believe it or not, I’m tired of spending hours in good-faith discussion trying to help someone run a better game only to get nailed with some pedantical nitpick because they don’t like a term I’m using even though I made it totally clear exactly what I meant. And because I don’t actually care what people think of the terms I choose. Seriously. There is not a word to express the infinitesimally tiny iota of a crap I have to give for someone’s personal opinion of whether my terminology is good.

The first rule is this: these are my words and my lexicon. If you’re talking outside of my community and you use my words, people may not know what you mean. And people outside my community may use these words differently. Be ye warned.

The second rule is this: my words are descriptive and not prescriptive. All definitions are imprecise and qualitative and there’s space around the edges. I know some of y’all still can’t handle the basic fundamental property of human language, but that’s a you problem. If you try to pin me down into giving a super precise, super objective definition, you’re just gonna get hurt.

The third rule is this: this is my native tongue. If you use a term I’ve coined and you’re talking to me — or talking in my community — I’m gonna assume you’re using the term the way I defined it. If you’re not, any resulting confusion is your fault and your problem. Maybe try explaining what you actually mean instead of flinging jargon at me. If you tell me, “Well, I consider this term to mean this, not that thing you said,” you’re just gonna get hurt.

The fourth rule is, I don’t care if you don’t like my terminology. Try to fight me on my choice of terms, you’re just gonna get hurt.

In my classroom, common room, and office, we talk about ideas. We don’t get bogged down picking over word choice.

And for those of you who’ve never picked a fight with me over word choice or said, “Well, when I say this, I mean that even though you made it very clear you were talking about that and not this,” I’m sorry you had to sit through that. I’m saving myself some trouble later. Trust me.

And now…

Okay, But This is Just True Adventure Designery, Right?

Let me reassure y’all right now that this is indeed just True Adventure Designery. If you’re hoping I’m gonna teach you how to design amazing tabletop roleplaying game adventures — especially fantasy adventures for games like Dungeons & Dragons — you’re not gonna be disappointed. Well, you might be. But that’ll be down to my terrible execution or your terrible implementation and not my subject matter.

So why am I calling this True Scenario Designery? Because that term better encompasses everything I plan to teach you and neatly excludes most of the shit I don’t intend to cover.

See, Adventure Design is just one part of scenario design. Scenario design includes Campaign Design and Encounter Design too. Scenario Design is totally scalable. And Scenario Design includes a bunch of other stuff too. But that’s a story for another day.

What I ain’t gonna spend a lot of time on is the pure mechanical shit. Because this is very much high-level design here, I’m not gonna spend a lot of time on the actual mechanics of building and balancing encounters or how to stat up custom monsters and traps. It’ll come up and I definitely will talk about how to make proper use of whatever tools your system of choice gives you to bring your designs to mathematical life, but we ain’t getting into the statistical weeds.

Don’t take this as a way of being all system agnostic and avoiding Dungeons & Dragons. My content is still about the sort of fantasy adventures that Dungeons & Dragons does best and is best for doing. This is still a Dungeons & Dragons site. I’ll always be assuming Dungeons & Dragons. But I ain’t getting into the nuts ‘n’ bolts math.

See, as with my previous True Whatever Whatevery courses, you — my student — are supposed to know what you’re doing. You should know how to use the instructions in your Game Mastering Guide or Dungeon Master Toolkit or whatever to make an encounter or build a trap or assign a Difficulty Number to a task. If you’re here for better encounter-and-monster-building tools, I already built those. They haven’t gone anywhere.

Likewise, you should know how to smash your game’s bits together to build a perfectly serviceable, adequate, playable adventure. If you’ve never done that, you ain’t ready for what the Angry is cooking here. Go build some crappy adventures and run them. Then come back. And if you’re looking for basic instructions, I’ve already published those too.

And really… that’s such a good explanation of what this course is and isn’t that I could totally get away with stopping there. But I ain’t gonna. Because the difference between a Mere Adventure Builder and a True Scenario Designer starts with understanding what Scenario Design is really about. And that starts with understanding the Game Master’s relationship to the game.

Buckle up kids… we’re going into overtime. This is going to be long.

Systems and Scenarios and the Game Masters Who Love Them

Considering roleplaying games in terms of the play experience — which is the only correct way to consider them — it takes three people to get a game to the players. And, remember, a game’s not really a game until the players are playing it.

First, there’s the System Designer. That’s whoever builds the ruleset. They’re the ones who write books with names like Dungeons & Dragons and Pathfinder on the cover. The rulebooks and supplements. And while systems like Dungeons & Dragons claim to be games, they’re really not. You can’t just bring your rulebooks to the table and start playing. And that’s because the rulebooks contain the game’s engine — the rules for how shit works — the game’s components — stats for monsters and player characters and magical items and shit like that — and often — but not always — instructions of widely varying quality about how to assemble the rules and components into gameplay experiences.

This ain’t news to anyone who’s been here a while. But it’s important I review it for context, so calm your tits.

Third, there’s the Game Master. The Game Master brings the game to life. They describe the world, present the challenges, portray the characters, and use the rules to resolve the players’ actions. I really hope you all know this shit already. Please tell me you do.

Now, you might have noticed I skipped an ordinal. That’s because there’s a huge-ass gap between the System Designer and the Game Master. I mean, hypothetically a Game Master could come to the table with just the core rulebooks, some dice, and some paper and spin out a game. Some game systems even facilitate that kind of thing. And some Game Masters think that’s the only way to really run a roleplaying game. But modern medical science can’t regrow missing brain lobes so those folks are beyond our help. Let’s not speak of them.

That approach — just assembling a game on the fly from the rules and the players’ actions — has problems. It’s very taxing for one thing. But it’s also wholly reactive. And the Game Master can’t really see more than a few moves ahead. This means they can’t really put good Game Design first. Game Design is a very holistic and top-down kinda thing. You need to work with the whole picture. And since we — in this classroom — know good Game Design is the single most likely path to the best gameplay experience you can have — for any definition of best gameplay experience — that means the assemble-as-you-play approach is just voluntarily running a less great game.

Enter the Scenario Designer. They sit between the System Designer and the Game Master. At its very simplest, the Scenario Designer’s job is just to assemble the Game Systems rules and bits and crap into something the Game Master can more easily run at the table. For a very simple example of the bare minimum Scenario Design, consider the practice of Shortlisting.

Say you wanted your players to explore a goblin forest. But you’re one of those absolute whackjobs who rely entirely on improvisation because of your delusions about true open worlds and total player agency or some other horseshit like that. What would you do? You’d probably scour your game’s various resources before the game and at least come up with a list of appropriate shit to populate that goblin forest with, right? Even if you were just going to pluck out whatever felt right in response to whatever the players did, you’d still not want to wade through literally everything the game’s got to offer at the table, right?

That, by the way, is what Encounter Tables are. They’re just shortlists of game components deemed appropriate for use in the current game. Their main function is just to keep the Game Master from having to know every option that exists at all times and to flip through multiple hundred-page books to find the one they want.

By the Power of Game Design…

Now, let’s take this a step further. The Scenario Designer’s position between System Designer and Game Master empowers them with options neither of the others have. System Designers can only build rules and components. The Game System is an Engine. It’s got to provide lots of different potential gameplay experiences. Meanwhile, the Game Master has to work on the fly, so their ability to do anything more than react to developments in the game is limited. They can do some planning ahead, but they’re usually stuck working in the short term.

Meanwhile, the Scenario Designer can build specific gameplay experiences for specific audiences — which might be one, personal gaming group, or the entire mass tabletop roleplaying gaming market — and they can work with the entire gameplay experience as a whole and they’re not under the time pressure of having to run the game as they build it, so they can apply good Game Design principles.

Consider one simple example: Setup-and-Payoff. That’s when players glean information about a future challenge or game event or plot development or whatever. It’s a good thing to do for a lot of reasons. There are lots of ways to do it and lots of ways to use it.

System Designers can’t really do much Setup-and-Payoff though. Why? Because they don’t know what specific things are gonna happen in any specific game. They can give advice about how to set shit up and what shit is probably a good thing to set up, but they still need the Game Master to figure out the specifics and implement it. And Game Masters certainly can do the Setup-and-Payoff thing. But it requires them to decide in the moment that some future thing is going to happen, decide how to set it up, and then remember to pay it off later. For a Scenario Designer, though, Setup-and-Payoff is really easy because you can build the Setup and the Payoff at the same time and just tell the Game Master what to do when they get to that part.

Thus a Scenario Designer is really the only person in this process who can truly access the full power of Good Game Design.

Never Wear a Hat on a Hat

I talk about System Designers and Scenario Designers and Game Masters as if they’re totally separate people — and also sometimes as if they’re individual people instead of teams or groups — but it’s important to remember that these terms refer to roles or jobs or functions. They ain’t people. Often a System Designer will also do Scenario Design, such as when a game publisher’s design team writes adventure modules for their game. And Homebrewers — who are Game Masters who write the adventure content they run for their specific groups — are both Scenario Designers and Game Masters depending on when you’re looking at them.

You can think of jobs like hats anyone can wear. As long as you don’t think of them too much like hats. Because they are different roles. Different jobs. And you never wear a hat on a hat.

Sometimes a Scenario Designer has got to build some game mechanics because the Rules System is insufficient for whatever they’re trying to do. They’re not doing System Design. They’re just patching a hole. Same with Game Masters who improvise encounters because their players do things the Scenario Design didn’t account for. Or who has to make a judgment call because the rules didn’t account for whatever just happened in the game.

This is part of the open-ended, freeform nature of roleplaying games. The people closest to the players often have to account for shit the players did that the design couldn’t account for. In fact, it’s one of the selling points. And dumbasses who prattle on about GM May I are dumbasses for precisely this reason.

But this does not make a Game Master a Scenario Designer or make a Scenario Designer a System Designer. It’s just the person in the best position to plug a leak plugging that leak.

Other Duties Unassigned

I’d be remiss if I didn’t mention the slew of other hats involved in bringing a game to the players. And I can’t even tell you how many hats there are. Because you can put lots of things in lots of hats. Different companies and different industries have different hat collections. It’s not really useful to argue about what goes in what hat because these hats are all secondary jobs that System Designers, Scenario Designers, and Game Masters tend to share around. Whoever’s in the best position to do them just does them.

In roleplaying games, we talk a lot about world-building or World Design. That’s a kind of writing that often rubs against Game Design. On a surface level, it’s just writing the fictional world’s fictional rules and history and backstory and all that crap. But it can encompass a lot of shit that can affect Scenario Design. Like, ecology, for example, which tells you which creatures are found where. Or society and culture, which can affect, for example, what temples and services and goods might be found by players in a given city.

There’s also writing, story, or Narrative Design. That’s basically writing the fiction about the game’s events, but there’s also a lot more to it. Things like the order of events and the motivations you provide for your characters will determine whether your gameplay experience also provides a satisfying narrative experience.

Then there’s a thing I’m calling Component Design. That’s somewhere between System Design and Scenario Design and it’s about building all the little game bits and pieces like spells and monsters and feats and classes and magical items and traps and literally any other Game Component that can possibly exist. Component Designers fill the pages of the Monster Manuals and the class and race and feat and spell chapters in the Player’s Handbooks and write most of the splatbooks.

As far I understand their byzantine organizational horseshit, Wizards of the Coast lumps all of this under Development. Developers are the ones who build all the monsters and provide all the worldlore and story details and basically, everything else that isn’t deciding what die to roll against what number and what stats every monster has to have and where they should average. Designers decide how magic works as a game mechanic and Developers explain how it works in the fiction of the world. Or they don’t effing bother. Because 5E just does not give a shit whether Game Masters and Scenario Designers know how the fictional world works.

Game Design Über Alles… Again

Do not misunderstand or misquote or fight me here. I am not saying Narrative Design and World Design don’t matter. They do. A lot, actually. In tabletop roleplaying games, they fill a very important game design need I’ll discuss more in a future lesson. But, they also serve the Game Design.

What does that mean? Consider that whole Goblin Forest thing again. You’re trying to build a Shortlist of Game Components that’ll make for a fun goblin-forest exploring gameplay experience, right? As you — you’re a Scenario Designer now — as you work through the pile of all the Game Components ever, you’re considering — first and foremost — what’ll lead to good gameplay experiences. You won’t include, for example, a 20th-level forest dragon because you know it’ll just brutally slay the players’ characters. And you won’t include any squirrels because they won’t even give the players pause. Probably.

Are you also parsing out shit that doesn’t belong in goblin forests from a World Design standpoint? Of course you are. You won’t include polar bears and lava dragons. And you might even limit yourself to just stuff that’s tagged for the Forest Biome or whatever if your game includes such helpful tags. But what you won’t do is put that 20th-level forest dragon on the list just because it belongs to the right biome. Game Design can veto anything.

Interestingly though, neither World Design nor Narrative Design have the same veto power.

Let’s say, for example, you spot the swamp ogre. And you realize it’s got some really cool abilities that synergize with the goblins you’ve already Shortlisted. You know you can build a good, fun gameplay experience by pairing them up. It’s a good Game Design choice.

If you’re a True Scenario Designer, you’ll probably find a way to square the good Game Design choice with the World Design or the Narrative Design or whatever else is throwing an error code. You might add a swampy bog to your forest and put the goblin camp on the edge. Or you might reskin the swamp ogre to make a forest ogre. Or you might build your own forest ogre inspired by the swamp ogre. Or you might add a whole backstory about the goblins being driven from their swampy home and then use environmental storytelling to reveal the goblin’s tragic backstory.

That’s the essence of Game Design Über Alles. You never compromise on the Game Design, you put everything else second to it, and when there’s a conflict, Game Design always wins.

And for those of you still throwing an effing conniption about your 20th-level forest dragons that totally belong in these forests? You can do it. You just have to find a good Game Design way to do it. You can’t let a low-level party of modern Dungeons & Dragons characters run into a 20th-level forest dragon. Because if the players don’t immediately assess the threat as “too damned powerful” and formulate and implement perfectly an escape plan, the characters are just frigging dead. That’s not a creative problem-solving challenge. It’s just throwing the characters in a blender and hoping the players recognize the predicament and roll well enough for their characters to climb out before you hit puree.

Such an encounter must be designed very carefully to create a fair, creative problem-solving challenge. And that design must account for the fact that roleplaying games are really open-ended and that players are often slow to recognize their predicament and can sometimes make stupid choices. Thus when the stakes are high, players need lots of information, enough time to reach the proper conclusion, and a few different ways to recover from a bad choice before it’s a permanent loss. Such an encounter is an extremely high-stakes situation. If it goes bad, it can end a campaign and frustrate your players to the point where they don’t trust you to run games anymore. Or, at least make them so cautious that they play their characters like porcelain dolls, and the heroic, fantasy element is just gone.

What Does a Scenario Designer Design?

I know I’ve been running my noise-hole for a while and I know this is all boring, introductory, conceptual bullshit and I know I’m still harping on the same fight I’ve been having with dumbasses for the past three weeks, but I really do think it’s important for you to really grok the Scenario’ Designer’s role here.

Meanwhile, I don’t want any of you walking away saying, “Okay, but what, actual, practical shit will I be designing? I get that I’m sitting down with the Game System and doing some Game Design Magic and then I’m handing the Game Master something. But what actually is that something?” That’s a very practical question and, whatever else I accomplish with my True Whatever Whatevery courses, I want to provide practical, useful, actionable shit. So I’m gonna try to answer that question. And then I’ll let y’all go for the day.

The Scenario

From now on, I’m using the term Scenario to describe whatever the Scenario Designer hands the Game Master from which to run a game from. I may talk later about adventure modules and campaigns and encounters and all that shit, but for now, all that matters is that Scenario Designers hand Game Masters Scenarios and Game Masters…

The Game Master’s Role… Again… For Reals… Maybe

Let’s talk for the thousandth time about what a Game Master actually does. And let me change the definition — or at least extend it — for the thousandth time.

Above, I said that a game’s not a game until the players play it. But that was a filthy effing lie and we all know it. Games don’t need to be played to be games. My board games don’t stop being games when I close the box and put them in the closet. I don’t have to touch them to make them games.

But a tabletop roleplaying game is not a game until a Game Master runs it. I have a really good, very detailed, kinda complex reason for saying that. A reason that’s grounded in solid game design principles and which has actual, important, practical ramifications for how tabletop roleplaying games are — or should be — designed. It ain’t just semantical philosophy. But I don’t have the word count to make it and it mostly doesn’t matter for today’s purposes.

The takeaway that does matter is that it’s the Game Master’s job to turn whatever shit they’ve got — rules, components, supplements, stat blocks, notes, maps, vague ideas, etc. — into a game. Because all that shit is incomplete. Game Masters never sit down with complete games to run. There are always vital components — necessary things that make games games — missing from whatever the Game Master brings to the table.

If you want to grok how this can be, think about video games. In the Matrix code that makes video games work, there are computer instructions that tell the TV what to draw on the screen and how to read the player’s button presses and translate them into game actions. In roleplaying games, it’s the Game Master who draws the world and parses controller inputs. Because the Game Master describes the world and resolves player actions.

Now, this is just an analogy. It’s imperfect and it’s incomplete and it’s a gross oversimplification. It’s just a way of seeing the Game Master as part of the game itself. The final component. The graphical display and user interface. And this ain’t semantics either. A game with shitty graphics that keep you from seeing what’s going on is unplayable. Likewise, if the Game Master can’t adequately describe the world so players can make reasonable choices, that game is unplayable.

The more detailed tools you hand the Game Master, the better off they are. Kind of. If you give the Game Master boxed, narrative text, you ensure they’ll draw the world properly. Kind of. And if you give them good rules for resolving player actions, you’ll help them resolve actions properly and fairly.

But there’s a whole other level to this that goes beyond graphical-processor-and-controller analogies.

At some point, every decent Game Master realizes they could run a roleplaying game from nothing. No rules, no maps, no plan, no screen, no dice, nothing. Most Game Masters wouldn’t want to, but they realize they could. And the quality would swing wildly. Imagine giving ten Game Masters each five players and some blank paper and four hours to run a game. You’re gonna get fifty very different player experiences and there’s gonna be a crazy quality disparity.

But there’s an advantage to letting Game Masters run games — and giving them some freedom — that a video game console or a predictive AI chatbot or a pick-your-path book just can’t match. A decent Game Master can provide a consistent, logical, open-ended play experience. And, from a practical standpoint, this basically amounts to two things. First, Game Masters can do on-the-fly error handling. If something goes wrong in the game’s code or the players discover a game-breaking exploit or bug, the Game Master can spackle over it and keep the game going. The game doesn’t have to crash. Second, if the players end up doing something that isn’t coded into the game, the Game Master can invent new content that’s reliably consistent and follows logically from all the preceding actions and maintains the game’s consistent tone and provides a similar quality of gameplay experience to the preexisting content. Hell, a good Game Master can even use Game Design techniques to steer the game back to the preexisting content without ever having to say, “No.” Or, better yet, without the players ever noticing it happened.

The point is that, whatever crap the Game Master brings to the table, they’re responsible for making a game out of it. However incomplete it may be, they’ve got to finish it. On the fly. And they’ve got to do any error handling and system patching necessary to keep it running. And if it goes off the rails, they’ve got to invent new content that maintains a consistent gameplay experience.

Believe it or not, that’s actually kind of hard to do. Games are complex things and Game Design is a complex art and tabletop roleplaying games are especially complex. It’s one thing to get an adequate, passable, fun, dicking-around game, but to get a truly artful gameplay experience that consistently wows your players? That’s something else. Doing it off the cuff is almost impossible. And no, you’re not the exception. Sorry.

So what the hell does a Scenario Designer hand a Game Master? Whatever the hell they have to.

Finishing the Game as Much as Possible

Game Masters have to turn incomplete games into complete games. They’ve basically got to finish making the game while they execute the damned thing. And the more incomplete the game when they sit down, the harder it is to complete it. And complete it well.

So, what does a Scenario Designer hand a Game Master? They hand them the Completest game they possibly can. A Scenario Designer is actually a game designer. And they’re trying to get that game as close to complete — and good — as possible so the Game Master can just kind of, you know, finish making a game of it.

Now, the word Completest — which I am shocked to discover is actually a word according to my spell-checker — the word Completest is tricky and it needs ten thousand asterisks. If the Scenario Designer is trying to deliver a dungeon crawl for a modern adventure-of-the-week D&D campaign, it’s easy to make a pretty complete one that’s relatively free of gaps. But, if the Scenario Designer is providing a character-and-faction-driven, narrative-focused intrigue game for a group of player-characters with preexisting relationships with the various factions, the Scenario is gonna lean pretty heavily on the Game Master’s improvisational skills. Of course, a good Scenario Designer will recognize that and then arm the Game Master with lots of tools to help them improvise and build content on the fly.

It’s like this: if I — a True Scenario Designer — know an encounter’s gonna be a fight, all I need to provide are combat stats. There’s always a chance some random party might not bite on the fight and might try to talk their way past the monster and the Game Master will have to handle that, but it’s a low-probability and low-stakes event so I can just trust the Game Master to handle that shit at the table. But if, due to the complex nature of the faction-and-character-driven gameplay experience I’m building, I have no frigging clue whether the players are going to be fighting with or talking to or robbing or sneaking past Aloysius Cromblefitz, Third-Level Wimbledorf of the Order of the Jade Seven-Toed Sloth, I’ve got to make sure the Game Master is prepared to handle all that shit or else I’m just not doing my Scenario Design job.

The point is, that what physical form a Scenario takes and what information is included therein depends entirely on what that Scenario is about and what the Game Master needs and how much the Scenario Designer wants to lean on the Game Master and who the Game Master’s players are and on and on and on. If I’m my own Scenario Designer and I just need to make a trek through a forest interesting to get me through tonight’s session, I can hand myself some scribbled notes and put some sticky flags on some stat blocks in my Monster Manual and call that Scenario Design. If I’m writing a six-month hardback adventure path for publication by a major gaming corporation, I’m gonna need to provide a bit more than that.

Part of being a True Scenario Designer is knowing what you’re building, who you’re building it for, and what they probably need to make a game of it.

But the goal — and the practice — of Scenario Design doesn’t change. You’re trying to give the Game Master — who might be you — as complete a game as possible. To anticipate what they need to make that game happen and to deliver it. You’ll never do it perfectly — and you kinda don’t want to — but you should always aim for perfect. If the players can do whatever they want to do and the Game Master always has the right tool to make it happen already in front of them, that’s a perfect roleplaying game session.

Your goal, as a True Scenario Designer, is to do your damnedest to give your Game Master that perfect session.

But… really…. this shit’s just Adventure and Campaign Design with a fancy name.

Class dismissed.