Elements of a Key 2

 Welcome to Part 2 of "Elements of a Key". I actually had this totally written when I posted Part 1 and intended to post it the following day, but I'm terrible at blogging so its posting was delayed by ~7 months.

Last time, I cut up all the various types of information that a GM might need when running a key--from immediate things like the sense impressions the PCs receive upon first encountering the key to more conceptual things like NPC motivation or instincts. These elements need to be decided on at some point, either when a module is being written, when the GM is prepping, or improvisationally mid-play.

Let's take a closer look at which elements are best suited for being nailed down during which stages of prep and what the trade-offs are of each way of doing things.

The Stages of Prep

There are, as stated above, three main stages an adventure goes through:

• Being written by the module's author. This is where the text of the adventure is created.
• Being prepped by the GM. This is where the GM puts the adventure in their head and thinks through how they'll actually run it.
• At the table. This is where the GM and players run the adventure, and where the information of the key actually gets used.

Obviously, not all steps will be reached every time. For a GM running their own adventures, the writing/prep stages are one and the same. For someone trying to run a module straight from a book, the prep stage gets skipped. In many cases, we end up reading modules that we will never actually run. For convenience, we'll talk as if all three stages are occurring.

Any unit of information about the key that comes out in play gets created during one of these three steps. So, what are some of the dynamics at play that make some stages better suited for certain elements of a key than others?

There are two big dividing lines here: before play/during play and invented by author/invented by GM. 

Before Play vs During Play

Meaningful vs Trivial

One of the easiest and most obvious dynamics is that you should try to save your prep for things that matter. You only have limited time and ink for writing and prep, so facts about the key that have no impact on gameplay should be saved for mid-play improvisation.

The colors of the curtains, the names of background characters, how many skittles are in the jar on the wizard's desk--these are unlikely to have any impact on play, so it's safe to put those all firmly in the "at the table" stage.

I'd argue that lore/backstory also fits into this category, as well. The fact that the bartender was an orphan who was adopted by a kindly old priest is also likely to be trivial to play, unless that kindly old priest is sitting on some leverage-point in the adventure. These details are (marginally) harder to improvise at the table than "color of the curtains"-style facts, but they're still not a good use of a module-writer's limited wordcount.

Fair vs Unfair

See: BLORB Principles

Similar to the above, one of the main reasons it's important to prep keys rather than improvise them is to avoid arbitrariness. Anything about the key that is a significant danger to the players should be established before play, as should anything that is an obvious and significant benefit to the players.

Once the players are already embedded in the adventure, it's impossible to be fair when making a creative decision. If the players are hurt and looking for an exit and the next room has not been prepped, it's very difficult to objectively and fairly decide whether the room contains a monster or the exit. If the GM makes these decisions in the moment, the game leans towards playing to the GM's whims and sympathies instead of the situation itself.

Enmeshed vs Independent

It's difficult to improvisationally create ideas that span multiple keys, but it's easy to think up one-offs on the fly. The more that an element in a key is tied to other elements in other keys, the better a fit it is to be pre-written.

