Let me date myself. I have to date myself; no one else will. Hahaha. Oh God, I’m so alone.

All right, the gods of comedy thus satisfied, let’s continue. A long time ago, if you wanted to play a role-playing adventure game over the Internet, you couldn’t just log in to World of Warcraft or Elder Scrolls Online or whatever else the kids are playing these days. You just didn’t have things like graphics and high-speed internet. The best you could do was to send long strings of text. So, your adventure role-playing games online looked like this:

Pig Farm
You are standing ankle deep in pig muck beside a small, one-room hovel made out of the curving ribs or tusks of some impossibly big monster and stitched together canvas or leather or whatever. You don’t know. It’s standard orcish construction. To the east, a trail winds across the hills to the road to Durotar. To the west, there’s nothing but open plains. To the north, you see the bank of a river.

Exits: East, West, North
There is an Orcish Peon here, an exclamation point glowing over his head.
There are 3 pigs here.
There’s a Dagger of Vendor Trash here.

What do you do?

I s$&% you not. That was World of Warcraft back in the day. You could type things like “go west” or “kill pig” or “poke Peon.” And if there was another player in the same location as you, you could interact by typing “/say ‘Don’t touch that dagger, it’s mine” or “/emote breakdances in an anachronistic and silly way, belying the apparent fantasy tone of the game.”

Now, this framework was built on an earlier framework: the text adventure game. Once upon a time, singe-player video games didn’t even have the power to have graphics. So, you had text-based adventure stories like that. The first was a thing called The Colossal Cave Adventure. And then came Zork. And then Roberta Williams and her husband Ken invented the idea of graphics and bulls$&% deaths and Kings Quest was born. But I digress.

The point is, when I graduated high school, the 56k modem was the best you could get. And that was cutting edge. We were still dialing up to America Online at the breakneck speed of 14,400 kilobytes per second. For reference, if those numbers don’t mean anything to you, your current internet speed is probably somewhere around 1,500 times faster.

Actually, that isn’t the point. The point is, as I entered college, I discovered the internet. And, more importantly, I discovered MUDs, MUCKs, MOOs, MUSHes, and a whole bunch of other acronyms that were all basically the same thing. A MUD was a multi-user dungeon. Later, it became a multi-user dimension. And I got addicted. Super addicted. Like, problem addicted. I don’t want to discuss it.

Eventually, I graduated from user to builder to admin to occasional coder. All of those clever terms just mean that I was helping to administrate and build and program these things. And that’s when I learned something really fascinating. Something that is of tremendous use for any game master who wants to design an adventure. It was a way of thinking about game design. And about computer programming. Computer nerds call it “object oriented design.” I call it “how to build a scene.”

Scenes and Rooms

So, the basic architecture of a MUD (or MUSH or MOO, they are all the same thing) is the idea of a room. A room is a chunk of the world a player can be in. Basically, it’s like a room in a dungeon. That Pig Farm up above? That’s a room. That makes sense, right? The whole structure of the game is broken down into rooms. But there’s more to it than that. A lot more.

First of all, let me take the moment to remind I’ve written other articles before this one. In this case, I pointed out that every adventure can be thought of as a dungeon, as a series of rooms. Of course, we call the rooms ‘scenes.’ But scenes and rooms can be the same thing. A scene is just a chunk of the game where the players are.

Uh huh. See where this is going?

Now, what’s really interesting is that, when you get down to it, the entire goddamned MUD – the whole entire multiplayer world – was essentially just a big old document. A text file. Specially formatted. It was just a list of rooms. And each room had a very specific format so the computer could read it and find the data. Every room, for example, had a name and a number. The number was just to abbreviate the name of the room. And every room had a description. That’s the text a player saw when they entered the room and looked around. And the room also contained exits. An exit was a little line of text that gave the name and direction of an exit and told you where it went to. And the room could also contain objects that you could interact with. And the room could also contain NPCs. We called them mobs. Some you could fight and some would sell you stuff and some would give quests or clues. It was all the same.

