First: 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.

Second: This course is based on a bunch of assumptions about the role of game design in tabletop roleplaying adventures and campaigns. I already spelled them out, and I will not defend them any further. If this course ain’t for you, just let yourself out quietly.

Third: This course uses a bunch of terms I’ve invented, co-opted, and beaten into submission. Words mean what I say they mean and arguing otherwise won’t get you nowheres.

Fourth and finally: This lesson is part two of a three-part whirlwind tour of basic, conceptual game design. I’m bouncing around and lot and some of this crap won’t make sense until it’s all done. If you’ve got questions, just be patient. It’ll all make sense eventually.

Fifth, after you’re done reading this, check out Q and Angry: The Anatomy of a Game Follow-Up, in which I answer ready questions and comments about this Feature.

You have all been disclaimed. Now, on with the show…

---

The Anatomy of a Game

You all back? Great. Sit down and shut up because I’m gonna start.

Last time, I taught y’all about Designing on Purpose. That is, I told you to decide what the hell kind of gameplay experience you were designing before you actually design anything. And I told you there were two corollaries to that. First, good scenario designers — like you hope to be — start their designs with Design Statements that spell out — at the very least — the scenario’s starting point, the players’ goals, the possible outcomes, and the scenario’s major challenge.

This lesson’s about why those things. The next lesson’s about that last thing in excruciating detail.

Second, the gameplay experience is the buck-stops-there criteria for all you do. Everything you do must serve a gameplay purpose and no gameplay need can go unmet. If there’s shit in your game that doesn’t have a gameplay purpose, drop it. If there’s a hole in your game, fill it. If you can’t do those things, throw the game away because it ain’t gonna work. You failed.

Scenario Design ain’t math and there’s no process to it. It’s a creative problem-solving thing. You state your design goal, identify your needs, and find the best ways to fill them.

Got all that? Great.

Today’s topic: what makes a game a game?

A Scenario is a Game

Confession time… I’ve been careless about my terms. Purposely. I’ve been trying to blur some lines in your dumb head. I’ve been using the words encounter, adventure, campaign, game, and scenario interchangeably. That’s because they’re all the same frigging thing. Basically. You can make a weak-ass argument that encounters don’t belong on that list, but don’t waste your time or mine. It’s a fiddly, technical point and you’ll design better encounters if you don’t make it than if you do.

Scenario design is all about taking the different elements of a game and assembling them into an actual game. Until a Scenario Designer comes along, the game’s just a pile of rules and stats and game constructs and shit like that. It’s a pile of game ingredients. The Scenario Designer’s job is to finish the game assembly process. To turn the ingredients into a game.

That means that, while the Scenario Designer isn’t designing the game’s mechanics — and shouldn’t — they’re the one that brings the whole game together. And that means they’ve got to understand the whole game design thing. You can have the best rules system and the best monster stats and the best character creation system ever, but if you can’t build a good gameplay experience out of it, no one’s gonna have fun. Likewise, you can have bland rules and shitty stats and no character creation to speak of and still get a great game if you know what makes games great.

In short, scenario design is game design. Game design ain’t about rules and stats and balance and math. It’s about knowing how to put your pieces together into something great.

Tabletop Roleplaying Games Are Special Snowflakes

And so are tabletop roleplaying gamers these days. Obnoxiously so.

Ha ha ha, I’m just kidding. We have fun here.

Seriously, though, every game medium and every game genre is different. Each is unique. Extraction shooter video games are really different from worker-placement Eurostyle board games and both are very different from baseball. No shit, right? But those are all games. And they have more in common than you might think. And it’ll make you a better designer if you know them all and more.

I’m not kidding here, by the way. Play every genre and every medium of game you can. Even the ones you think are bad. Even the ones you think, technically, aren’t games. Like sports and Candy Land. People tell me all the frigging time how Candy Land isn’t a game. It’s their go-to example. But not one brainiac has yet been able to explain to me why it is a game and what you can learn from it. Because it is. And knowing how that can be illustrates a vital facet of game design you have to grok.

But I digress…

My real point here is that, while it’s good to look at lots of different kinds of games, you also have to know what makes your medium and genre special and how it changes the game-design equations. As I take you through this whole scenario design thing, I’m gonna say some shit that’s not technically applicable to all kinds of game design. And I can’t be assed to specify. So it’s on you to use context clues to figure out when my use of game design means all game design ever or tabletop roleplaying game design or just fantasy adventure tabletop roleplaying game design.

Context clues, kids. Use ’em.

What Makes a Game a Game?

