Scenario Design on a Need to Know Basis

July 11, 2025

This feature is part of my ongoing True Scenario Designery series about advanced adventure, encounter, and campaign design. If you haven’t followed it from the beginning, use The True Scenario Designery Course Index to catch up.

This particular True Scenario Designery lesson — which is more of an informal discussion — is a direct follow-up to last month’s Momentous and Inertial Adventure Design so you definitely should have read that.

Scenario Design on a Need to Know Basis

Guess what we’re doing today, desiñors and desiñoritas? We’re deconstructing that big-ass End the Goblins scenario pre-design example I presented in Momentous and Inertial Adventure Design. Again. I got some questions and I want to address them.

But this ain’t any of that casual office hours discussion crap where I just re-explain shit I’ve already explained because none of you get it. This is a real lesson with real information. Half of it’s shit I intended to cover in short order and the other half’s shit I’m setting up to cover later.

If you haven’t read Momentous and Inertial Adventure Design — or you don’t remember the finer points — you should probably do that. I can’t keep re-reviewing everything from every previous lesson whenever I want to build on the crap I’ve already said.

How Do the Players Know…?

So, a few different folks put forth a few different questions and comments that I can basically summarize as two major, related questions.

Here’s the first…

Given that the End the Goblins dungeon is split into three paths, each culminating in a mini-boss, and given that killing the three mini-bosses is how the players actually make progress and eventually win the adventure, how do the players know that’s what they have to do?

And this is the second…

If the dungeon keeps refilling with different encounters every day and the only sign the players have that they are making progress is certain elements or abilities being removed from encounters, how do the players know that it’s their actions that are changing the encounters? How do they know, for example, that killing the kennelmaster is the reason why there aren’t any wolves in any of the encounters? Might they just assume they depleted the wolves? Might they not even notice?

Now, those are great questions, but not because of the questions themselves. I can answer the actual questions easy. The first answer is, “They don’t” and the second answer is, “That’s something you handle when you design the adventure,” but neither of those answers helps you in the pre-design phase, does it?

You see, those questions — and the reasons why those answers are the correct answers — highlight a much more important single question that’s important to start thinking about as early in the whole scenario design process as possible.

What do the players need to know about this scenario and how might they know it?

Ignorant Players are Happy Players

So, what do the players need to know? Specifically, what do they need to know about the scenario? I’m not talking here about rules or game mechanics or backstory or even, technically, the clues that’ll help them solve the mystery or beat the big bad easier. I’m talking very specifically about what the players need to know to play — and potentially win — the scenario you’re making.

There is a reason to separate knowledge about the scenario from information that’s part of a challenge, but that’s a story for another day far in the future. You’re just going to have to trust me.

If you’ve been a long-time fan of my work, it’ll probably blow your stupid mind when I say this, but, in general, the players need to know as little as possible about your scenario. They should know only what they absolutely need to know to play — and potentially win — your scenario and they shouldn’t know one thing more. Your players are like field agents; they’re on a strict need to know basis. You don’t need them second-guessing their orders in the field or revealing too much if they get captured.

Damn, Angry, that doesn’t sound very empowering at all. That doesn’t sound all open-endedness and agency focused. Why are you being such an information miser all of a sudden? Especially given all your rants in the past about clear communication and arming the players to win your games.

Well, hypothetical reader, you’re only saying that because you don’t actually understand empowerment or open-endedness or player agency at all. You dumbass. Not that I’ll be correcting you today. It’s not the day for the agency rant.

There are lots of reasons why you shouldn’t bog the players down with too much information about the scenario itself. Especially when it comes to how it’s put together and all the nuts-and-bolts abstractions you employed behind the scenes to make it work. In fact, that’s the first reason. Scenario designers do a lot of tricks with nuts-and-bolts abstractions that, if players looked closely at them, would remind them they’re playing a game and not exploring a world. This is, in fact, the second reason to not give the players more information than they need. One of the conceits of roleplaying games is that the players’ knowledge is limited to their characters’ perceptions and situational awareness and personal experiences.