These connections can either be explicit (the cult leader has the key to the squid room) or implicit (there's a metal lock in room 3, a glass bottle in room 5, and a pool of high-power acid in room 8). If anything, the implicit connections are the harder ones to improvise on the fly, but they're also some of the ones that can really make a module pop; one of the main things I think about when writing a dungeon is trying to ensure that there are as many of these latent lines of potential quietly seeded through it as possible (with trust that the players will find even more I hadn't thought of).

Bespoke vs Cliché

See: Against the Wicked City - Conceptual Density

There's an autopilot default to how any given key element will get unpacked at the table. The goblin yells "Intruders!" and attacks. The dwarf loves ale. The secret door is opened by a concealed panel. When the GM doesn't have any better ideas (due to being put on the spot, inexperience, fatigue, etc), this is how the key gets introduced. Cliché has gravity, and without active effort improvisation naturally flows downhill towards it.

The more cliché an idea is, less useful it is to include it in a key's written description; if that's how the key was going to get unpacked anyway then you might as well save the ink. A good module helps nudge the GM out of their habits and towards modes of play they wouldn't have tried by themselves.

Hard vs Soft

I'm a believer in the "cruel prepper/generous GM" style of OSR play--I tend to prep overwhelming odds and difficult problems for my players to encounter, but then tend to default to a 'say yes' style of responding to their hairbrained schemes mid-play. If I want there to be some hard barrier to player success, I generally need to prep it beforehand because my mid-session rulings tend to lean permissive. If the wizard lab is shielded from scrying and teleport spells or if the guard absolutely will not settle for a bribe of less than 100gp, I need to prep those facts before play begins.

Related, I find that if I'm not laying down hard NPC desires and motivations beforehand it becomes easy for scenes to stall out if the players opt for non-combat. NPCs who want things and are willing to use the players to try to attain them are great for driving forward play.

Sublime vs Ordinary

Not every element of a key needs to be interactive; some elements exist to make the players (including the GM) feel like they're on the edge of something much greater and bigger than themselves. Mountain-sized corpses of dead gods, abstract Lovecraftian horrors, or even just a lovingly described ordinary situation can provoke an emotional response in a way that lives outside of the action players can actually take.

This may live in the form of well-crafted prose (Cool Words from last time), illustrations, or simply resonant concepts. If you think you're onto something that will have an impact on the GM or players when they encounter it, that makes it more worthwhile to nail it down before play.

For each of the above, the distinction is between the 'improvised' layer of play and the 'prep/writing' one--they're all dynamics that make a certain element of a key a better fit for either being determined beforehand or improvised at the table (and therefore omitted from the key's written form).

There's a second distinction that's equally important but somewhat less discussed, however--the line between a module's written text and the GM's prep.

The contents of a module don't magically summon themselves into play; any idea written in a module must be read and internalized by the GM. This creates a strange dynamic where the best option is not, often, to make all the prep-important information in the module explicitly stated in words on the page; leaving some elements of the module implied can actually help the GM internalize the module's scenario by making them active participants in unpacking its implications and thinking the scenario through. These omissions also, of course, can save page space and make the module less onerous to read.

Let's look at a few dynamics that can help determine whether an element is best made explicit in a published module, implicitly suggested, or handled entirely by the GM. 

In Module vs Prepped

Concrete vs General

Nobody knows how a key is going to play out. If there's a goblin in a room, the players might try to fight it, befriend it, evade it, pretend to be a goblin at it, seduce it, sacrifice it on the altar in room 7, and so on. The GM needs to have an understanding of what the deal is with each element in the key, to the point that they can run with any of these unexpected directions play might take.

So, that means that it's better for a module to give generalized descriptions than concrete one-off actions and events, right? "The goblin is crass and violent" is better than "the goblin sits in filth, idly tearing the wings off flies"?

Actually, no--concrete details are usually going to be better overall. The GM does need to have a general sense of that goblin's personality, but they can get that just fine from concrete and specific actions. Showing, rather than telling, does double duty--it both communicates the general while giving the GM actual examples to use in play. If anything, the concrete examples convey more subtle detail for the GM to play off of than a general personality trait would.

This dynamic reverses somewhat with player-driven action, however. Describing a chain of "if the players do A, the result is B" is generally less usable than simply describing the key's contents as they are. "The basin is full of strong acid (1d6 damage/round)" is stronger writing than "If the players touch the green liquid in the basin, they take 1d6 acid damage."

Fun to Prep vs Work to Prep

Coming up with cool ideas is fun. Nailing down exactly how everything fits together, making sure it's all internally consistent, filling in mundane but important details, and testing it to make sure it generally plays enjoyably is work. Ideally, when I buy a module, I'm buying it to take work off of my plate.

That's often not how modules get written, of course. Many of the most beloved modules out there are almost entirely cool ideas with very little help in converting them to use at the table. This makes sense--cool ideas are much more inspiring and fun to read than mundane details, and most people experience most modules primarily as inspirational readings. God knows I've read way more modules than I've been able to get to the table.

Still, the dream is there--work that needs to get done, details that need to be thought through, and dynamics that need to be designed should be written by the module writer instead of being foisted on the GM.

Fussy vs Intuitive

Modules live double duty as inspirational art and reference documents. If the module includes complex or data-driven info, it's nice to provide ways of making that information easily referenceable. Monster statblocks, wandering encounter tables, exact coin counts in treasure hoards, complex procedures--these are all hard for a GM to hold in their head, and so they should be written in the module. Bonus points if they're presented in a form that makes them easier to find mid-play without sacrificing readability.

System-Specific vs System-Agnostic

There are a lot of systems out there, and if you're publishing a module for a vaguely OSR audience you have no idea which system they'll be using. Is it better to tailor a module to a specific system or to leave all the hard mechanics up to the GM to come up with during prep? To what extent should you use mechanical language vs stick to pure narrative description?

All methods are reasonable, but I personally prefer fully supporting one system. I feel that it's easier to convert from one system to another than it is to come up with stats out of nothing. At a minimum, I find giving the relative level/HD of NPCs and monsters helpful in avoiding arbitrariness.

Page-Turner vs Dry

Modules are a lot of reading to prep. It's nice if you can write them in a way that makes them fun to read. Elements that enflame the GM's curiosity, that keep them excited to keep reading, justify their own inclusion in a module. Conversely, drain the fun from reading a module should be avoided.

Of course, this dynamic often doesn't align some others above. What's fun on a first read isn't always what's useful in a reference document. None of these dynamics line up perfectly aligned with the others--every author must choose which to emphasize and which to sacrifice in a given work. There's no one golden style for module-writing, just an endless series of trade-offs. 

This post is all still very theoretical, but I hope reading through it has been a good chance to reflect on some of the specific ways that modules are useful. Following these dynamics blindly will almost certainly not help you write better keys--the only thing that can make you better at writing is gaining experience writing and reading. My hope is that by thinking about these elements and dynamics as you study existing keys (either written by others or yourself), you can sharpen your writing senses more quickly. Theory never replaces practice, but it can augment the benefits of practice.

I have a rough sketch of a third post in this series where we can look at existing modules and see how they navigated all of these elements and dynamics. Will it be posted this year? This decade? Ever? Only time will tell.