So, a room was just a container for the stuff that was in it.

And the MUD was really just a list of interconnected rooms.

And if you understood the format, you could create all new rooms and fill them with stuff.

Now, sure, when you built an area of a MUD, you tended to start with a map – a flowchart – so that you could keep track of how the rooms connected. Because linking up the exits could get tricky. Kind of like how linking up the SCENES in an adventure can get tricky but a flowchart or map makes it much easier. And then you had a list of things you had to make sure you did to make sure the room worked right. Make sure it has a name, make sure it has a description, make sure it has exits, and so on.

And that brings us around to how all of this information can help you build good adventures. Once you’ve figured out how the scenes in your adventure join up and where your adventure starts and where it ends, you have to start building the scenes. And, as varied as scenes can be, they all have a very similar anatomy. There’s things that you need to figure out for every scene. A checklist, if you will. And if you know that format, you can build an adventure as big as you want.

This is Not Prep Instruction!

Okay, now let’s be clear here. Because I’ve talked before about how it’s impossible to teach someone how to prepare their notes to run a game. And I stand by that. I’m not telling you what things you have to write down and how to write them down. I’m just telling you how a scene in an RPG goes together Maybe you need to write down your establishing shot. Maybe you don’t. Maybe you need notes about an NPC. Maybe you don’t. I’m just telling you what a scene needs to function. If you can do it off the top of your head, good for you. If you need to write notes, write them. That’s on you. I’m not your f$&%ing mother. This is adult time. This is university. I’m not going to tell you how to take notes. Got it?

For that matter, I’m not telling you that you HAVE TO plan any of this before the game either. Improvisation is fine. You’re going to have to do it eventually. Those jacka$& players will eventually f$&% up your road map and you will eventually have to invent scenes out of thin air on the fly. That’s fine. Remember, improvisation is just designing on the fly. You still have to design if you want your improv to be any f$&%ing good.

A Note on Mobs and Objects and Scope

What I’m covering right now is Scene Building 101. Basically, here’s how to build a nice, self-contained scene. But, as I noted before, a scene is a container where you can put stuff. For example, I noted you can put pigs and quest givers and knives in your scene. And, in the parlance of the mud, we called those things mobs and objects. Mob was short for mobile object. A mob was just a thing that could move around and do stuff. Like a pig or a peon or a wolf or a dragon.

The important thing to understand though, is that mobiles and objects weren’t PART of the room. They were external things you could PUT in the room. Why is that important? Well, because RPGs are a little more complicated. But not much more. The same concepts exist. But they have to be a little more versatile.

For example, the Innkeeper of the Lusty Winch or the Rusty Wench or whatever? Well, that particular dude or dudette probably IS a part of any scene that takes place in the Lusty Winch. They don’t move around. They don’t wander. So, when you design a scene in the Rusty Wench, the Innkeeper is a part of the scene. They are like the tables and chairs. They are contained entirely within that scene.

But, if the PCs are being hunted by an assassin from the Guild of Perfectly Innocent Businessfolk, that assassin probably IS moving around. They MIGHT show up in the Rusty Wrench. Or they MIGHT show up on the Canals of Schmenice or they MIGHT show up in the Library of Secrets.

I bring this up because even though I said I wasn’t going to tell you how to organize your notes, I’m going to give you a piece of advice RIGHT HERE. The advice has to do with something called “scope.” If something exists only as part of ONE SCENE (like that Innkeeper), you can shove the information you need for that something right in the SCENE ITSELF. But if something is going to pop up in more than one scene, you might want to have a separate set of notes. The assassin might be on a separate piece of paper. And then, you might refer to it in your notes. Something like “there’s a 30% chance Guido N. Nunzio, Guild Assassin will be here disguised as Nunzio N. Guido, Legitimate Businessman.”

What’s in a Scene

