This Feature is part of my ongoing True Scenario Designery course. If you’ve not been following from the beginning, catch up using the True Scenario Designery Course Index.

Scenario Design that Makes a Statement

I feel like I ain’t been here in forever and a day. But I’m back, dummies, trying to crowbar a basic understanding of game design into your thick craniums. Which, if I recall, is what I spent the last three lessons doing, right? I walked you through this super fundamental, conceptual, basic-ass, introductory framework that underpins game design.

Why? Well, it’s partly for the same reason I play Soulsborne games — I like trying to chew my way through concrete walls — but it’s mostly because — and I know I keep saying this, but it cannot be said enough — it’s mostly because scenario design is game design. When you make a roleplaying game scenario, you’re building a game — start to finish, soup to deez — as surely as any video game developer or board game designer.

Roleplaying game systems are engines. They’ve got a lot of the ingredients you need to make a game, but you — the scenario designer — have to put them together. You’ve also got to supply some ingredients yourself. There’s just some shit that’s not built into the engine. Some shit that’d be impossible to build into the engine.

So what’s the plan for today? Well, I want to show you how a True Scenario Designer uses this basic underpinning to develop a Design Statement. Remember Design Statements? That’s where the True Scenario Designer spells out how they’re gonna design whatever the hell they’re trying to design.

I will not be going any further than the Design Statement today. I might do it as part of some other lesson later or I might come up with new and different examples as and when I need them.

Apart from showing you how the concepts I introduced in the last three lessons fit together, this little exercise will also do a segue-type thing and lead us into a much deeper discussion about challenges, outcomes, and a few more advanced game design concepts.

My sample Design Statement is gonna be about building a short, simple roleplaying game adventure. But remember, any complete chunk of beginning-to-end gameplay counts as a scenario. Encounters are scenarios. So are adventure paths and campaign arcs and even some full campaigns. In theory, you’d come up with the same kind of Design Statement for every encounter, adventure, path, arc, and campaign you design. In practice, you probably don’t. But that’s a topic for another day.

All right… that’s enough introduction. Let me do the Design Statement thing so you can see what it’s like and I’ll highlight the important bits we’ll explore in future lessons. Sound good? Yeah? Well, who cares what you think sounds good. I’m the professor; I know what I’m doing.

Taking Games Out of Context

You can’t Truly Design a Scenario without context. True Scenario Designers don’t design in a vacuum. There’s always a purpose to the design. Technically, this context is part of the whole Design Statement thing, but it’s also more of a pre-Design Statement step. Basically, you want to know what the hell your scenario is for and why it’s for.

Scenarios can be for very general things or very specific things. If you’re designing an adventure that comprises the final part of the second chapter of your six-chapter campaign — the one in which your 3rd level heroes will uncover the vizier’s secret ties to the cult of Shrub Niggurath — that’s a very specific for. If you’re designing an introductory D&D adventure for 1st level heroes you can sell, pay-as-you-will-style in your shop on the DM’s Guild, that’s a very general for.

The broadness or the specifocity — it’s a word; look it up — of the context doesn’t matter. What matters is you know what the hell needs your design is meant to fill.

I’m a homebrewer. I run lots of interconnected adventure paths and campaign arcs and so I often have very specific fors when I build scenarios. Most homebrewers do. So I’ve always got a pile of specific Design Statements that need stating. The problem is, my players read this shit so I can’t ever use any real-life examples of my actual design work.

So, I’m going to invent an imaginary, hypothetical, contextual for for today’s lesson. What’s the adventure in  my example Design Statement actually for? It’s for my imaginary mid-level party of heroes. They’re traveling between Townsburg and Castleville or some shit like that. They spent the last session exploring, interacting, resupplying, and resting up in Townsburg while they hunted down a lead. That lead pointed them to Castleville. When they get to Castleville, they’ll be doing a bunch of establishing themselves, interacting, exploring the town, basically more of the same bullshit. I don’t want to do two Town Sessions in a row for obvious, pacing reasons so I want something in between those two and I don’t feel like a Travel Session will provide the kind of frisson I want in my heroic adventure campaign. I need some actual frigging adventure to break up this bullshit.

This imaginary, hypothetical, totally made-up example is pretty close to the sort of shit I’m kind of doing in my games currently. Or it would be if I didn’t already have other plans. But it’s a really good example of the Game Design Über Alles philosophy applied to plotting and session planning. I’m looking at my game’s pace and flow, recognizing a need — or want — to kick things up between the low-key town sessions, and filling that need.