With End the Goblins, I really don’t want the players to know I’ve reduced all the complexity around the goblin’s morale and survival instincts and group behavior down to a murder checklist. “Drive the goblins off with repeated assaults until they give in to despair and flee?” That’s organic. “Kill three bosses and you win,” is a quest log in a video game. Both amount to the same thing, but you don’t want to admit that to the players.

The next reason is uncertainty. Tension is a vital part of any narrative and any gameplay experience and roleplaying game adventures are both. Remember all that crap I taught you in True Game Mastery about pacing, right? Well, pacing isn’t about speed, it’s about managing tension. Getting distracted ain’t bad because it wastes game time; getting distracted is bad because it defuses the tension you’ve been building. Since tension is just a product of uncertainty, the less the players know, the easier it is to manage tension. Hell, the main reason for rolling dice is so that the players can’t even be sure their actions will work out.

Another reason to limit how much the players know about the scenario is that roleplaying games are mental challenges. They ain’t sports or toys or video games. You can’t test manual dexterity or reaction time or athleticism or anything like that. It’s all about what players can do with their brains. The less you tell them, the more you force them to reason, deduce, and intuit, and thus the more you force them to test their own mental skills.

I can keep going. There are lots of reasons to keep players as in the dark as possible — though keep in mind, this is just a case for restricting the players’ knowledge to what’s strictly necessary; I’m not saying to keep them clueless by any stretch — there are lots of reasons to keep players as in the dark as possible. I could discuss how people remember information better if they figure it out and how people are more attentive when they feel slightly lost or confused, but this ain’t a masters thesis for my neuroscience in gaming degree. I’m just teaching you how to pretend to elf good.

So, long story slightly less long: as a general rule, the players should only know what they absolutely need to know to play — and potentially win — your scenario because everything they know makes for a worse gameplay experience for a lot of really smart reasons and you’re going to have to trust me.

What Do the Players Actually Need to Know?

All of that crap leads naturally to the question of what the players do actually need to know and man, some of you are going to really hate this answer. I know you all hate situational answers that are highly dependent on your design intentions and that can’t really be qualified and that come down to judgment calls and that you can’t really get right. Some of you hate this creative design bullshit.

Though I will admit I’m kind of impressed at how many of you keep banging your head against this shit. Tenacity is commendable. Creative, subjective design is like a Dark Souls boss for some of you but you just keep throwing yourself at Ornstein and Smog anyway. Good for you.

Anyway…

The general rule is that the players need to know whatever they need to know to play — and potentially win — the scenario. But what does that actually mean? It means the players need just enough information to let them make reasonable gameplay decisions that give them a reasonable chance to reasonably expect victory. It’s all very reasonable.

The problem is that word, right? Reasonable? Some of you really hate that shit too, but suck it up buttercup, because it’s the standard you get in anything that ain’t physics. It’s only gonna get worse when we start adjusting our reasonable player to build an adventure any new player could reasonably win or an encounter only a very skilled player could reasonably expect to overcome. If Games: World of Puzzles magazine can put difficulty ratings on crosswords and logic puzzles and seppukus, True Scenario Designers can put them on their challenges.

Anyway…

The players must be able to take actions and make choices that’ll carry them to victory, right? If they take the wrong actions or make the wrong choices, it should be because they fucked up or missed something or because they’re stupid, right? It shouldn’t be because there was no context or direction available.

In practical terms, that means the players absolutely must know the goal they’re chasing at any given moment. But that ain’t saying much. In fact, it’s kind of a tautology. I already explained that a scenario’s goal is the thing the players are aiming for and it’s their criteria for scoring wins and losses.

Which, by the way, is another thing players need to know. Kind of. In the next section, I’m gonna add a wrinkle to this whole player knowledge thing. But don’t worry about that, yet. For now, just know that the players also need to know whether they’re winning or losing. Or, more correctly, they need to know whether they’re making progress.

Psychologically, it’s important for people to have a sense of progress in any long-term task or else they’re at risk of disengaging. Strategically, people need to know if they’re getting somewhere so they can decide whether they’re doing the right things or they need to try a different plan.

And that’s it for the absolutes. Those are the things that all players absolutely need to know about every scenario they’re playing. Players must have answers to the questions, “What are we trying to do,” and “How are we doing right now?”