Enough dicking around… what makes a game a game? What do games — and therefore scenarios — need to count as a game? It comes down to four things: Goals, Rules, Challenge, and Context.

That last one, by the way, is the reason I had to give that speech about media and genera. Context won’t make or break baseball, but it does make or break a tabletop roleplaying game.

To make a game, you must provide those four things: Goals, Rules, Challenge, and Context. Are there other things that go into game design? Yes, absolutely. But those other things are more about the difference between good and bad games. These four things are the basic qualifications to even count as a game.

The entire rest of this lesson is about each of those four things. And the entire next lesson is about the most challenging of those four to get right.

Why Isn’t That The Design Statement?

You might be wondering why those four things — Goals, Rules, Challenge, and Context — aren’t the four components of a Design Statement. Two of them are — there’s overlap — but if scenario design is game design and games need those four things — at a minimum — shouldn’t that be the starting place?

Great hypothetical question, me! So glad I asked.

First, remember that you — the Scenario Designer — ain’t the only hand on the wheel. You’re actually the last hand on the wheel. By the time you’re doing your thing, the game’s major mechanics — the Rules — are already in place. And your Design Statement does acknowledge that fact by whispered implication.

When you say…

A village lies under the thrall of a dragon. The heroes arrive…

… there’s an invisible first sentence that reads something like, “In this adventure for the 5th edition of Dungeons & Dragons.” Rules covered.

Your chosen system and genre also set the basic Context for your game. The reason to focus on the starting point and the outcomes is to narrow your Context. You’ll continue working on the Context throughout your design. But that’ll make more sense when we talk more about Context.

That’s why your Design Statement is what it is and how it really is about Goals, Rules, Challenge, and Context even if it’s not explicitly about them.

Moving on.

A Winning Goal

Every game needs a Goal. No Goal, no game. It’s that simple.

A Goal is an actual, tangible, in-game thing the players are working toward. A Goal is the end of a sentence that begins, “To win, the players must…” The facts that tabletop roleplaying games are open-ended and have narratives and simulate worlds and give players agency do not excuse the game from having a Goal.

Every scenario you design — every encounter, adventure, arc, and campaign — must have one or more explicit, in-game Goals. Full frigging stop.

Don’t confuse Goals with Motivations and don’t confuse them with Rewards. Don’t confuse Motivations with Rewards either. Lots of dumbasses do that. Having fun ain’t a Goal. Neither is share a story. Those are player Motivations. They’re reasons players play games, but they’re not how you win games. A character’s desire to amass wealth or serve good isn’t a Goal either. Character motivations are Contextual reasons for the pursuit of Goals, but they’re not Goals. Experience points and level-ups and fancy new spells and magical items aren’t Goals either. They’re gameplay Rewards.

Goals come from the game, not the players and not the characters. That’s an important part of this. Players bring their motivations to the table and may invent in-game motivations as part of their Contextual roleplaying framework, but Goals come from the game because they’re part of the game. Players don’t need to know why roleplaying games are fun to play and win, but if they don’t know the Goal, they can’t really play the game.

Don’t worry… I’m gonna spend a lot more time on Goals later. I’ll probably do two or three dedicated lessons on just Goals. They’re really important.

The Rules of the Game

Every game has Rules. Rules define how the players interact with the game. Rules tell the players what they can do, what they can’t do, and how the outcomes are determined.

Roleplaying games are very open-ended. At least, in theory, they’re supposed to be. Thus, the Rules of tabletop roleplaying games are meant to allow players to attempt any interaction they can imagine might be possible within the Contextual reality of the game. And, mostly, they do. Provided, of course, you recognize the Game Master — and his judgment — are part of the Rules. But the open-endedness of roleplaying games and the existence of the Game Master don’t excuse the game from needing Rules nor the players from being bound by them.

You — the Scenario Designer — don’t write the Rules. That’s what the game system’s for. You’ve got to work within those rules when you design your scenarios. That means you have to understand — really frigging understand — those rules and that you must accept their constraints. Even the ones that aren’t actually written.

For example, the most important rule in tabletop roleplaying games is the one I called the Declare-Determine-Describe Cycle back in True Game Mastery. That’s basically a formal name for that thing where the Game Master describes what the characters see, hear, and perceive, and then the players describe the actions their characters take and then the Game Master determines and describes the outcome.

Yes, that’s a rule. It’s the tabletop roleplaying game equivalent of Magic: the Gathering’s Untap-Upkeep-Draw-Main-Combat-Main-Cleanup thing. Or whatever the hell it is now. As a Scenario Designer, you’ve got to understand how the game works on that fundamental level and make sure your scenarios work with it.

