No tricks today. I’m going to give you the follow-up I promised. More on fixing module presentation. And since this is the second part of a two-parter that already had a good Long, Rambling Introduction™, I’m going to use the space normally devoted to that bulls$&% to give you a little Learn to Play Module update and preview. And to answer a few questions.

And if you have no idea what the f&!% this is all about, check out my previous article on this topic.

The Fall of Silverpine Watch Project Update

Just to be clear, I’m writing this on October 21. I mention that because I know you are definitely not reading this on October 21. According to the timeline I set out two weeks ago, I should have finished the FoSW draft and be well into the final revision. Guess what? I’m not. Mainly because I had to go back and redraft a bunch of the module to conform with my changing ideas about presentation. I’ll be wrapping up the draft text this weekend and then I’ll launch into the final revision.

Meanwhile, I’ve gotten some questions about the module. So let me clarify some s$&%.

The adventure module I’m writing ties into my book Game Angry: How to RPG the Angry Way. The entire module—including the maps, the pre-generated characters, everything—will be available for anyone to download. For free. You don’t have to own the book. You don’t have to support me on Patreon. You don’t have to have backed anything on Kickstarter. And you don’t have to pay one thin dime. Or thin ten-pence piece. Or thin looney. Or thin whatever-the-hell-you-usually-pay.

I’m not planning on selling physical copies. Sorry.

The Fall of Silverpine Watch is a short adventure module for three to five 1st level characters and it’s compatible with the Dungeons & Dragons Basic Rules and the D&D SRD. Most groups will get three or four four-hour play sessions out of the thing. The module comes with six pre-generated characters that were both specially designed for the module and specially modified to make them approachable for new players. FoSW is designed for new and inexperienced GMs. It won’t teach them the D&D rules, but it’ll give them a chance to practice the skills described in Game Angry. It’s also designed to help a GM teach new players how to play D&D. The first few encounters introduce different rules and game concepts in a logical order and the later encounters build on the earlier ones. So, FoSW is an excellent tool that experienced GMs can use to introduce new players to the game.

Despite that s$&%, The Fall of Silverpine Watch can also provide experienced gamers a totally satisfying play experience. There’s instructions for removing the tutorial crap, changing the pre-generated characters, upping the difficulty, and even making better use of the module’s primary antagonist. It ain’t going to turn into Tomb of Horrors or anything like that, but it’ll still be a playable one-shot that’ll give an experienced group two sessions of low-level fun. And when I say that, I mean the characters’ levels will be low, not the level of fun.

What’s it about? What happens in it? I’ll give a short, spoiler-free pitch. Winter has broken in the Angryverse kingdom of Asternia and the halfling merchant, Oona Tealeaf, is heading to a village in the rugged frontier. She hires a group of bodyguards. That’s our heroes. Standard stuff. Or so it seems. The heroes have to deal with a bunch of perfectly normal crap on the road through Silverpine Forest. But the trip takes a dark turn when the heroes find the bloodless corpse of a peddler near Silverpine Watch—the military fortress that guards the road—and then find the fortress dead and the gate closed. The heroes have to enter and explore the fortress, looking for someone who can open the gate or else find a way to open the gate themselves. But the ghost of the Watch’s former commander and the corpses of the former garrison seem hell-bent on stopping them.

The adventure is pretty linear to start with. That’s mainly to help the GM introduce game concepts like character interaction, ability checks, proficiencies, saving throws, combat, rest mechanics, exploration and investigation, and treasure and magical items in a logical order. And also to help new GMs get used to narrating, inciting action, resolving action, and making transitions. The second half then takes off the reigns and asks the players to explore a dungeon on their own initiative. The dungeon isn’t super open-ended, but it’s open enough to make the point. And to show new GMs how to follow a party around a keyed map and keep the game moving.

You might want to skip this paragraph if you’re afraid of even minor, tiny spoilers. The second part also lets the player make some important decisions about how they complete the adventure. What goals they pursue and what challenges they face. To win the adventure, the heroes just have to find the fortresses’ winch rooms and raise the gates. A goal-oriented party can easily figure out where they are and take care of that. Dealing with the tormented ghost of the Watch’s commander is a totally optional side thing. If the heroes do decide to confront the ghost, they can solve the problem with the time-tested, adventurer-favored strategy of dealing enough damage to destroy it. That won’t be easy, but it’ll be totally doable. Even for fledgling gamers. But if they explore the Watch thoroughly, they’ll also find tools and equipment that make that fight a lot easier. Moreover, if the party explores thoroughly—or if they get curious—they can find enough clues to piece together what happened in Silverpine Watch. If they do so—if they find enough clues and draw the right conclusions—they can use that information to free the ghost from its torment. Yep. They can fight the final boss with information and social interaction. Thus, new players and new GMs learn that the game’s not just about killing s$&% and completing goals, it’s about how the players’ choices determine the outcome. And it also subtly shows them that exploration and investigation can be as valuable as violence.