But depending on the scenario, the players may need to know a little more. Usually not much more.

What’s Enough to Play the Game?

When you start a scenario with something like, “Here’s what you’re trying to do, and here’s the situation right now,” — which is how Game Mastering works — your players must be able to start taking actions. If they choose reasonable actions — and, depending on your scenario, if they choose the right reasonable actions — they should end up winning. Assuming they also have the right amount of luck.

If the players can’t take actions, they don’t know enough.

Imagine this stupid-ass setup, for example…

You’ve arrived at the gates of Tortleport, a city you’ve never before visited and know nothing about. Before you can enter the city proper, the Captain of the Watch greets you. He explains that your reputation has preceded you and that terrible things are afoot. “Fix our problems,” says he, “And you will earn the gratitude of Baron von Vahnbarren.” He then dashes off, “leaving you to it.” What do you do?

Now, I know there’s some genius-level players out there who can take it from there and I know there’s some Game Masters out there that think that setup is all any player should ever need and if they can’t proceed from that setup, they don’t deserve to win. But can we non-dumbassholes — those are Game Masters who are both dumbasses and assholes — agree that most players will just look at you the way a cow looks at an oncoming train if that shit above is your entire setup?

Players need to know what actions they can take and they need some way to know which are likely to be productive given the circumstances. Otherwise, the players will just bumble around randomly hoping something will make something happen. Or worse, they’ll just sit there staring at you making uhhh noises with their thumbs up their asses.

There’s a long discussion we’re not having today about what it means for players to know what actions are available and to assess which are likely productive and how that fits into the framework of open-ended games and pre-defined actions that come from the rules and push-button play and all that crap. Sorry. I ain’t in the mood for that spherical chicken in a vacuum horseshit and I’ve given up trying to convince some of you asshats that things don’t need to be quantifiable or objective or definitive to be true.

This shit’s subjective and qualitative and so it’s down to the Scenario Designer’s best judgment that arises from intuition, experimentation, and experiential learning. True Scenario Designers spend a lot of time just imagining themselves in the players’ positions and asking themselves crap like, “At this point if I were a reasonable player with a given level of skill and gaming experience, is there a reasonable chance I’d be able to pick the right sequence of reasonable actions that would give me a reasonable probability of winning? Reasonably speaking?”

Put another way, “Given this scenario, do the players I’m designing it for have a fair chance to earn a victory?”

I’ll give you a practical demonstration of this crap below, okay? But first, I gotta add another wrinkle to this whole knowing thing.

Knowing, Deducing, and Feeling

Knowledge is overrated. Too much of it ruins a good game. The less the players know about a scenario — especially a tabletop roleplaying game scenario — the more likely they are to find it satisfying and engaging and meaningful and all that crap. So a lot of scenario design is figuring out the recipe for the Goldilocks Porridge of Knowledge to feed your players.

But — and depending on your personal perspective and tolerance for the bullshit that is subjective, creative design, this might be a nice but or an ugly but — but, when it comes to scenario design, there’s knowledge and then there’s Knowledge. True Scenario Designers know the difference; most Game Masters don’t.

You see, there are different ways to know things. You can Know shit, you can Deduce it, or you can Feel it. As a Scenario Designer, information can take the form of Knowledge, Deduction, or Intuition.

Knowledge is clear, concise, unambiguous, explicit, actual-factual information the players receive. Either they get it from the rulebooks or they get it from the Game Master, often at the Scenario Designer’s instruction. It doesn’t have to be rules or exposition, but it often is. How to make an Ability Check? That’s knowledge. The troll takes extra damage from fire? That can be knowledge if the Game Master says, “You rolled 12 points of damage but the troll takes 24 points of damage because he’s vulnerable to fire.”

If it’s clear and explicit and if it wouldn’t require any special reasoning or interpretation for a reasonable player to figure it out, it’s Knowledge.

When it comes to a scenario, the players should Know the game’s goal. They should always be able to clearly and concisely state what the hell they’re trying to accomplish.