Say, for instance, you want to do a scenario in which the players’ characters join — or command — an army and fight an invading horde of savage, evil, barbaric orc raiders. How does the Declare-Determine-Describe limit you? Well, for one, it technically means you can’t allow the players to take direct, sky-god-like control over the army units and play a war game.

A proper army scenario means starting with the assumption that the players only know as much as their characters can perceive. They know what their characters can see and hear and from whatever reports their scouts and outriders and officers bring them. And the players are limited to personal character actions. The characters can give orders — shouting them or relaying them via messengers and officers — but they may not know immediately what the outcomes are. Once the battle starts, the players might not know what’s going on beyond their immediate areas.

I know that ain’t how anyone runs mass combats in roleplaying games — and if your game does have a system for mass combat, that’s how you should do it — but really, in D&D 5E, that’s how you should run a war.

Consider also how many video games use cutscenes to convey information. Sometimes, they’ll even show events the players’ characters aren’t present for just to provide the player with Context or establish a Goal or whatever. That’s totally fine for a video game, but it’s technically outside the rules of tabletop roleplaying games. The players can’t know what their characters can’t perceive. So, if you need to establish how evil the villain is, you need to put that information where the characters can perceive it.

Am I being a bit of a purist here? Absolutely I am. And note I ain’t saying that a rule that allows the characters to directly control NPC allies or to move armies or ships around like they’re playing a strategy game is wrong or bad or whatever. If the system’s got a rule for that, use it. But if it doesn’t, the proper scenario design approach is to limit perception to the characters in every way all the time. And a True Scenario Designer understands all off the rules and their implications, not just the shit about statting up combats and resolving Strength checks or whatever.

Rules Preprocessing

You ain’t an Engine Designer. Did I say that already? You — a Scenario Designer — don’t do rules and mechanics. You work with what you’ve got. And you know your rules inside and out, frontways and backsides. But, even though you ain’t responsible for designing rules, you are responsible for them. More responsible than the poor, put-upon Game Master struggling to run your crap scenario as correctly and efficiently and effectively as possible. So one of your jobs as a Scenario Designer is to do as as much Rules Preprocessing as possible.

What does that mean?

Say there’s a locked door in your game. As a Scenario Designer, you’re smart enough to know the players will want to get through that door by any means necessary. You should also be smart enough to know how they’ll try to do it. Predicting Player Behavior is actually another one of your jobs. But that’s a lesson for another time.

You should know, for example, that most players will try to bust down the door, for example, or they might try to pick the lock. Simple stuff, right?

As a Scenario Designer — and resident Expert in the Rules — you give the Game Master all the little, mechanical fiddly bits to resolve those actions. You spell out the skills or abilities that might apply, the target numbers the players must roll, and what happens when the players succeed or fail or crit or fumble or whatever other stupid possibilities your system’s rules account for.

That’s Preprocessing the Rules. You predict the mechanics that are gonna come up and you arm the Game Master to handle that shit. You don’t not leave anything up the to Game Master’s judgment if you can see it coming. The Game Master’s judgment is for the shit you failed to see coming. You also don’t shrug and say, “Well, the Game Master knows how to set the DC on a lockpicking check and he knows the rules for busting down doors.”

To some of you, this crap’s really obvious. But there’s a hugely important, conceptual, philosophical underpinning thing that’s going to matter a lot next lesson and in many lessons to come. It’s something, that if you don’t grok, will leave you pissing and moaning at me about Player Agency. Which, by the way, is a joke. Player Agency is the Santa Claus of Scenario Design. It’s a fun fantasy that makes a lot of people happy, but it doesn’t exist, and knowing it’s a lie and keeping it alive is part of being an adult. Did I already say that? I’m saying it again. Repetition, kids; it’s how you learn.

Sorry… got distracted…

There’s a really important conceptual underpinning to this whole Preprocessing thing, right, and that is this: when you list the mechanical rules for resolving actions you foresee the players taking, you are not defining the possible actions the players can take. You are not spelling out how the players can or must deal with a game situation. You are merely predicting the actions the players are most likely to take and arming the Game Master to resolve them as effortlessly as possible.

That’s one of the reasons why 4E Skill Challenges — and other similar mechanics — were — and are — totally FUBAR. They were presented — and built — as lists of possible interactions, not predictions of likely interactions. But that ain’t a story for today.