To build further on this brilliant, multilayered example of True Scenario Design thinking, I’m further going to specify that this particular scenario is to be a true diversion. The characters have been laser-focused on the plot for a while and there’s been a bunch of heavy developments in my totally nonexistent campaign’s imaginary plot. I want to up the pace a bit, but I want to tap on the plot brakes too.

In the old days, Dungeon Magazine had these single encounters and short, self-contained adventures sprinkled between the long-form adventure modules. They were called Side Treks; the sort of shit a Dungeon Master could drop anywhere in an ongoing game to fill a session or two. That’s what I’m doing.

So, that’s the context; that’s what my scenario’s for. It’s a self-contained, adventurey side trek on the road between Townsburg and Castleville to add a little excitement between plot-heavy interaction sessions. And because I like them, I’m gonna make it a Site-Based Side Trek Adventure. Yep. It’s a dungeon.

Making a Statement

With the scenario’s for firmly established, I — as a True Scenario Design — can actually start developing my scenario’s actual Design Statement. Remember that a complete Design Statement establishes the Scenario’s…

• Goal
• Starting Point
• Likely Outcomes Good, Bad, and Indifferent, Plural Emphasized for Emphasis
• Major Element of Challenge

They do not necessarily do that shit in any specific order nor do they follow any particular format.

Tools for Youse to Use

Design Statements take whatever form you — the True Scenario Designer — need them to take. They can be outlines, scribbled notes, ideas in the head, paragraphs of overwrought and overthought prose, single pages in a design journal, a tippity-typed out document, an entry in a OneNote database, whatever. As long as you’ve got the proper elements established, your Design Statement is a good one.

That said, it’s always best to write shit down or type it out. Especially when you’re working above the Encounter scale.

Bouncing Around the List

Design Statements ain’t about ticking down a checklist or filling in a Mad Lib. You can fill in the elements in whatever order you want. In fact, True Scenario Designers usually bounce around, tweaking different elements of the Design Statement as they work. Until the moment you step back and say, “Yep, that’s the complete picture of the scenario I want to design,” everything’s lightly written in easily erasable pencil and totally provisional.

That said, your scenario’s contextual for will usually fill in some of the elements for you. Or, at least, suggest which elements to start with.

If I’m writing an Encounter in which the party has to confront a major villain in battle, I’ve pretty much got the Major Challenge spelled out. If, instead, I’m writing an Encounter to give the players a chance to get some clues in a mystery adventure, it’s the Potential Plural Outcomes I need to focus on first and they’ll include several of the following…

• Players Get the Clue
• Players Get a Partial Clue
• Players Lose Access to the Clue
• Players Lose Access to the Source and Have to Get the Clue Another Way
• Players Get a False Clue

The Pain-in-the-Ass Art of Actual Game Design

As difficult as it may be to come up with a complete Design Statement, remember this shit’s the easy part. You ain’t doing the actual design, here, but rather, giving yourself a design assignment. You’re spelling out the criteria and constraints for the design, you ain’t actually doing the design. You can’t get bogged down too much in figuring out how you might be able to pull off whatever it is you’re trying to pull off. At this stage, you’ve got no idea what your scenario design’s actually gonna look like. You just know what it has to do.

That said, it’s important to know your system and your tools so you don’t spend too much time chasing an impossible or impractical design and then having to scrap your work and start again. Which, by the way, is gonna happen. You will eventually set yourself an impossible or prohibitively difficult design task and end up having to throw away a bunch of shit and settle for something else instead. It’s unavoidable. Suck it up, buttercup.

There’s a very fine line between sanity-and-sniff testing your ideas and censoring yourself and it’s a line you can only locate through experience and practice. Early on, it’s better to err on the side of aiming too high and failing, not just because it’ll help you do really great things, but also because it’ll help you get over your fear of failure. Failing is the only cure for failophobia.

A Goal-Oriented Side Trek

My context doesn’t tell me much. I know the scenario’s got to start on the trip from Townsville to Castleburg or whatever, but there are lots of possibilities there so the sky’s the limit. In other words, I’ve got a blank page to fill and no starting point. That sucks, but sometimes, it’s what you’ve got.

Lacking anything else to work with, it’s best to start with the scenario’s Goal. What are the players actually trying to do? How do they win? A scenario’s Goal tends to feed into everything else, so it’s a good seed to plant first.

I’m clinging to the idea of true diversionary Side Trek here and I know I’m doing a dungeon so, assuming the players trip over a dungeon on the way from hither to thither, what might their goal be in delving it?

Obvious answer’s obvious here, right? When players trip over dungeons, they explore them to satisfy their exploratory creativity, find useful items and valuable loot, and gain Experience Points. There’s no reason to eff up a working formula so that works as a Goal here, right?