Now, here’s where things get tricky. Before you can start planning your adventure, you have to make a decision about what your scenes represent. And that has to do with the Metastructure of Your Adventure. Now, don’t panic. I only used that phrase because I like using overly complicated phrases. And also because I love using the prefix “meta-“ for everything except the one thing every shrieking GM idiot uses it for. That is, “yelling at players for making smart decisions.”

See, I drummed it into your head that every adventure is a dungeon. It’s basically just an interconnected map of scenes. Right? But that was an analogy. That was to help you understand the idea of scenes. Now, we have to discuss a subtle point: some adventures really are dungeons. That is to say, in some adventures, scenes ARE just locations. They are just rooms where stuff can be. In other adventures, scenes ARE events. They are things that happen. And the same LOCATION can play host to multiple scenes.

And the distinction really DOES matter. It doesn’t HAVE TO matter much. But it does make a little bit of difference. The major difference is that an adventure where the scenes are locations tends to have a lot of scenes that are really minor, piddling little things. The room with two exits is a scene in which the party has to decide which exit to use. And those sorts of empty room scenes tend to be rare in adventures where the scenes are events.

The thing is, a scene like “the room with two exits” requires almost no information. Just showing it on the map is enough to tell you everything you need to know. There’s a room. There’s two ways out. The party has to choose one. Done and done.

So, before you start planning your scenes, you want to decide whether your scenes are actual physical locations with physical exits or whether they are events with transitions leading away from them. And that will affect some of what you write down.

Once you’ve gotten that out of the way, you can start putting together all the things that make a scene work.

Name

This might sound really silly. And, technically, you can skip it. But I’d be a s$&% GM mentor if I didn’t mention something I figured out a long time ago that lubricates the creative process of designing scenes and adventures. Give your scenes a name. The name can be the name of the location or a completely pedantic description of what happens there. Or it can be artful and creative if you’re so inclined. It doesn’t matter how you name your scenes. But give your scenes a name.

Locations might be the Sentry Cave, the Moonlit Grotto, the Cave of Massive Mushrooms, the Lizard Den, Baltac’s Trading Post, the Wusty Lench Inn, the Town of Durotar, and so on. Events might be the Battle at the Gate, Meeting the Innkeeper, the Shopping Trip, Defeat the Lizard Mommy, or Chasing the Assassin. Trust me. Name your f$&%ing scenes. It helps more than you think it does.

Purpose

The next thing to figure out is WHY this scene exists. What is it doing in your game? If the scene is just a scene, what will the PCs get out of it. Will they learn about the dungeon? Will they meet an important NPC? Will they have to make a decision? Will they get some exposition? Will they have a chance to choose between making a friend or making a foe? Will they have a chance to rest? To shop? To gain resources? What the f$&% is this scene for? If the scene is an encounter, what’s the dramatic question? What are the PCs trying to accomplish? Are they overcoming an obstacle to continue on their way? Are they here to slay an enemy? Are they trying to gain information? Remember, an encounter can be anything as long as the outcome is uncertain and there’s something in the way.

You need to know what the PCs will get out of the scene. I’ve already talked about the different reasons why a scene might exist when I talked about how adventures are made of scenes. That list is pretty complete, but it is not meant to be exhaustive. Feel free to invent your own purposes.

Also, be f$&%ing specific. There is no use in being vague when you’re designing an adventure. Who the hell are you trying to keep in the dark? Yourself? Don’t say “gain information.” The purpose of the scene is “to learn the weaknesses of the pigs of Durotar.” Or “to introduce the players to the Legitimate Businessman who will later turn out to be the villain.” Or “to give the players a chance to interact with Lady Aralayne and to establish a relationship for better or for worse with her.”

DO NOT CONTINUE if you can’t explain why your scene exists. There are almost NO bad reasons for a scene to exist. But NO REASON is a bad reason. It’s perfectly valid to give the players a chance to interact with a world element just for the sake of it (that’s a form of exploration, after all). But you need to know that’s why you invented the scene.

Setting