Speaking of stories for another day, next lesson, I’m gonna break your brain by telling you the exact opposite of what I’m saying right now. Let’s see how many of you have aneurysms from the paradox that isn’t actually there. It’ll be a fun time.

Moving on…

Rising to the Challenge(s)

A game must present its players with one or more in-game Challenges and I am choosing my words with the utmost care there. Every word in that clause matters and they are exactly the words they need to be. Even my using the word Challenge is deliberate. I could have made my life a lot easier by picking a word like Obstacle or whatever. I wish I could have. The word Challenge really screws with lots of your dumbass brains. But it’s the right word here.

A Challenge is anything the players must accomplish or overcome on their way to the Goal. If the Goal is a treasure, the Challenge is the dragon sleeping atop it. Games without Challenges aren’t games. Except when they are, but that shit’s outside the scope of this course. Challenges are what make the players work for the Goal and thus what make achieving the Goal feel like a win.

Do not confuse the word Challenge with the word Challenging and do not equate Challenge with Difficulty. A thing is a Challenge — and Challenges players — if it requires any effort or skill whatsoever to overcome it and if there is any uncertainty at all. Even if you think a Challenge is super easy and that 99 players out of 10 will cakewalk through it, it’s still a Challenge. It just ain’t a difficult Challenge.

Also, note that Challenge Ratings are not inherently about Challenge or Difficulty. Not really. Challenge Ratings — as they exist in the Dungeons & Dragons and Pathfinders of the world — aren’t actually, inherently about how difficult a Challenge a monster presents. Difficulty Classes also ain’t about Difficulty or Challenge. The fact that a task with a DC 15 is considered Hard or whatever has nothing to do with whether it’s a difficult Challenge. In fact, the task isn’t a Challenge at all. Unless it is. And, actually, it’s your job — as a Scenario Designer — to know that actions and tasks aren’t Challenges and they’re not challenging and figure out how to fix them. That ain’t, by the way, a failing of the game’s design. That’s not because the designers did it wrong; it’s because that’s how games and Scenario Design work.

This shit — and the fact that you’ve probably gone cross-eyed by now — is why the entire next lesson is about Challenge.

I just want you to understand, today, that games must present players with one or more in-game Challenges. Most games include one or two major Challenges and a bunch of minor Challenges. The most obvious example is the dungeon with the boss fight at the end, but that’s also, like, baby’s first Challenge Structure. When you’re ready, I’ll show you how to do way more than that. But you won’t be ready for a while.

There’s one other thing I want you to understand today, and that is that tabletop roleplaying games are really frigging limited in the kinds of Challenges they can present. Really, they can only do Challenges in which the players have to make the right choices — or the best choices or just good choices — in a given situation. It ain’t like they can test muscle memory or physical aptitude or reaction time or anything like that. Moreover, because roleplaying games are narrative by nature and because of the weird flow of in-game time, even lots of choice-based Challenges just don’t work in a lot of roleplaying games.

Again, though, the next lesson — and most of the rest of this course — is to do with Challenges so I ain’t going to harp on this shit anymore today. But I’m going to ask you to think about something before the next lesson.

Consider, again, that Locked Door Challenge I mentioned above. Which, by the way, we’re gonna talk a lot about. My supporter Discord server is sick to hell of The Locked Door Challenge already given how much I’ve harped on about it, but it really is a perfect example of what it means to build Challenges in tabletop roleplaying games. I firmly believe that, if you don’t understand how a locked door can — in and of itself — be a Challenge — and how you — the Scenario Designer can make it one or not — then you can’t be a Scenario Designer.

So, this is what I want you to think about before next time. And I mean think. Just noodle this shit. Don’t post your answer, don’t comment, don’t start a discussion, just think. To yourself. And let everyone else think. And shut your fingers and your noise hole. Got it?

Tabletop roleplaying games primarily Challenge players to make the right — or the best or merely a good — choice in a given situation. That implies situations must have wrong — or worse or merely bad — choices. What does that suggest about building The Locked Door Challenge in and of itself? Because handled rightly, The Locked Door is a Challenge and handled wrongly, it ain’t. Which is the Challenge of Scenario Design.

And note that in-and-of-itself means without consideration of the monster that’s behind the door or any other thing external to the door itself.

Everything in Context

Context is the secret sauce that separates roleplaying games from most other kinds of games.

Note that I didn’t say, “Every game must include…” the way I did at the start of every other section above. That’s because, while many games do feature Context — at least to some extent — it ain’t a must-have. Games can be games without Context. Baseball has no Context. The Goal of baseball is to score more runs than the other team. And the Challenges include batting, running, fielding, pitching, and staying awake through an entire frigging game of baseball. Why is that the Goal? Why are those the Challenges? Because they are, that’s why. There’s no more Context than that.