Hopefully, that’ll entice you to play or run the module. Or at least download. But if I can’t figure out how to organize it, you’ll never get the chance. So on with the article.

What the Hell is an Adventure Module

Before you make something—anything—you have to know what the hell you’re trying to make. And what it’s for. I’m making a module. But what the f$&% does that mean?

First, let me pedantically distinguish a module from an adventure. See, I’ve gotten really careful about using those two words ever since I discovered I know a hell of a lot about how to make one of those things and almost nothing about how to make the other. An adventure is a single, self-contained D&D game. Or a whatever-game-system-you’re-running game. It has a goal, a beginning, a bunch of challenges, one or more endings, settings, plot, characters; all the s$&% that makes a complete narrative game.

An adventure module is a product—a physical book or an electronic file or a box of feelies or a downloadable add-on—that lets a GM run that module’s adventure for a group of players. It delivers the info a GM needs—and often provides a bunch of useful tools—to make that adventure happen at their game table.

Yeah, yeah, this s&%& seems obvious. But it’s important to state a problem clearly before you solve it. Let me give you a case in point.

Shaded Boxes of Read-Aloud Text

Pretty much every module ever has these boxes of text for the GM to read aloud to the players, right? They’ve been around since forever. Or at least since 197X. Why? Because an adventure needs narration. Scenes need to be set, actions need to be invited, and so on. But does that mean a module needs narration? Does it need shaded flavor-text boxes?

No. Shaded flavor-text boxes help the GM set the scene for each encounter, but GMs are supposed to be able to do that s$&% themselves. In fact, even when running a published module full of shaded flavor-text boxes, the GM still has to provide some extemporaneous narration. Only the big, important encounters have shady box text. The ones that include important details that can’t be left out without f$&%ing up the whole adventure.

I want to teach GMs how to run games with this module. I don’t want to teach them how to read out loud to their players. GMs don’t need the narration spelled out, but they do need to know which details are too important to leave out. GMs don’t actually need a lot of the s$&% that modules give them. Especially the s$&% modules give them inconsistently. And that’s something you recognize once you understand that a module isn’t an adventure. It’s a pile of information that empowers a GM to run an adventure.

Reading, Skimming, and Referencing

A module is a product that lets a GM run a specific adventure. That helps them run it. Fine. Now we know what a module is. But how do GMs use modules? Better still, how do GMs want to use modules?

Common knowledge says that a GM who wants to run an adventure from a module first reads the entire f$&%ing module from cover to cover. And then, when the GM runs the adventure, they keep the module open in front of them and reference it constantly. And between adventure sessions, they review the s$&% the group has already done periodically and read ahead to see what’s coming next. But is that what most GMs do? I don’t think so.

I mean, I think most GMs know—or suspect—that’s what they’re supposed to do. And they probably start out with good intentions. They probably try to read every f$&%ing word in the module. But once they get to all the individual encounters and monster stats and the crap like that they get bored. They start to just skim stuff. They try to get the gist of things and assume they’ll be able to run the game at the table from the text. And when it comes time to prepare for the next session, they don’t actually leave themselves time to read ahead. On game day, they flip open the module and just look to see which miniatures they have to grab from their collection for the next couple of encounters.

I mean, have you tried to read one of these modules. They get pretty dull pretty fast. And I’m not even talking about the big honking textbook modules. Even the short s$&% is dull as s$&%.

It’s obvious that every adventure module assumes that GMs are going to read every single f$&%ing word of text before they show up at the table to run the adventure. But that’s clearly a stupid assumption. And while it’s certainly impossible to present an adventure with any sort of depth without requiring some advance reading, it seems like adventure module writers should be trying their damndest to minimize the advance reading. The module writer should decide what crap needs to be read thoroughly and what crap can just be skimmed. And present that s$&% accordingly.

But What IS a Module?

There’s two sides to everything. There’s function and form. There’s what a thing is for and what shape a thing takes. So far, we’ve focused on the function of a module. What’s it for and how’s it going to get used? The function usually defines the design’s goals. But the form sets the limits.