Well, no…

Exploration and advancement aren’t really Goals but rather, they’re Motivations. A Goal is a Win Condition. It’s something the players can actually do. Something they can finish. What are the players actually trying to do when they enter a dungeon hoping to explore and pillage and level up? Well, they’re trying to fully explore the dungeon and recover all the treasure.

The Goal is, “Explore every inch of the dungeon and recover every valuable thing.”

Do you think I’m being pedantic? Does “Fully explore every room and recover every valuable thing,” sound pretty much the same as “explore, loot, and level-up?” Well, that’s why I’m the professor and you’re the mouthy punk who thinks he knows it all. Below, you’re gonna see how important it is to set your Goal properly even if it means just restating Motivations as firm and finishable goals. It is, in fact, the key to doing the one game-changing thing that’ll revolutionize your adventure design if it’s the only thing you take from this lesson.

See if you can spot it.

Anyway, that’s the Goal: “Fully explore every room of an interesting adventure site and plunder every valuable thing.”

Well Begun is How You Get ‘Er Done

Next, I’ll figure out how my adventure starts.

Some Mere Adventure Builders talk about hooks or inciting incidents which are in-game objects or events that tell the players that an adventure’s afoot and set them off chasing a goal. But Starting Points are more than hooks. A Starting Point is an in-game circumstance that reveals there’s a Goal to accomplish, conveys reasons why that Goal is worth accomplishing, and points the players in a direction to get started.

None of that shit has to be explicitly obvious, though.

Consider my scenario here. The players trip over an adventure site. Any unknown, unmapped, mysterious site in a fantasy adventure roleplaying game presents a clear goal: explore and loot the place. It’s also clear in the context of the game just why that’s a fun, rewarding thing to do. Exploring satisfies curiosity and leads to discovery. It’s a form of intellectual conquest. Characters improve by finding useful equipment and they can trade cashy-money for in-game resources. Adventure sites also usually provide clear starting directions. Every site’s got a door. Some of them have several. Either way, the players can take a clear action to get started.

The point is to consider all three aspects when you figure out your adventure’s Starting Point. Reveal a Goal, suggest the Goal is worth pursuing, and point the way to get started.

Realistically, my Starting Point need be nothing more than an interesting-looking adventure site looming on the side of the road for the party to walk past in their trip from Town Village to the City of Castle or whatever. Just putting it there will do what I need to do. But when I consider the in-game circumstances, it might be weird for a big ole unlooted adventure site to be conveniently located at Exit 17 on the King’s Highway.

Remember, Scenario Design can’t ignore the reality of the fictional universe in which the game plays out. I talked about that months ago.

So, I might have the adventure sitting off the road and then come up with an encounter to pull the players off the road to the site’s doorstep. I don’t have to work out the details now because this is just a Design Statement, but if I have an idea, I can certainly write it down. So, I might decide the players encounter a merchant’s cart ambushed and looted in the road with a couple of dead horses and merchant people lying nearby. A tendril of smoke from a campfire rises over a ridge just north of the road. If the players follow the smoke, they’ll find some bandits or goblins or whatever counting their loot. They just happen to be camping in front of the dungeon’s entrance. It ain’t their lair, they’ve got nothing to do with the adventure, it’s just an exciting little incident to get the players to the dungeon’s doorstep.

In fact, psychologically, this little trick actually makes it more likely the players will explore the site than if I just dropped it on the side of the road, but that’s some advanced psychology shit we’ll maybe talk about some other time.

It is also vitally important that the bandits have nothing to do with the adventure, partly for reasons I’ve already implied, and partly for reasons I haven’t talked about yet. I won’t be calling explicit attention to those reasons, but see if you can spot them.

But, remember, this is a Design Statement. All I need to say is, “The party comes on an ambushed cart on the road, and investigating it leads to the entrance of the interesting adventure site.”

Let’s See How This Plays Out

Next, I — True Scenario Design genius that I am — have to come up with a list of Likely Outcomes Good, Bad, and Indifferent, Plural Emphasized for Emphasis. It’s hopefully clear that I was very picky-choosy about how I worded that to call out some extremely important things.

A Design Statement must include a list of the scenario’s likely outcomes. Those are the ones that you — the scenario designer — can see coming and therefore plan for. There are often good, bad, and indifferent outcomes on the list. It ain’t as simple as calling out as a Win Condition and a Lose Condition and you certainly can’t stop at just calling out a Win Condition. The Goal already defines the best possible, foreseeable, and likely outcome. But if you’ve only got one outcome, you haven’t built a game, you’ve laid down a railroad.

