This month, I’m getting this Bullshit out of the way early. Mainly because it’s a short, holiday week and I’ve got a wedding to attend. But also because I’m hoping all that Macrochallenge bullshit is still fresh in all y’all’s minds and I really want to reopen that can of worms again.

I just never learn, do I?

Don’t worry, though. I ain’t trying to re-explain that shit a third time even though I’m still getting nonsensical questions like, “What would be a better Macrochallenge around which to build a fantasy adventure roleplaying game?” and “No, but really, just tell us the list of Macrochallenges so we can pick our favorites.”

If you don’t get it at this point, you don’t get it, and I can’t fix that. I’m sorry. And I’m further sorry you’re not gonna get much from this article. Which means I can look forward to more pointless arguments about how I use my terminology. Because that’s what I’m talking about today. I’m talking about my personal lexicon. The way I talk about Scenario Design to myself. And how that terminology’s informed by my understanding of Macrochallenges in Scenario Design. And why Scene is the best word to use for the thing I use it for.

That’s right, I’m defending the way I use the word Scene.

And, look, this ain’t just me trying to prove myself right and end some dumbass argumentative feedback I’m still getting about that shit. Though that is a side benefit. This shit might actually help some of you advanced — and open-minded — Game Masters build better adventures before I get to the Scenario Design portion of the True Game Mastery series sometime in… hell, it’ll probably be December before I get there at this point.

What? The Angry GM is Evolving?

Years ago, I wrote this article about designing kickass Encounters. An article I ain’t linking to. Because, man, did I ever get that crap wrong. I mean, I was right at the time, but I’m way more right today than I was then. Though truth be told, I haven’t changed as much as y’all seem to think I have. It just looks that way because of nuance.

Seriously, lots of you think I’ve changed a lot. I haven’t. I’ve just refined my techniques. And my understanding of things. I’ve found better ways to do the same shit I’ve been trying to do this whole damned time.

But I digress…

In that article I won’t link, I claimed an Encounter was a chunk of gameplay defined by an unresolved Dramatic Question. And that Dramatic Question was the result of a Conflict between the game’s protagonists and some External Force.

Basically, you could define an Encounter as gameplay to find out the answer to a question like, “Will the heroes make it safely through the spider’s lair or will the spiders paralyze them, liquefy their innards, and lay eggs in their eyeballs?”

I went on to say that a Scene was just an Encounter that lacked an External Conflict and thus lacked a Dramatic Question.

In other words, if you’re trying to force your way past an uncooperative guard, that’s an Encounter. But if you’re just shooting the shit with the guard or receiving a question or getting exposition-dumped by the guard, that’s a Scene.

In a Stealth patch a year later, I quietly changed my definitions. Most folks didn’t notice the change and inferred from context clues that I’d started using the word Scene to describe a whole, different concept, but a few remarked on the change and forced me to explain.

So I did.

I explained that it really wasn’t as important as I thought to distinguish between Interactions with Conflict and Interactions Sans Conflict and that the word Encounter was good enough to describe any and every interaction between the player-characters and the game’s world. And meanwhile, the word Scene was much better suited and infinitely more usable as a Scenario Design term.

I kept using Scene as a way of subdividing adventures despite many, many objections. Because I shit you not, there were objections. And while I put some of that down to gamers just naturally getting overly worked up over really stupid shit — as is the nature of gamers — I did kind of get the objections. Kind of. I mean, I myself had made a really big deal about the importance of Dramatic Questions and Conflicts when designing Encounters. So much so, that some of my students made it a central feature of their early encounter designs before building amazing toolkits of their own and then becoming massively successful independent content creators themselves.

Congratulations, by the way, on your amazing success Kelsey and everyone at The Arcane Library.

Anyhoo… I recently started this fight back up with a long-ass discussion about how Encounters aren’t really things. How Encounter is just a fancy-pants way of saying “the start of an interaction.” And while I know that seems like a giant departure from the Ancient Lore of Angry, it really isn’t.

As expected, lots of you let me know I was totally wrong now and I was totally right then and my saying that Encounters were things with Dramatic Questions totally changed your life and also it was muey importantito to distinguish between Encounters and Scenes. For reasons.

And that brings us to the present day. And between all that True Game Mastery crap and the stuff I posted about Macrochallenges, I can finally explain why Scenes are what they are, why they ain’t Acts, and why none of this matters when you’re running games.

The Change