Adventure modules come in a few different shapes. Without going into too much detail and differentiating binding and length and different file formats and s$&%, we can basically say that modules come in four different shapes. There’s physically printed books, electronic documents, boxes filled with feelies, and downloadable packages for specific software applications. I’m going to leave out the boxes of feelies and the software add-ons and focus on printed books and electronic documents.

The thing is, printed books and electronic documents have very different constraints. When it comes to printed books, the page count is absolutely f$&%ing everything. And anyone who thinks it’s nothing to add another page has never actually tried to publish a book. You’re never adding just one page, first of all. Depending on the binding and printing, you usually have to add four pages at a time. And that changes the printing cost. It also changes the weight and thickness of your book. This means the shipping, distribution, fulfillment, and inventory storage costs also change. And since you can’t actually charge whatever you want for your book, you usually can’t pass those costs along to the consumer.

When the proofs of my book came back from the layout artist—right before he ran away to China thinking he’d finished the job—I discovered that his page design and font choices had turned my 180-page book into a 300-page book. If I’d have sent that to the printer, I’d have gone broke thanks to the additional printing and freight and fulfillment costs. That’s why I had to redo the entire book’s layout myself. Page count ain’t trivial.

Meanwhile, when a module’s published as an electronic document that’s meant to be read on a device, adding pages is trivial. With file compression what it is and with bandwidth and memory so inexpensive and because once you have an electronic file you can make infinity copies at no marginal cost, you can add a hundred extra pages to a PDF and no one would give a f$&%. That’s an exaggeration, but not by much. Electronic documents have different limits though. Page flipping and skimming are chores. And while electronic displays can be pretty versatile, a lot depends on the user’s particular device and setup. Someone with a giant-a$& computer monitor or dual-screen setup can have a bunch of different documents open at once, but someone reading on a smaller device like an e-reader or cell phone definitely can’t. And while bookmarks and hyperlinks can make it easier to navigate a big document, finding exactly what you’re looking for if you don’t know precisely where it is can be tricky. Most users aren’t as savvy with search functions as they should be. So, basically, you have to assume people can only see one page at a time and every time you ask them to change pages or refer to something else, you’re making life very difficult.

Complicating all this s$&% is the fact that things don’t get published in just one format anymore. Unless you’re WotC and stupid. And even if something is published in one format, that doesn’t mean it won’t get used in another format. Most stuff published by non-stupid companies is available in both electronic and printed formats. And many users end up printing electronic documents or sending them to a document printer or print-and-bind-on-demand service. None of those options is terribly efficient. Which means if you make your document too much of a pain to print, some people just won’t buy it. And suddenly, you have all the limits of both formats.

And that’s why it seems like companies keep ignoring the in-line stat block thing.

To Stat or Not to Stat

We all agree that modules would be better if the stat blocks for all the monsters were presented in-line with the encounters. Only drooling morons would argue otherwise. Even WotC knows it’d be better.

But when you consider form over function—and recognize that it’s form and not function that sets the limits—you can see how much of an issue it is. Most modules use the same monsters several times. And in games like D&D and Pathfinder, stat blocks take up a lot of real estate. So, in-line stat blocks eat up a lot of page space just to repeat the same content over and over. If you use the same goblin in eight different encounters and the goblin stat block is a quarter of a page, you’ve chewed up two pages of text just for that.

Meanwhile, as onerous as page-flipping is, it’s not the end of the world for physical book users. Physical book users can easily keep two or three or more books open in front of them at once. That’s why the best thing to do is to put all your monster stats in one book and your adventure modules in other books. It’s an okay compromise. That said, putting monster stats in the appendix of the module is not a great solution. Because no physical book allows you to keep it open to two different pages at the same time. Beyond that, though, screen users get screwed. Because page-flipping is tricky. Many screen users don’t even know they can have the same document open to two different pages at the same time in most document reading software. And that’s still cumbersome.

Of course, screen users don’t care about page count. In-line stat blocks aren’t a problem for them. Until a screen user wants to print their document. Then they care. A lot. Especially because, for some reason, everyone likes to put colored shading behind their stat blocks which means they either hog ink or look terrible in grayscale.

The obvious solution is just to have three different designs. A printed book, an electronic document, and a print-friendly document. But that means spending more time—and more money—on graphic design and layout. For small press or indie publishers—or bloggers trying to give away bonus content on a tight deadline—the extra time and expense can be prohibitive.