That’s not quite always true but it’s a rule too many people break too easily thinking that’s how you make a mystery or surprise or whatever, so as far you’re concerned, it’s always true. Hell, I already explained why it’s pretty much definitionally true above.

Deduction is information that requires the players to do some reasoning to know it. Deduction is information the players synthesize from other bits of information, which bits can themselves be Knowledge or Deductions or even Intuitions. When they’re put together, Deductions are still clear and explicit — players should be able to state what they’ve deduced — but there’s some mix of skill and chance required for the players to get there.

Obvious answer is obvious, the solutions to mysteries and puzzles and problems are all Deductions, but that’s gameplay shit. In scenario design, the players often have to Deduce which course of actions to take — whether it’s an open-ended challenge or whether there’s a set of paths to choose from — and they may have to reason out how their actions are bringing about the changes they’re seeing. In, End the Goblins for example, the players might say, “I think when we killed the kennelmaster, the goblins lost control of that pack of wolves,” or “The goblins seem to have some kind of divine magic protection thing so maybe we should try to find and kill their shaman or destroy their shrine.”

Intuition is the haziest and fuzziest kind of information. It’s highly subjective and it’s very difficult to describe. Consequently, most Game Masters and Mere Adventure Builders totally dismiss it. To them, Intuition doesn’t count as information. That just goes to show you what utter dumbasses most Game Masters and Mere Adventure Builders are because Intuition is the most powerful, most useful, best kind of information there is and True Scenario Designers know it.

Intuition refers to stuff the players feel, but which they might struggle to precisely explicate, let alone qualify. Intuition is emotional knowledge.

The thing is, humans — including you, sorry because you ain’t Spock and experiments with people whose emotional brain parts got broken have shown that if you were, you couldn’t make even the simplest decisions — humans make most of their choices based on emotional knowledge rather than rational, logical knowledge. Humans also form all their opinions based on emotional knowledge. That’s how people are wired up.

The players will decide how to treat nonplayer characters based on how you’ve made them feel about the character. Even if there is no logical reason to suspect the character’s a sinister asshole, if you’ve somehow given the players the sense that he’s shady, they’re going to treat him like ass. You know this. All Game Masters do.

More importantly, though, the players will decide what to think about your game and your game mastering and your scenario design based on how it feels to play the game. Given that running a game your players don’t find satisfying and rewarding and engaging — notice how I did not say the word fun; fun is a bullshit word for morons — given that running a game your players don’t find satisfying and rewarding and engaging is how you lose at game mastering, this is kind of a big deal. Which is why I insisted, above and a thousand other frigging times that pacing is the most important thing a Game Master does, by the way.

Anyway…

You’ve probably noticed that I keep using the word feel when I discuss gameplay dynamics like momentum and inertia. Now you know why. The sense of momentum — the feeling like they’re making useful progress — is information the players know about the scenario, but it’s not Knowledge they can concisely explain. They feel it. It’s information they Intuit.

In End the Goblins, the players need to feel like they’re making progress as they take out the mini-bosses. But they should also feel like just killing faceless goblin after goblin is a pointless waste of time because they’ll never make a dent in the endless horde.

The Scale of Informational Just Rightness

Hopefully, it’s obvious to most of y’all that there’s a spectrum thing going on here. As you move down the information scale from expository Knowledge through acquired Knowledge and then into Deductions of increasing difficulty and through the realm of explicable Intuition — “I hate that guy; he’s up to something” — to end up at totally unconscious Intuition — “You may not have noticed, but your brain did” — you’re trading things like reliability and certainty for impact and retention. Meanwhile, there’s this kind of bellcurve of player skill overlaying it that peaks just shy of where Deduction hits Intuition.

Knowledge is reliable. When players know Knowledge, they know it. Reasonable players rarely fuck up knowing Knowledge. But Knowledge is the least impactful kind of information and the most forgettable and it requires nothing from the players to know it.

Intuition is subjective. It’s unreliable and it’s uncertain. Try as you might, you can’t guarantee you’ll get any given reasonable player to feel what you need them to feel. Moreover, at the very end of the Intuition spectrum, conveying Intuitive information is more about the Scenario Designer’s design chops and the Game Master’s presentation than about the player’s skill. But intuition is impactful and memorable and it’s pretty much the thing that determines whether the players keep coming back or not and what they think of the game you’ve designed and run.