I haven’t changed as much as you think. I know the crap I’ve been saying lately seems to contradict stuff I made giant, swear rants out of years ago. It doesn’t. And while there has been a change in me, it’s a small one. It’s really just about perspective. And I’ve even told you what it is a few times these past few months.

Game Masters are not Game Designers.

Long ago, I claimed that running games entailed making lots of decisions that are very similar to the kinds of decisions Game Designers have to make. And that ain’t wrong. But making a few one-off game design decisions does not a Game Designer make. Especially because Game Masters make their decisions way differently and in a different context from Game Designers.

Game Masters indeed make a lot of judgment calls when running games. They’ve got to decide how to hand the rules and when to use, overrule, or change the rules. They’ve got to decide how the world reacts to the characters. And they’ve got to decide when to add, remove, or modify encounters. If a tabletop roleplaying game was a computer game, all that crap would be preprogrammed by some Game Designer in advance. Specifically, a Scenario Designer.

Here’s the thing: when a Game Designer makes those calls, they can take all the time in the world. Within reason, of course. And they get to iterate, test, and tweak all they do. They can also rework the whole design around the choices they make. They get to see the entire big picture. Which means they can optimize the hell out of every design choice.

You, a Game Master, on the other hand, have just seconds to sort your shit out at the table. Even if you’ve got a perfect grasp of the big picture — both in terms of Scenario Design and Engine Design — you’re making your calls in the middle of the game. So you can’t redesign all that shit on the fly. And you sure don’t have the time you need to work through the consequences — intended and other ways — of your call and all the weird interactions that’d arise from your tinkering. And you can’t test, tweak, or iterate. At all. You get one chance per choice to get it right.

What I’ve been desperately trying to get through your skulls is that, if you approach running your game like a Game Designer — if you think and tinker too much — you’ll always run a slower, shittier game. And that’s true even if you’re awesome at Game Design.

When I said, Encounter is just a thing you present and resolve and nothing else, that’s what I was saying. As a Game Master, that’s all you can do. So shut off your brain, trust your gut, and keep your game moving. You will do infinitely more good for your game that way.

Game Master, Campaign Manager, and Scenario Designer

It’s a standardly accepted aphorism now that Game Masters wear lots of hats. But I think that’s actually a useless thing to say. Or at least, I think most people miss the point of saying it. It is that people who choose to run tabletop roleplaying games end up doing lots of different things and using lots of different skills, but I don’t think it’s useful to say that’s what Game Mastering actually is. Or maybe, it’s okay to say that’s all Game Mastering, but then we need another term for actually sitting at the table and running the game.

For my money, Game Mastering is sitting at the table and running a game. It’s presenting situations and adjudicating outcomes. And it’s also all the pre-game and post-game Prep. It’s reviewing your adventure notes, and your previous session’s notes, and gathering resources for your upcoming session. And it’s scribbling notes about the session that just happened, doling out experience points, and doing whatever other bookkeeping your game requires.

That’s Game Mastering. Everything else isn’t.

For instance, if you’re running more than a single Scenario or Adventure Path or multipart adventure hardback or whatever, you have a bunch of extra shit to deal with. You’ve got to keep detailed track of how the world evolves. And you’ve got a lot more administration and player management bullshit to handle. Sure, Game Masters run into that shit sometimes — there’s overlap — but they handle it like firefighters. They douse the problems as they arise and move on. Because they just need to get through each session. But Campaign Managers have to keep a game going for months upon months. Or even years. And thus, they need long-term campaign tracking, player management, and scheduling strategies and they’re a lot more likely to deal with intra-player conflict.

Then, of course, there’s Scenario Design. Building Encounters and writing adventures ain’t prep work, though I know some of you call it that. Prep is how you get ready to run a game after you’ve designed the Scenario. Or someone else has. What you’re doing when you make your adventures is Scenario Design.

There’s also Game Design — or Hacking — which is a whole, different thing altogether. But I’ve covered that.

And that’s why I don’t think it’s good enough to chuckle and shrug and say, “Game Masters wear lots of hats.”

First, every Game Master has got a different set of hats on the rack. The vast majority of Game Masters are totally happy to run published adventure paths and WotC’s honking hardback super-adventures these days. They ain’t doing any real Campaign Management or Scenario Design to speak of. Other Game Masters buy wodges of short adventures on sites like DTRPG and stitch them together into Campaigns. Those folks are actually Managing Campaigns, but they ain’t writing their own Scenarios. They’re just tweaking here and there to get the adventures to fit together. Some Game Masters — like me — run long-form, homebrew campaigns for months or years. They’re doing it all. Hell, there are even Scenario Designers and Game Designers who really only run games to test their own creations. They ain’t doing a whole of Game Mastering because you don’t want to make too many judgment calls in playtests and they ain’t Managing Campaigns.