Where does this scene take place? If the scene is a location, this question is easy to answer. But the question can get surprisingly difficult. For example, you can have a single scene in which the PCs explore the Town of Durotar. The setting, in this case, is the entire Town of Durotar. You need to decide how far afield your scene can wander.

Now, here is where you can be a little descriptive. When you are actually running the scene, you will need to be able to tell the players enough information so they can visualize the scene. And, in order to do that, you need to be able to visualize the setting yourself. If the setting is a single cave with an open chimney high above that lets moonlight fall on the tranquil pool, well, you have your description. If your setting is the entire Town of Durotar, you’re going to have to have an understanding of the town as a whole as well as individual locations within it. Think of it like having a camera. You can get in a helicopter and take a wide-shot of the whole town where the chase scene or exploration is going to take place, but as the scene moves around the town, you’re going to need to zoom that camera in to the right level of detail.

And this is also where I can’t tell you how much to write down. Write down as much as you need to conjure a picture of the setting in your head so you can describe it to your players. If that’s a prose description, fine. If it’s a few adjectives, also fine. If it’s just a name, also fine. I – personally – can squeeze a lot of flavor text out of “Moonlit Grotto” or “Windswept Bridge” or “Warrens of Durotar, City of Orcs.” You might need more.

Interactive Bits

So far, your scene is just a raison d’etre and a place for it to etre in. That’s a “reason for existing” and a place to “exist” in if you’re not cool and smart like me. But that isn’t enough for a scene. Just like a room in a MUD, there’s got to be some s$&% IN the room for it to be interesting.

First of all, if the scene is an encounter, you want to put some sources of conflict in the room. Remember those? Those are things that stand between the PCs and their goals AND the reasons WHY they stand between the PCs and their goals. It’s not enough to drop some orcs in a room. Orcs are not a source of conflict. WHY is there a potential conflict? Because the orcs are defending their lair? Or because the orcs want to rob the PCs? Or because they want to eat the PCs? A source of conflict is not just a WHAT, it’s a WHY.

Beyond that, though, the interactive bits are the things in the scene that the players can play with. NPCs, weird runes, magical gates, treasure chests, levers and switches, bridges, statues, basically anything that the players can f$&% around with is an interactive bit.

Interactive bits serve a purpose. Usually, they serve the purpose of the scene. If the purpose of the scene is to let the players learn about Durotar Swine, you need a book like The New Swineherd’s Guide to Swine. Or you need a swineherd who can give the PCs the information they need. That might seem crazy obvious, but you’d be amazed how many people get as far as “this is the Pig Farm and the purpose is to teach the PCs about pigs” and don’t think about HOW the PCs are going to get that information.

And this is where things can get CRAZY COMPLICATED. And that is why you need to understand the purpose of the scene. Because you can go very, VERY overboard when you start building interactive bits.

For example, if the PCs are NEVER going to get into a fight with the swineherd or the swineherd is so weak that he could NEVER threaten the PCs, you don’t need combat stats for the swineherd. The swineherd is not an encounter. He’s just a source of info. If the PCs try to kill him, they will succeed. All you really need to know is the information the swineherd will impart. That’s all.

Of course, you also need to be able to portray the swineherd if you want to act out the scene. It’s fine and dandy to just say “the swineherd is willing to answer all of your questions. After an hour of conversation over bacon tea and bacon buns, you’ve learned the following information about Durotar Swine… blahdy blah blah.” But if you want to inject a little life into the world, you might want to give the swineherd some personality. At the very least, you might want to give him a silly accent and some homespun metaphors.

And THAT is why it’s really important to establish why the scene exists. If the scene is PURELY about exposition, you don’t want to spend much time on it. But if you want the scene to “let the PCs to learn about swine and also to interact with the world,” the swineherd might need some extra fleshing out. And if you want to “introduce Bork, the Swineherd who secretly wants to be an Exotic Dancer and also let the PCs learn about swine,” then you also need to establish hopes and dreams for Bork.