WotC is a traditional print publisher and no one can tell them differently. Trust me. I have it on good authority that people have tried and been laughed out of their offices. Page count is their gospel and their hymn is “no in-line stat blocks.” The electronic publications they do make available are basically just electronic copies of their print products. No special formatting. No changes to the design.

I have no idea what the hell Paizo is doing, meanwhile. I mean, I know what their products look like. But—and as several correspondents and commenters observed—their current approach is random and haphazard. Sometimes, there’s in-line stat blocks, sometimes references, sometimes appended compilations, and sometimes there’s just plain nothing.

But that’s why the in-line stat block debate isn’t as easy as “just stick them in; that’s best for everyone.” At least, a brief overview of the major issues. Which just goes to show how much the form of a thing has to say over how it’s designed. Function describes what you want to do. Form tells you what you can do. And can’t do.

Problematic Hierarchies in Module Design

But let’s leave that theoretical s$&% aside now and look at my problem. I’m writing an adventure module. In electronic form. A PDF. But it’ll have to satisfy both screen users and printers. I don’t have the resources to provide two radically different layouts for those two groups. I have to compromise. Particularly on specific issues like inline stat blocks and map presentation and s$&% like that.

But where do I go from there?

Look, all I’m really trying to do is take a bunch of information—the information some random schlub needs to run my adventure—and present it to some random shlub so they can run my adventure. I could do what everyone does and just write a bunch of expository, explanatory prose. Just paragraph after paragraph and page after page of words, words, words, words, words, words. Like a reference book. Because, if you look at a standard adventure module, that’s what it looks like. If you’re old enough to remember what encyclopedias were, that’s what they look like. Encyclopedias. Textbooks. Reference books. Which are great if you want to impart a lot of information about a topic and the reader has all the time and patience in the world to absorb it. And if the reader is taking a lot of notes or at least doing a lot of highlighting. But that’s not how most GMs want to use adventure modules.

GMs want to know what they have to read and what stuff they can merely skim once and then reference during the game. Which means I have to segregate my information accordingly. I should lean heavily on skim-and-reference s$&% and try to minimize advance-reading s$&%, inasmuch as I’m able. The advance-reading s$&% can read like an encyclopedia. It has to. But the information that’s meant to be used at the table—during play—needs to be easy to skim and reference. And it should be easy to look away from that information and then look back at without losing your place.

That means the other half of my module should look more like an instruction manual. Like the assembly instructions for a piece of furniture. Or like the writeups from books like 1001 Totally Cool Science Experiments You Can Do at Home. Or like one of those books you buy to teach you how to use a piece of software like Adobe InDesign. All of those things are designed to communicate a lot of information very clearly while the user’s primary attention is on something else.

That means pulling the useful information out of massive walls of text and organizing it into short chunks that make it easy to see where you are and find what you need. Even if you look away and have to look back. And that means organizing everything into logical information hierarchies. Notice how most instructional manuals organize things in particular ways. They organize things in a logical, step-by-step order or they move from the general to the specific. Those are information hierarchies.

What are the information hierarchies in an adventure? Well, I mentioned one already. It’s the obvious one that most modules already get right. Modules include introductory information that provides background information and context and definitely must be read in advance. Then, you have the game material—encounter, scene, and location information—that’s used during play. And then you have additional reference materials and tools that supplement the game text.

While most modules get that basic hierarchy right, they also get it wrong. Because they don’t recognize that the beginning stuff is the read-in-advance stuff, the middle stuff is a mixture of read-in-advance and skim-and-reference, and the reference stuff is almost entirely skim-and-reference.

Introductory crap should be presented as prose walls of text. Fine. The body of the adventure, though, needs to more skimmable. It can include some short prose that should be read in advance, but that s$&% has to be obvious. Glancing at an encounter, you should be able to recognize the s$&% you need to know in advance and the s$&% you can just glance at when you’re running the adventure. The appendectory stuff—things like stat blocks and maps and handouts and s$&%—that stuff needs to be useful at a glance. Fortunately, most of it already is. Mostly. But understanding this hierarchy suggests a way I can help both screen-users and printers use my module without needing two radically different designs.

The appendectory stuff is the stuff that people need to look at while they’re also looking at the body text. Or stuff they need to hand out. Or stuff they need to do something else with. Printers can easily put all those pages off to one side and shuffle through them like they’ve got a second book open. But screen users might have an easier time if they could open or close them as needed. Or have them in separate windows. Or print just those documents while they have the main document on their screen. Or import them into some other piece of software. Or e-mail them or screen share them or whatever. So, first, I should make the whole document print-friendly so the printers can just print the whole damned thing. But then, I can take the same document and chop off all the appendectory stuff and put all that stuff in separate files. Shove all of that in one archive. Organized well and clearly labeled, obviously. That way, the print users get a single document they can print and the screen users can either use the single document or they can organize and use the multiple files however they want.