For players to know Deductions, they have to deduce them. That means there’s a skill factor. There’s also a luck factor. There’s always a luck factor. As soon as you leave shit up to player skill, though, that introduces uncertainty. You can give the players as many clues as you want; if they don’t put them together, they don’t know jack. Of course, a lot of the challenge design part of scenario design is about adjusting the requisite level of skill — intellect, creativity, whatever — required of players to have a reasonable chance of deducing a Deduction and setting that chance properly. Because there’s skill involved, that means Deductions are the most gameplay kind of information there is. That also makes them rewarding. Emotionally, Deductions are worth a little squirt of happy brain chemicals. Thus, Deductions are impactful and consequently memorable. The only problem is the impact is of the quick, cheap variety. Especially when the Deductions have to do with the scenario — “Yay, I figured out how the Game Master is measuring progress” — rather than overcoming actual challenges.

As a scenario designer, then, you’re not just worried about what the players need to know but also how it’s best for them to know it. Gamefeel is your bread and butter and you really want the players to feel the most important elements rather than know or reason them, but if there’s information the players absolutely have to have just to play the scenario, you need to spoonfeed them that shit. Deductions are good for bridging the gap between the nuts-and-bolts mechanics and the actual challenges — especially the macroscopic challenges — but you don’t want the players deducing the mechanics and the abstractions themselves. You want them focused on their action-choice causes and the resultant effects in the context of the fictional game world.

So how does a True Scenario Designer work this shit out? And how much of it does a True Scenario Designer lose sleep over in the pre-design phase?

Let me end this by taking you through my information-based reasoning as I pre-designed End the Goblins.

What Do the Players Need to Know to End the Goblins?

Let’s pretend I actually plan to design End the Goblins for real and that an actual Game Master — maybe me — will be running it for actual players someday. None of which is true because it was a big-ass example I pulled out of my ass especially for you as an object lesson in pre-design, but let’s pretend.

Pretending that, what do I think the players would need to know to play — and potentially win — End the Goblins?

I always assume players need an unambiguous, explicit goal to play a game. Because at least 99 times out of 10, they do. So, when I design End the Goblins, I’ll start it with an introduction that clearly tells the players, “There’s goblins in that waterfall cave and they need to not be there anymore because they’re vile and violent and terrible.” You know, just in case saying, “This adventure is called End the Goblins,” isn’t frigging clear enough.

“Is that enough,” I ask myself, “that the players can pick a reasonable course of action and, given luck and some follow-through, have a fair chance to forge a path to victory?”

Of course it is.

As it exists right now in the pre-design phase, the major challenge is about pushing through a bunch of encounters in a row to take on a few mini-bosses. If the players show up at the cave and just start killing — which they’ve been explicitly told is the point — they’ll eventually kill the mini-bosses and that’ll trigger a victory. They don’t actually have to know there are mini-bosses or that victory is based on the Game Master tracking an abstract Mini Bosses Murdered counter.

In fact — and I’m jumping ahead here — the whole dungeon branches into three distinct paths that each end in a mini-boss thing is something I did on purpose so the players wouldn’t need to know anything about the design to win.

See, players come pre-programmed with all sorts of assumptions and behaviors and shit. That’s all part of the reasonable player thing. Give players a dungeon and any sort of goal at all and they’ll assume the keys to victory are “going deep” and “covering ground.” Players tend to visit new areas before revisiting old areas and they tend to assume that any goal is as far from the entrance as possible.

Now, those assumptions play out differently depending on the players. Some players are explorers and prefer to clear all the side rooms before going in whatever direction they think is progress. Some are goal-seekers and prefer to choose the direction that leads to progress first and then clean up the side stuff at the end. But you can’t even count on that because players change their behaviors depending on the stakes and the challenges and the players’ moods and the group dynamic and how many resources they’ve used up and how much they’ve struggled and the phase of the moon and whether Mercury is trine with Saturn or whatever. Regardless, though, the basic ideas of “go deep” and “cover ground” are in there somewhere.

