Best practices for easy-to-run modules [+]

Inspiration is good, but isn't this post about Easy to Run modules? Not inspiration? I love inspiration, and their are parts of a module that I hope to get inspiration from, but that doesn't make a module easy to run.
All the stuff I mentioned would make scenarios easier to run. Most of what's been discussed in this thread is low-hanging fruit that's been discussed for decades. The OP asked for "any ideas" in their first post. So I provided some ideas.
LordEntrails said:
Information in Order... maybe, it depends. Yes, but... When it comes to physical locations, when possible they should be in the order in which they will be encountered. Putting the finale first so the GM can understand the module and everything else in random order doesn't make it easy to run. Most importantly they need to be ordered in a way that makes it easy for the GM to find and reference during play.
I agree that keyed locations should be presented in numerical order.

I don't think I said that everything in the scenario should be organized in random order. Why should a scenario's text assume the order in which physical locations will be encountered? I'm not saying a scenario can't point PCs in one direction or another, but why not just list them alphabetically in their own section called "Locations"? Same for the NPCs. Just have a section called "NPCs" and list them alphabetically. (I would also encourage lots of graphical elements like icons and symbols to tag locations and NPCs to make connections between them easier to remember.) GMs can just print or photocopy the pages they need for a given session. We should move past the era when "easy to run" means "don't need to flip back and forth in a book." As @Benjamin Olson said:
Benjamin Olson said:
-I think adventure presentation is overly rooted in the limitations of writing and printing before modern wordprocessing and layout software was available. It's just not that hard anymore to have footnotes, infoboxes, and other marginalia and annotations, and these sorts of things are great for allowing a main text to be brief and navigable while also permitting there to be options for a reader to delve deeper when they need to. They also are a natural place to speak with editorial voice to elucidate certain elements.
Many opinions about scenario presentation suffer unconsciously from this point of view. This isn't 1982 and people aren't publishing Champions II using typewriters and mimeographs. Why should we cling to the idea that a GM needs to have an entire physical book in front of them during a session? Design your product's pages so that sections can be printed and used without the book at the table. Tell GMs that's why your book is presented the way it is and encourage them to do that.
LordEntrails said:
Playtest... eh. Interesting to read, but makes it a pita to run.
I don't think this playtest information needs to be next to the scenario information it's describing. You could just have a separate section of the scenario called "What Usually Happened In Playtests."
LordEntrails said:
Look, I get not having to flip all over the place to find some piece of info. But if you put every piece of info in 10 tens you module is not ten times as long and now there is so much info its hard to find it. Repeat what you have to have when you have to, but if you organize well, and use links or references, then you really don't need to repeat.
The point of repetition is to reinforce to GMs how different parts of your design connect to each other. GMs need to know this so that they can make sure these intentional connections emerge during play. But I don't mean that entire blocks of text should be copied and pasted. We agree that things like links or references should be the primary tools. But things like Revelation Lists benefit from repetition in the text.
LordEntrails said:
Why? I get the idea of informing the GM so they can fill in the blanks, but no, only a few places like a plot synopsis or background section needs detailed info. But why the mook has a mace instead of a sword because they don't like the sight of guts spilling out of there enemies, uh, no.
This is another unexamined bias that I wish we could move past. It's not explaining that books have maces instead of swords because of a fear of blood. It's explaining that the mooks have maces instead of swords because some PCs might have armor that's worse against maces. That's a bad example because I'm trying to use the one you gave me. It doesn't make sense in modern D&D/OSR even if it might have made sense in the AD&D days with Armor Class Adjustments for weapons.

GMs would find scenarios easier to run if the designers spoke about the game design reasons behind why they wrote what they wrote, assuming they had them when creating the scenario. I suspect this level of intentionality and reflection is absent in most scenario design. I'd find it easier to run a scenario if a designer told me, for example, what function an NPC is meant to serve in the scenario assuming there is one.

I don't think every element of every scenario requires this approach. But the GM should be behind the curtain with the designer. That's why I think the tone of scenario writing has to change altogether. Scenarios should be written as though the designer's explaining it to folks in a forum thread who have questions about how to run it. The need for discussions about "information design" would be greatly reduced if designers spoke directly to GMs about what different parts of the design are trying to achieve at the table.
 
Last edited:

log in or register to remove this ad

I woudl like a module to think through and offer suggestions for the consequences of major ways things can not go according to intention...
This could definitely help, but notice how you phrased it: "think through and offer suggestions." That's what you do when you've never played a scenario before. Why should we expect or forgive scenario designers who haven't actually played their own scenarios? And if they have, why shouldn't they write as if they had? Tell the GMs what did happen during play. That's what I was pointing to when I suggested that playtest feedback shouldn't be hoarded.