Yes, after a decade-and-a-half, I finally used the word railroad as a pejorative.

The point is, this ain’t really about winning and losing. It can be, but it’s more generally about any and every reasonable way the players are likely to come out of the other end of the scenario. Realistically, some adventures can’t be lost. That ain’t a problem. What’s important is just considering the different ways shit might play out based on the Goal as it’s presented or implied.

My stated Goal is to fully explore every room and plunder every valuable thing this adventure site has to offer, right? So what are the likely, foreseeable outcomes here?

The obvious one is that the players fully explore every room and plunder every valuable thing in the site. But the players might also not fully explore the entire site and plunder every last thing. They might give up partway through. They might decide the adventure is wasting too much time and costing them too many resources and it’s too much of a distraction from their real goals. They might get their asses handed to them, retreat, and then just continue their trek to Fortressopolis.

They might also try their best to fully explore every room and plunder every valuable thing in the site but fail. Maybe they just don’t manage to find their way into every nook and cranny of the delicious, toasted English muffin that is my adventure site. They might not find every tough-to-find passage or they might miss a hidden treasure.

Really, with this particular adventure — and by now, it’s probably clear that I chose this particular kind of scenario as my example because simple though it appears, there’s actually a lot to drive future discussion — really, with this particular adventure, I can’t list a bunch of discrete outcomes and it doesn’t make sense to talk about Win Conditions and Lose Conditions. The outcomes are more about the players achieving some completion percentage between 1% and 100%. The players get to decide when they’re done.

Unless they die, of course, but that’s a dumb thing to consider. Death is not a Lose Condition.

It’s important that you — as a True Scenario Designer — don’t plunge too deep down the rabbit hole of imagining every possible, conceivably outcome no matter how remote the possibility. That’s another line you learn to identify with time and patience and practice. Remember, you’re enumerating — or describing — only the likely outcomes. The ones that are probable enough to deserve a plan.

For instance, I rarely consider The Party Rejects the Adventure as a likely outcome. It’s a pretty slim possibility in general and especially so given the kinds of games I run. It’s just not worth spending a lot of design time on figuring out what happens if the party walks away from the adventure without even trying.

But…

This scenario is actually kind of different and therefore perfectly illustrates how context-sensitive — man, I am using the word context a lot for a lot of different things — it perfectly illustrates just how context-sensitive the word likely is. I’m purposely building a distracting, diverting Side Trek here and it’ll be pretty obvious to my players that that’s exactly what they’re facing. I’m offering them the chance to spend a couple of sessions playing a totally optional dungeon delve for some extra treasure. Thus, there’s a reasonable chance my party will settle for Nope-Percent Completion.

I bring this up because, once you — the True Scenario Designer — come up with a final, manageable list of Likely Outcomes Good, Bad, and Yaddah Yaddah Yaddah, you need to examine each and make sure you’re okay with them. Make sure you can keep your campaign going given any of those outcomes. Or, if one of them is campaign-ending because this is some kind of linchpin scenario, that that’s okay too. Because it is okay to have a campaign-ending outcome as long as it’s okay. Which it is.

You know what I mean.

A lot of True Scenario Design actually lives here in the Likely Outcomes Good, Bad, and Indifferent Plural Emphasized for Emphasis. It’s something I’m going to be spending a lot of time on in the next several-lesson chunk of this course and, probably, throughout the entire rest of this course.

Meanwhile, my Design Statement just acknowledges that my players will likely end up either exploring every room and looting every valuable thing in my adventure site or only being willing and able to explore and loot some portion of the site or ignoring the site and continuing their journey to the next town.

What’s Between You and the Win?

Hopefully, it’s self-evident that if you do this whole scenario design thing right, the best Outcome is the one in which the players accomplish the Goal completely and unambiguously and, more importantly, that is the most desirable Outcome. That’s the one players are gonna want to shoot for. Every other Outcome is either settling for less or some flavor of losing.

The last question to answer in my Design Statement, then, is what makes it hard for the players to get that best Outcome? What’s so tough about accomplishing the Goal? What, in fact, is the major element of Challenge between the players and the win? What might force them to accept a consolation prize or take a loss?

Apart from death, obviously. Death isn’t a Lose Condition.

And no, it’s not Attrition. Attrition is different. I’ll get to that too.

This Challenge thing is also going to be a big part of almost every future lesson in this course and especially the next several-lesson module. As with Plural Good, Bad, and Indifferent Outcomes, Challenge is where game design — and therefore scenario design — actually lives. Designing a game is designing gameplay challenges.

For now, I just want to illustrate a very important way to look at this whole Major Challenge thing that’ll probably be a very new way of thinking about scenario design for lots of you.