So, as you put interactive bits in your scene, think about what purpose(s) they serve in the scene and in the game as a whole. And think about what the scene needs. In a negotiation, a table is just a table. Something to put drinks on and pound on for emphasis. But in a combat, a table is an optional +2 bonus to AC against ranged attacks if it’s flipped.

Beware of overthinking and underthinking. Don’t stat out every shopkeeper. But don’t skip giving the shopkeeper a personality if you’re planning to bring him to life.

In addition, DO NOT TRY TO PLAN EVERYTHING. In a tavern, it’s a given that there are tables and chairs. In negotiations, people will put drinks and pound fists on them. In a fight, people will jump on them and flip them for cover. But people might do other things with tables. They might stand on them to make a rousing speech. Or break a leg off for an impromptu club. You can’t possibly imagine every object in every scene and every use for it.

Establishing Shot

And now we’re going to rip off a bit of film terminology. We’re going to refer to the establishing shot. In a movie or television show, an establishing shot shows the location where the next scene is going to take place. If you every watched Seinfeld or Friends, that shot of the outside of the diner or the coffee shop? That was the establishing shot. It was a quick visual statement to the audience: “we’re here now, in this diner or coffee shop.”

In RPG terms – well, okay, in MY terms – the establishing shot is the FIRST bit of description the players get about a scene. When they transition into a scene, the establishing shot is basically the flavor text. “Here you are, in this place, now what do you do?”

The establishing shot establishes EVERYTHING the players know about a scene. And you need your players to know several things about the scene. They need to know their goal or purpose, they need to know the setting, and they need to know what explicit interactive bits exist. Your establishing shot has to cover ALL OF THOSE. Don’t skimp.

“You’re in the one room hovel of the swineherd. It’s a canvas tent with giant monster ribs supporting it. The smell of bacon rises from the cookpot above the firepit. The dirty, foul-smelling orc swineherd offers you cups of bacon tea. ‘So, you want to know more about Durotar swine, do ya’ now? Well, sit down and I’ll rustle us up some grub and you can ask your questions.’ You notice, draped over one chair, is a sequined costume and a feathered boa. There’s a sewing kit beside it.”

Done and done.

You’ve told the players where they are, introduced the NPC – who they can ask questions of – and introduced the costume, which the players can examine or ask about. There is also a firepit, in case the players want to burn the costume because players are a$&holes. You didn’t mention the cot or the spice rack or the small chest that holds the orcs meager belongings. Because they are just background elements right now. If they become important, you can bring them up later. For example, the players might ask “can I root around the room to find valuable stuff to steal?”

Because players are a$&holes.

If the scene is an encounter, you also want to call attention to the source of conflict and explicitly state the goal in some way.

“The path continues through the forest and presumably on to the library, but standing in your way are four hungry orcs. ‘Looks like we’re gonna eat well tonight, boyos,’ says the largest orc as he brandishes an orcish cleaver-axe.”

Hidden Interactive Bits

Sometimes, you have interactive bits in your scene that aren’t immediately obvious. That is to say, you have hidden interactive bits that the players have to discover for themselves. For example, a scene might have a hidden chest. The hidden chest is an interactive bit, certainly. But, you don’t call attention to a hidden chest. You wait for the PCs to search the underbrush or go rooting around under the bed. If they don’t, they never find the hidden chest.

Hidden interactive bits can be anything. A hidden chest, a trap, an assassin, a specific book on the library shelf amongst hundreds of others, and so on. In a scene in which the PCs are exploring a city, a hidden bit can be a specific location or landmark. Hidden bits are anything the players COULD interact with that you won’t reveal until they meet some specific condition.

If you’re including a hidden interactive bit in a scene, apart from figuring out everything you need to know based on what it does, you also need to figure out how the PCs can discover it. For example, they might simply notice a pit trap if their Passive Perception is high enough. Or they can discover it if they search for traps and roll a Search check (DC 25). Or they might discover it by walking over it and setting it off.