So imagine three linear gauntlets that all start at the same entrance. What will players do? They’ll pick a path and clear it to the end. Then, they’ll head back to the entrance, pick another path, and clear it. If they’re forced to retreat before finishing a gauntlet, when they come back, they’ll either start a new path and clear it to completion, or else they’ll resume the unfinished gauntlet. Either way, they’ll eventually clear all three gauntlets to the end instead of just clearing the same six rooms — two from each path — over and over, day after day.

The players don’t need to understand how the dungeon’s designed or even that the mini-bosses are the key to victory. If they just behave like players and cut a bloody swath through the dungeon, they’ll win. Reasonably skilled players will do it in three to five trips.

Of course, I muddied up the design with some side rooms and cuts between the paths, but that just lets the players explore on their own initiative and express their natural tendencies. Because of the “cover ground” habit, it’s not like they’ll get stuck looping through the same rooms over and over or any shit like that. Of course, they might overspend resources or switch from one unfinished gauntlet to another inadvertently, forcing them to retreat early or double back later which might cost them more resources or chew up an extra day, but we call that shit gameplay and that’s the whole point of all of this crap.

The point is, that I intend to explicitly reveal the goal as Knowledge and then rely on the design to nudge the players toward overcoming the challenge on a deep, Intuitive level, leaving them choices that’ll give them a chance to earn victory or lose it by improperly managing resources or not keeping track of where they’ve been or whatever.

Above, I said the players have to know they’re making progress. That’s an important gameplay dynamic, right? Unfortunately, as one of the questioners pointed out, I’ve made a mess of that with my stated design intentions. In fact, I did that pretty explicitly. I said I wanted the players to feel like they’re clearing out an infestation that is just too big to handle. That’s basically me saying, “I want the players to feel like they can’t possibly make progress against this.”

That’s why the dungeon keeps restocking.

Did I fuck up? No. I don’t fuck up. I wanted to create a specific feeling and it’s the right feeling to create. But that doesn’t mean I get to ignore the fact that the players still need to feel like they are making progress. Since the scenario is actually laying on the inertia pretty hard with the the dungeon keeps restocking worse because there are somewhere between a hundred and infinity goblins to kill, I’ll need to make sure the players can clearly see signs of progress. This ain’t a time for subtle Intuition even though gameplay dynamics like momentum are usually more about feels than facts.

The point is, at the very least, the players have to notice that they’re weakening the goblins somehow and I’d like it to be possible for the players to Deduce what, specifically, they’re doing to weaken the goblins. They don’t have to draw that conclusion to know they’re doing something, but it’d be nice if they could.

Thus, when I actually sit down to do the design work on End the Goblins, I need to call attention to the changes in the encounters as they happen. I need to make them visible. I will also want to add some clues in the adventure that connects the mini-bosses to those changes.

So, first, there’s the idea that the goblins have a divine blessing or buff that they lose when the shaman’s dead, right? Based on what I’ve said above, this ain’t the place for a subtle buff or numerical bonus. The blessing has to be something the Game Master can’t not convey and that reasonable players can’t not notice. It’s got to be an aura or an action or something that affects the players’ dice rolls or something. For maximum impact, that buff must be thematically similar to the goblin shaman’s powers. Maybe the goblin shaman has a stronger version of it or an offensive or active version of the other goblin’s defensive buff or whatever.

The point is, it should be super obvious the goblins go from having a magical buff to not having it so the players know the goblins are weaker today than they were yesterday. If that buff also vanishes the day after the players kill the shaman who had the same kind of powers and the buff was presented in a way to suggest it was of a divine magical origin, it’s not a stretch to imagine a reasonable player saying, “This might have something to do with that zealous little magical fellow we killed yesterday.”

The same applies to the wolves. When the wolves are gone, I need to call very explicit attention to their absence. The players have to recognize that something definitely changed about the goblins and the wolves otherwise they might just assume they killed all of the wolves or even just ignore the change because, well, the encounters are all different anyway and maybe the Game Master is just done using wolves or whatever.