Every hat’s got its own goals, priorities, and concerns. And they often conflict with each other. Each hat must be worn in the right context. Bog yourself down thinking like a Scenario Designer when you’re Game Mastering and you’re going to trip over your damned self and drop your game all over the floor.

That’s the spirit in which I wrote Stop Hacking. I wasn’t saying you’re too stupid to design games and you should stay in your lane. I was saying pick a hat and get really good at wearing that it before you try on another. Or maybe don’t wear a hat on a hat.

In that context, maybe the hat analogy is a good one. Because you can’t wear more than one hat at a time and some hats fit better than others and you don’t ever want to wear the wrong hat to the wrong gig.

Compartmentalize.

From a Game Design — and Game Mastering advice-giving — perspective, I’ve come to realize that each hat requires different tools, different materials, and a different mindset. This is why I’ve been using the True Game Mastery to clean up and reorganize my advice. It ain’t that I no longer believe what I said about Encounters five years ago; it’s just that I only believe it when I’m wearing the right hat and you shouldn’t worry about it unless you’re wearing matching haberdashery.

I’m divvying up the advice. Putting it in different columns.

And that is why I am firmly reclaiming the word Scene and stuffing it in the Scenario Design hat. It’s really useful there. And having it there also helps Game Designers and Advice Givers immensely.

… And Scene

Attentive, long-time readers know I’ve been using the word Scene as a way of breaking down my Scenarios into smaller chunks. And yes, I’m gradually and deliberately shifting from the word adventure to the word Scenario. At least when I’m talking specifically about designing roleplaying game modules, adventures, and the like. I’ve been rewiring your brain for a while now. Just let it happen.

I divide my Scenarios into Scenes. And you’ve probably inferred through context that Scenes are some combination of narrative subdivision and containers for encounters. That ain’t quite it, but I haven’t had the language to explain it until now.

Scenes are chunks of Macrochallenge. Scenes represent challenges that are bigger than overcome the Encounter in front of you. I while ago, I mentioned this adventure I ran wherein the players had to get a bunch of lumberjacks at a camp to trust them so they’d give the party resources and information? There were a bunch of little, individual Encounters in there — fight this, escort that, fetch the other, whatever — that added up to the players gaining or tanking reputation. And that whole reputation game was part of the Scene.

In my lexicon — the best lexicon — a Scene is a Location plus a Macrochallenge. Scenes have goals, usually involve conflicts, and they take place in defined settings.

Building Scenarios around Scenes is a lot easier than just building blank-page Scenarios. And using Scenes as elements of both Setting and Macrochallenge ensure I’m always thinking in terms of Macrochallenges. And that makes even simple adventures richer and deeper than they’d otherwise be.

Even a simple dungeon delve Scenario comprises three Scenes at my table. In Town, the party gathers information and resources. Crossing the Wilderness, the party treks across the trackless land, trying to hold on to as many resources as possible. In the Dungeon, the party tries to do whatever the hell they set out to do in the first place.

Scenes are powerful, versatile elements of Scenario Design. Consider, for existence, a branching path wherein the party can either trek through the Forest of Death or Breakleg Hills to reach the dungeon. I design each of those locales as a separate Scene with specific challenges, random complications, and even special mechanics if I need them. This means I can design them mostly in isolation and worry only about the shit — like resources, reputation, alarms raised, or whatever — that passes from Scene to Scene at the Scenario Design level.

Breaking Scenario Design into Scenes also lets me consider the design in a more sophisticated way than I otherwise might. I can think of Scenes in terms of their structure — open-ended, branching, linear, whatever — and design each as a sort of mini-adventure unto themselves. And design only what I need for the Scene at hand. That In Town Scene? It’s very open-ended. The players can wander wherever and interact with whomever they want. They can leave whenever they want and even return to the Scene later. There’s no central conflict, just an opportunity to gather resources and information. This means I need a map with a lot of named locations that hint at useful resources and a few random complications that make resource-gathering a little harder.