It helps to understand HOW the hidden bit is hidden. You can sit there and say “the trap requires a Search DC of 25 to discover or it goes off if the PCs walk over the carpet,” but if you know that it is concealed under the carpet, then you also recognize that if a PC simply pulls the carpet aside, the trap will be revealed. No roll required. But then, this goes for EVERYTHING. The more you know about how it works in the world, the more prepared you are to handle any action the PCs might take with regards to it.

Goals, Prizes, and Takeaways

Many scenes give the PCs something. It might be information, resources, treasure, magical blessings, clues about the murder case, and so on. Most of this stuff is defined by the purpose of the scene, but sometimes, there’s optional extra stuff the PCs can come across. After fighting the orcs, for example, if the PCs loot the bodies, they can find some coins and armor and a book about swine husbandry.

All of that crap needs to be planned too. That’s part of the scene. So you need to decide what the players WILL leave the scene and what they MIGHT leave the scene with and HOW they will acquire it. Write out the information they learn about Durotar Swine. Figure out how much money the orcs have. Is there a magical item in a hidden chest? What’s the item? What does it do? How much is it worth?

Outcomes, Exits, and Transitions

And finally, you must resolve the question of where the game goes once the scene is done. That is to say, where do the exits and transitions go.

Some transitions are dependent entirely on the outcome of the scene. “If the PCs win the battle with the orcs, they can continue along the trail. If they lose the fight, survivors are dragged unconscious to The Orc Camp and imprisoned while a big cooking fire is prepared.”

Some transitions and exits depend on player choices. That is to say, once the scene is over, the players have a choice of where to go next. After they defeat the spiders, they can leave by one of the three hallways that lead out of the Chapel of Way Too Many Spiders. Once they finish questioning the witness, they can go visit the suspect or they can take the evidence the witness gave them to the crime lab for analysis.

In an open adventure structure, the general assumption is that the players can go anywhere from anywhere. So, in such a structure, you don’t have to specify where the PCs can go unless something has changed in the structure of the adventure. For example, in an open adventure structure, if the PCs are captured by the orcs, suddenly, their options for where they go are limited to “the orc’s food pens” or “the afterlife” and those are determined by who made how many successful death saves.

If the players can choose where to go next, you have to figure out how the players know where they can go. In a dungeon room, it’s easy enough. There’s doors or halls or stairs or tunnels or something. The exits are clearly marked. But if the scene is an investigation, you have to decide how the players know about the possible transitions. Now, this often gets woven into the narrative, but it’s also very helpful for the GM to state the possibilities at the end of the scene as part of the transition out of the scene. “After you finish talking to the witness, where do you want to go? He gave you a suspect’s address, but his evidence needs to be analyzed at the crime lab? And, of course, you still haven’t visited the police chief.”

Further complicating this transition business is the idea of hidden transitions. Just like hidden interactive bits, hidden transitions are ways out of the scene that you DON’T show the players unless they fulfil some condition. Secret doors are the obvious physical example. But a specific piece of evidence, like a matchbook from the Nightclub of Respectable Gentlemen, might provide a transition opportunity only if the PCs make the right search checks. An NPC might only give access to certain scenes if the PCs fulfil other conditions first.

In the end, though, your scene needs exits. It needs ways out. North, east, west, whatever. And they need to be communicated. And, if they are hidden, you need to decide what the conditions are whereby they will be revealed.

The Basic Code

In the end, that’s the basic code for a scene. Name, purpose, setting, interactive bits, establishing shot, takeaways, exits. That’s how it all goes together. That’s what every scene needs.

But, like so many things, the devil is in the details. It’s in designing the little interactive bits and takeaways and exits and setting where things really shine. The basic framework for a scene is pretty boring. It doesn’t do anything interesting. It’s just blanks to fill in.

From here on out, this whole “adventure design” thing gets pretty nitpicky because it’s all exceptions from here on out. But that’s good. It means I have a lot of content to write for you f$&%ers. Happy reading.