But, again, that’s the obvious information hierarchy. A lot of well-presented adventures already do stuff like that. They include bestiary files, map packs, s$&% like that.

The same hierarchy also suggests that I probably need a lot of summaries. It’s pretty much standard practice to provide a loose summary of the adventure in the introduction. But individual adventure parts and even individual encounters would benefit from short summaries. Those summaries would clearly be useful to read in advance, but if they’re well organized and short, they can also be useful to refer to during play.

But still, that’s easy stuff. The big information hierarchy that I need to tackle is…

Hierarchical Encounters

It’s funny. You’d think this would be the longest part of this article. The biggest and most important part. Instead, it’s tacked on to the end and it’s fit into whatever word count I have left. But that’s because, while it is the most important part, it doesn’t have to be the biggest. Because I already did all the foundational work I needed to do. Part of that foundational work was just recognizing that that encounter text isn’t something most people will read in full in advance. It’s text they’ll skim and then refer to. Unless they see a big ole block of text in there or they see something that catches their eye.

The rest of the foundational work was starting this website and then writing a summary of it in book form. Because I established an information hierarchy for encounters years ago.

What does a GM do when they’re running an encounter? First, they set the scene. Then, they present something urgent that invites the players to act. Then, they resolve those actions. And finally, they transition to the next scene. That’s a simple, step-by-step order of operations that is not only explicitly called out in my book, but it’s also pretty intuitive. Every GM understands—on some level, if not a conscious one—that that’s what they’re doing.

The problem is that the section about resolving the action is a doozy. It’s easy enough to start with a summary of an encounter, then break off the flavor text, the incitement, and the possible transitions and include any background the GM needs for the specific encounter in question. But how the f$&% do you organize the action resolution stuff so the GM can find what they need? Is there a logical way to organize that s$&%?

Yes. Yes, there is. Because 99 times out of 10, when players take actions, they’re either interacting with a specific thing or they’re reacting to a specific event. This means that all the relevant information about how to resolve the actions the players might take can be grouped together with the things and events to which they relate. Of course, you can’t spell out absolutely everything. And you don’t have to. Because the GM can—and must—make some judgment calls. But the stuff you do spell out combined with the summary and occasional background information helps the GM handle those calls.

Rather than keep babbling about this, I’m going to do something that I normally wouldn’t ever f$&%ing do. I’m going to show you some really rough draft work I’ve done. Normally, I’m careful about sharing anything too early in the draft process because people think I’m inviting them to share their dumb-a$& opinions about it. And getting opinions too early in the creative process just f%$&s the process up. In short, this s$&% is not ready for any critique. So don’t. I don’t even want to hear about typos. I am admitting this a messy pile of crap. The fonts, colors, and layout were all pulled out of my a$& just to test the basic idea. The text is a hideously ugly draft that’s stuck somewhere between the original walls-of-text prose approach and the hierarchical information format I’m talking about. That’s why it’s a hodgepodge of prose and bullet points and conditionals and all that crap. And the text is still too long.

Both of the encounters you’re going to see come from the tutorial segment of the adventure. They teach specific game concepts. B6 is probably the simplest encounter in the entire module. The players are encouraged to take a long rest, the GM tells them how long rests work, and then an NPC imparts some useful information to foreshadow upcoming events. B7 is likely the most complex encounter in the entire module. It’s the first open-ended encounter the players face. They’re presented with a scene to investigate instead of an urgent problem and they have to ask questions and look for clues. Because it’s an investigative scene, the GM needs a bunch of background information close at hand.

I’ll let these drafts speak for themselves. But I will point out that if you’re really attentive, you’ll notice a few little graphical design elements to help make the organization of information clear. Look close at the summary. Certain words are emphasized. Which words? Why? And what order are they presented in? Why that order?

Finally, I’ll share a little extra something. Something else I’ve been tinkering with at the same time. Again, this is early crappy draft work and it’ll go through a few iterations before I’m happy with it. And the font and color choices were an attempt at a ‘spooky’ theme because this was initially part of a different project. But that monster is one that‘ll appear in Silverpine Watch.

So, that’s it. That’s what’s on my desk right now. Now, let me get back to finishing this damned module.