If I assume the kennelmaster was the only goblin who could control the wolves and he abused the wolves to keep them in line, then when he’s dead, the wolves might have turned on the goblins. When the players return, maybe there’s an injured wolf eating the corpse of a dead goblin right at the entrance. The wolf runs or limps away or the players take it down in a non-encounter. A few more wolf corpses around and some half-eaten goblins will drive the point home that the wolves turned on the goblins and the goblins killed them or drove them off.

Likewise, when the chieftain is dead, there’s some factional infighting and a bunch of goblins end up dead before the power vacuum is filled. I can indicate that with clues of orange-on-orange violence or maybe even include a nonplayer character prisoner or a surrendering goblin that speaks common that can foreshadow the complex nuances of goblin politics. That might lead the players to purposely seek out the chieftain to cause infighting just as they might purposely look for a shaman to rob the goblins of their divine powers.

All of this crap is for the design phase. Hell, this shit is scenario design. I’m gonna get to all of it. I’ll show you how to use your design to communicate information as Knowledge, Deduction, and Intuition. I’ll show you how to plan an adventure structure so reasonable players will be able to navigate it without you having to spell out every damned thing explicitly while still leaving the players plenty of room to explore on their own initiative. I’ll show you how to plan progressions so that later encounters tie back thematically and mechanically to earlier encounters so that everything feels like a part of the same whole. But it is good to think about the design work you’re gonna have to do to make your scenario work in the pre-design phase. In fact, eventually, that’ll just be second nature.

Meanwhile, now you’ve seen my thought process and you know why I gave the answers I did to those questions people posed. You know why the players don’t have to know that they need to clear three paths to win and why it’s better if they don’t and you know why I said, “I’ll figure that shit when I’m actually pretend-designing the adventure” when asked how the players will know their actions are changing things.

So now… can we please move on from this crappy End the Goblins example. I’d really like to start talking about adventure structures or progressions or even just draw a fucking map in this supposed adventure design course.

This conceptual thinking about designing stuff totally sucks.


[jetpack_subscription_form]

6 thoughts on “Scenario Design on a Need to Know Basis

  1. This article really helped me see something about my games: that I rely WAY too much on explicitly spelling out the parameters of the game / scenario to my players.
    I can see it’s a crutch, and was better than the alternative of them feeling lost, but this whole subject is something I’m VERY excited to improve on

  2. I know you want to move on from this shit, but my most rage-inducing experience of being a player was at a table with a DM who just *sucked* at pretty much every part of this article. They either really enjoyed watching players aimlessly wandering around in the dark, or got some kind of kick from ‘subverting the norms of the game’.

    The party was given no clear direction or motivation for the adventures. Solutions to problems were not even slightly signposted, and in fact often completely contravened game design logic. Flipping a switch in one room triggered something in another room that we neither had reason to revisit, nor contained any device or feature which could have made us think “Hmm, we should put a pin in this and come back” or any visible link to the room with the switch.

    Solving a puzzle based on opening sequential linked gates relied on pushing the levers back and forth really quickly to break the mechanism, rather than what any reasonable player would assume, which was that there was a deducible specific order of gate activations which would result in clear passage, Tower of Hanoi-style. It blew my mind when he told us after the session that there was no actual sequence of moves that would open the gates correctly. We spent a 4 hour session on that crap, and it was the closest I’ve ever come in my life to flipping a table and leaving the building. And that was just a standard puzzle encounter, never mind full blown adventure design.

    So as much as we hope we wouldn’t have to spell this stuff out, there are DMs out there who really need to hear this. We can only hope they read your site.

    • That really does sound miserable. How did the original occupants even use the gates if there was no combination of levers to open them?

      I hope they’ve gotten better with practice or that you found a better table to play at

  3. I rarely comment on any forum because my time is precious but no this occasion I will, just to say… absolutely damn amazing article. Seriously, you write some good stuff Angry – or do you prefer Mr GM? I can’t believe I missed this the first time around and only got to it now, months late.

    I’ll be changing my design process to fully incorporate these ideas. I can already see how it will improve my games, both for me and the for the experience of my players. Many thanks indeed.

Leave a Reply

Your email address will not be published. Required fields are marked *