This Macrochallenge shit? It ain’t just about adding an element of challenge beyond win all the fights. Games are at their best when several Challenges are running at once and they sometimes come into conflict. Take, for example, D&D’s Attrition-Based Macrochallenge which is basically about having enough resources to win. Being as stingy and efficient as possible. It pulls against the Survival-Based Macrochallenge sometimes when players have to choose to spend valuable resources to increase their odds of survival or take bigger risks to conserve resources. Did you think Attrition and Survival were the same goal? They ain’t.

Scenes add other, different Challenges to the mix that all contribute to the overall victory and force the players to set priorities and resolve conflicts between their goals. On a highly abstract level, for example, a scene In Town might include a situation in which the players have to decide whether spending a valuable resource now is worth buying a chance to obtain a more valuable resource, as my players just did when they gave a very and valuable rare weapon to a knight to gain her favor in the hopes that she’d outfit their expedition to a nearby dungeon.

My point is, to me, it’s way more useful to have the word Scene available as a Scenario Designer to describe a location-based Macrochallenge than it is to define a difference between two kinds of Encounters that does nothing to change how Game Masters run them. And yes, Scene absolutely is the best word for what I’m describing because, in a screenplay, a Scene is a subdivision in a narrative in which the setting is fixed, time is continuous, and is usually defined by a single dramatic question. And that’s exactly what I design Scenes to be.

This shit’s also particularly useful to me as someone who’s set his sights on designing a Game Engine and who believes in his heart that tabletop roleplaying game engines are made for Scenario Designers and not to sell to players. If I can come up with a good, solid language of Scenario Design, I can ensure the Game Engine’s Mechanical Tools align with those. And Scenes — as Location-Based Macrochallenges — are good Mode-of-Play Designators. Because Modes of Play tend to follow either locations — Town Mode happens in Town and Wilderness Travels happens in the Wilderness — or else Macrochallenges — Infiltration Macrochallenges are going to need Infiltration Mechanics. Thus, if I can get you all to adopt my Scenario Design lexicon, I can clearly label the Tools in the Engine Toolbox for the Scenes they mostly belong to.

But Why Not Acts?

Before I sign off — because I’ve said what I meant to say — I want to address, specifically, a question I’ve gotten a few times. “Angry,” people have asked, “why not keep using Scene to describe Non-Encounter Encounters and use the word Act for your Scenario subdivisions?”

Why? Because I also use the word Act. I use it too. If a Scenario’s big enough or complex enough to need an extra level of subdivision, I divide it into Acts and divide the Acts into Scenes. It’s a fuzzier designation which is apt because Acts in screenplays are much less well-defined than Scenes. Acts are narrative segments of indeterminate length that usually conclude with reversals, resolutions, revelations, plot points, or other kinds of act breaks.

See, this is all about building a good hierarchy for Scenario design. One with enough levels to build interesting games but not so many that you spend more time outlining Scenarios than you do designing them. I’ve found that two levels of Scenario subdivision are enough to build the occasional deeply complex long-form Scenario without drowning them in complexity.

When I design a Scenario, I usually start with a Goal. If not, I usually figure out the Goal as soon as I can after the inspiration hits. Depending on how big a Scenario I want, I’ll break the Goal into three to five Plot Points or Conflicts or Challenges or whatever. If that’s enough, they become Scenes. If that ain’t enough, I’ll break one or more of the Plot Points into three to five Subpoints which become Scenes, and the Plot Points become Acts. Then, whatever else I’ve got, I add an opening and closing Act and then I design the individual Acts and Scenes accordingly.

That drill down and subdivide is great not just because it’s easier than filling out a blank page, but also because it keeps the game’s Narrative and its Gameplay in sync. Plot Points come with the resolution of Major Conflicts which are, in mechanical terms, Macrochallenges. But don’t take that to mean I think too abstractly about this shit. I don’t sit there and write “Scenes” and “Plot Points” and “Macrochallenges.” I write a fucking game.

In fact, having the terms in my head and knowing how they fit together helps keep me from getting too abstract or delving too deep into the mechanical weeds. And it also keeps me from making things too complicated. I can only subdivide shit twice before the Scenario gets unwieldy and I run out of language to describe it.

And, by the way, I also have a thing called an Interlude which is where Town Mode lives in my world now and it’s basically a Scene that comes between Scenarios. But that’ll have to wait until I get around to it in True Game Mastery. For now, I’m taking off my Scenario Designer hat. I’ll bust it out again this fall. I promise.