Have you figured out what Context is yet? No. Let me give another example.

Consider the board game Century: Spice Road. In Century, you take on the role of a spice trader and you’re trying to be the richest, bestest spice trader you can be. Except, the Goal is actually to score more victory points than anyone else. The Challenges are to gather colored tokens, play cards to swap tokens for different tokens, and trade certain token combinations for cards worth victory points. The Context is a coat of paint. It doesn’t help you play the game. If you were an actual, professional spice trader, you’d have no edge over anyone else at the table.

Context is the framework by which the players understand their Goals and the Challenges they face. In games like baseball and Century, that framework doesn’t matter. Considering your actions in terms of the game’s themes doesn’t help you in any way. But, in tabletop roleplaying games, Context is a vital part of the experience. Roleplaying is about making the best choices in the Context of the fantasy world. Moreover, understanding how your Goals and the game’s Challenges and your choices fit into the game’s Contextual framework can help you overcome the game’s Challenges and predict the outcomes of your choices. Knowing, for example, that orcs are, by their nature, brutal savages and not inclined to be charmed is part of your calculus when deciding how to deal with an orc as part of a Challenge. Likewise, knowing that magical items are limited resources that can’t easily be replaced affects your willingness to use single-use items to overcome Challenges.

Moreover, understanding the Context reveals infinitely more gameplay options. You’re not limited, in D&D, to trading tokens for the cards on the table. You can attempt any action that fits the game’s Contextual framework. You can chop down a tree and make a battering ram to get you through a door because that’s how trees and axes and doors work.

This adds extra layers to the whole Scenario Design thing. It’s not enough for you to create Goals and Challenges. You have to consider, on some level, why those Goals and why those Challenges and what they — and the players’ actions — mean for both the game’s Fantasy and its Narrative. This is why I acknowledge both Fantasy and Narrative as part of the Scenario Designer’s job, but it’s also why they aren’t the Scenario Designer’s only job. In the end, Context is just one of the four legs that hold the table on top of which sits the roleplaying game.

Get it? Table top? Roleplaying game?

I’m probably never gonna do a dedicated lesson on Context, but I am going to reference it here and there a lot throughout this course. Which is kind of how it works. It’s like a filter through which you view the Scenario Design process.

That’s a Wrap

I realize this wasn’t so much a lesson as it was four vague essays about the four major ingredients that make games — and scenarios — games. Really, it’s two essays, one noncommittal hand-wave, and one note that says, “IOU one essay about Challenge; XOXO Angry.” But you can’t say I didn’t warn you this was how it was gonna be. Fortunately, we’re going to be discussing, exploring, and reanalyzing these ideas over and over and over again throughout this entire course. I didn’t even scratch the surface here.

I can’t really give you a conclusion, but I can give you a recap…

As a Scenario Designer, you’ve got to know what makes games games — and what makes them good — because your job’s to assemble disjointed game pieces into actual, playable — and hopefully good — games.

Every game must present the players with one or more in-game Goals. The Goal is what the players are trying to accomplish. Don’t confuse Goals with Motivations or with Rewards and don’t confuse Motivations and Rewards either.

Every game needs Rules. Rules define how the players interact with the game. Scenario Designers don’t write rules, but they need an expert-level understanding of their game’s rules. The written rules and the unwritten rules. One vitally important unwritten rule in tabletop roleplaying game scenario design is that the players’ knowledge of the game situation and their potential interactions with the game must be limited to what their characters can perceive and what individual actions those characters could take.

Scenario Designers must predict the likely ways the players will interact with different game situations and provide the Game Master with the mechanics necessary to resolve them. Scenario Designers don’t rely on the Game Master’s judgment or knowledge of the rules to resolve interactions they can see coming.

Every game must present its players with one or more in-game Challenges. Challenges are the situations the players must overcome through effort and skill to accomplish the game’s Goal. Tabletop roleplaying games primarily to the point of near exclusivity Challenge players to make the best choices in the situations they find themselves in.

The tabletop roleplaying gameplay experience is heavily dependent on the game’s Context. Goals, Challenges, and in-game actions must be comprehensible within the game’s Contextual Framework. That is, they must work assuming the game represents an imaginary world with the player’s avatars as living, breathing people in that world, and also assuming the game represents an unfolding narrative.

That’s it, that’s the gross structural anatomy of a game. Next time, I’ll give you that essay about Challenge.