If a designer can think of things that actual players didn't do, then that can be included too, but alongside playtest evidence rather than instead of it.
Benjamin Olsen said:
I feel like most written adventures, even ones well written to run (for most people), are too afraid to just come out and tell me narratively why elements are in them and what their narrative purpose actually is. Since I'm going to remake everything to my tastes I'd appreciate a note here or there when something is a keystone element and tampering will have widespread reprecussions. And, while I don't need commentary on everything, when the inclusion of something as presented is the result of some sort of complicated calculus weighing multiple goals a note explaining would help me appreciate it's significance and tamper responisbly.
Absolutely. I'd love to see a world where scenarios present the designer's outline before they stared writing the "proper" text. That's the level of transparency that would make running a scenario easier. This is what I'm pointing at when I say that GMs should understand the "why" of a scenario's design.
Benjamin Olson said:
Yeah, I half wrote out another point about how really adventure design is too rooted in the limitations of physical books, and realistically a lot of small-time adventure authors should lean more into the fact that their work will overwhelmingly be consumed digitally, but having only consumed a few rpg products purely digitally and not knowing what print-on-demand sales figures look like for primarily digital products, I worried I was too out of my depth on that one.
Real advances in scenario/information design won't be made until RPG scenarios are web pages. In the meantime, we can get closer with paper.;)
 



Yeah, I half wrote out another point about how really adventure design is too rooted in the limitations of physical books, and realistically a lot of small-time adventure authors should lean more into the fact that their work will overwhelmingly be consumed digitally, but having only consumed a few rpg products purely digitally and not knowing what print-on-demand sales figures look like for primarily digital products, I worried I was too out of my depth on that one.
One of the big challenges I as a small time publisher has with the digital/physical approach is you basically have two completely different products you have to create. It's a lot of work to have a digital version that hits all the dots for what a digital user wants and a completely separate version that is designed for print. For example, you really need a different font for each, and when you start doing that, you shift around the layout completely. I (and I'm sure others) do our best to try to find a happy middle ground with two different versions.

Heck, with Twilight Fables, I also did a dyslexic friendly version, and a no-background version. But doing that for every project? It's a lot of time and money. Things a small time publisher might not have.
 

A big step forward would be presenting your scenario as if you expect the GM to write directly on the pages. Create checklists that can be checked off or annotated, put checkboxes next to NPC/monster spells to indicate they've been used, present hit points with specific space for GMs to write as they decrease, make a table with all NPCs on it and space to track how they feel about the party. RPG scenarios should be more tool-like.
 

A big step forward would be presenting your scenario as if you expect the GM to write directly on the pages. Create checklists that can be checked off or annotated, put checkboxes next to NPC/monster spells to indicate they've been used, present hit points with specific space for GMs to write as they decrease, make a table with all NPCs on it and space to track how they feel about the party. RPG scenarios should be more tool-like.
I agree with what you just said. While I would never write in a published hard copy module, the pdfs that I have printed out are filled with notes. But I've noticed that the early TSR modules suck for white space!

And since I'm here, for all that is holy in the world, I wish publishers would stop with backgrounds in their pdfs. At least set them as a layer that I can toggle off when I want to print something out.
 


I have always wanted to build an adventure with pop out text boxes that you can either open or just hover over for as long as you need it. I am a land surveyor and civil engineer and one of the towns we work in has all their regulations in a website like this and I always thought it would be great for running modules.
I love this idea. I've added it to the Feature Request list. Would be incredible to have a linked window pop up on hovering instead of fully opening the linked window.
This is another unexamined bias that I wish we could move past. It's not explaining that books have maces instead of swords because of a fear of blood. It's explaining that the mooks have maces instead of swords because some PCs might have armor that's worse against maces. That's a bad example because I'm trying to use the one you gave me.
I'm not sure it's unexamined. Horrible example I admit. Can you provide one that would be good? Because I can't think of any.
GMs would find scenarios easier to run if the designers spoke about the game design reasons behind why they wrote what they wrote, assuming they had them when creating the scenario. I suspect this level of intentionality and reflection is absent in most scenario design. I'd find it easier to run a scenario if a designer told me, for example, what function an NPC is meant to serve in the scenario assuming there is one.
Maybe? My approach is in the background section and/or plot synopsis. To me, that's where the writer communicates to the GM what the idea of the scenario is and what's going on etc.
But the GM should be behind the curtain with the designer.
Eh? Why? I agree its a valuable idea, but it doesn't make for less prep.
It's a lot of work to have a digital version that hits all the dots for what a digital user wants and a completely separate version that is designed for print. For example, you really need a different font for each, and when you start doing that, you shift around the layout completely. I (and I'm sure others) do our best to try to find a happy middle ground with two different versions.
It doesn't have to be that much more work. It is more, but things like fonts are near trivial to change if you are using Styles. I also find it much easier to create in the digital format and export to a print format and then style the print format for print. XML and style sheets make it pretty easy to change styles between formats.
 

In addition to just cutting down on the verbosity of background/lore, I could see it being useful to group information by how hard it would be to come by. E.g., "Virtually unknown" to "Common knowledge". This could map to DCs required for knowledge checks (which I personally hate) or for the general difficulty of finding somebody who would know.

Another way of handling this would be a rumor table rolled with multiple dice, so that there's a probability curve. The rarest information on the ends, the common knowledge in the middle.
 

Remove ads

Top