First, recognize that a scenario might include lots of different elements of Challenge. The bigger the scale you’re working on, the more Challenges you’ll have to include to fill out your Scenario. If you’re designing an encounter, you’ll probably limit yourself to one Challenge, though you will sometimes have two or three. If you’re designing an adventure, you’re gonna have lots of little Challenges. A campaign is going to include a metric butt-ton of different Challenges as it plays out.

As a True Scenario Designer, you have to distinguish between Major Challenges and Minor or Incidental Challenges. Major Challenges — and often, there’s just one — sit atop the entire scenario and they’re instrumental in determining the Outcome. Minor and Incidental Challenges sometimes also affect the Outcome, but usually indirectly. When you develop a Design Statement for your scenario, you need to call out the Major Challenge. Or Challenges — plural — if you’re doing more than one.

If I were a Mere Adventure Builder designing this little Side Trek, I’d probably come up with some stupid bullshit Major Challenge like, “The party must survive all the encounters as they fully explore the dungeon,” or “In the heart of the dungeon, guarding the bestest treasure, the party must defeat a boss monster.” But we’re aiming higher than that baby shit here. This is True Scenario Designery and that means the Major Challenge must follow in a very direct way from the Goal and the Likely Outcomes.

Here’s how I — as a True Scenario Designer — think through this shit for this scenario.

The Goal is to fully explore every room of the site and loot every valuable treasure. Therefore, the Major Challenge must somehow make it hard to fully explore the site and loot every valuable treasure. A gauntlet of monsters, traps, mini-bosses, and bosses do that, but only indirectly. I’ll have them too, obviously, because this is a dungeon, but I need a Major Challenge that actually makes it hard to access all the rooms and find all the treasures.

This is — again — where scenario design becomes a matter of creative problem-solving. It’s where scenario design becomes an art. There’s no way to do this shit just by mapping a dungeon and scattering elements from a book around the space. I’ve got to imagine into existence a way to test the players that directly follows from fully exploring a space and finding all the treasure therein.

One solution — the one I like — is to require the players to figure out how to navigate and interact with the space in such a way as to make every room accessible. Something about this dungeon locks off parts of it and demands that something be done for complete access. There’s a trick to it. Maybe opening access to some spaces restricts access to others. Ultimately, the players have to reason out — or guess or stumble upon or fail to uncover — the proper configuration that makes the whole dungeon accessible.

By the way, this shit’s the essence of classic, good, true-to-form Legend of Zelda dungeons like mom used to make. You had to locate keys and items to access different rooms. You had to keep track of what was where so you knew where to backtrack to once you had the means to access certain spaces. You had to understand the layout of the space to access certain rooms. Even if you were able to kill every monster and every boss, there was no guarantee you’d be able to explore every room and uncover every last secret.

That, there, is the fundamental difference between a scenario’s Major Challenge and its Minor and Incidental Challenges.

Now, this is going to sound cliché and Arthur from the Discord is probably going to accuse me of ripping him off even though I’ve had this article outlined for several weeks now, but I’m envisioning a classic Water Dungeon type setup. Maybe the dungeon is some kind of Ancient Cistern and flooded chambers and waterlogged passages block access to the whole site and there are floodgates and spillways and drains that let the players reconfigure the dungeon by flooding or draining different areas. Ultimately, the Major Challenge is to find the proper configuration of floodgates, spillways, and drains that give access to every room in the site.

Because, damn it, I liked the Water Temple and you’re wrong if you didn’t.

Design Statemented; What’s Next?

My goal here today was just to show you how a True Scenario Designer approaches coming up with a Design Statement for their scenario. I wanted to pull together the concepts I’ve covered in the last three lessons and lay the groundwork for some future discussions. So, if you’re left saying, “Well, that was neat to watch but I’m not sure I could pull that shit off myself,” don’t worry. There’s a lot to unpack here and it’s going to take time to unpack it all. I know the scenario I chose seems simple and boring and barely worthy of the title of True Scenario Design, but, again, I want you to see how important the right mindset really is. Any idea, simple or complex, can make a great scenario or a terrible scenario. It’s all down to the design.

There’s no real homework here and there’s really nothing to review or recap because this was all about illustrating the process. Recapping the major points would actually detract from the lesson. So I’m just gonna tease the next set of lessons. We’re going to be going over the same basic, conceptual ground again — Goals, Challenges, and Outcomes — but we’re going to be peeling a layer off, digging deeper, and looking at some more advanced game design concepts.

And once I figure out what that actually frigging means and come up with something resembling a game plan, I’ll let you know. Probably next week.