How's my 'Room Key'?

[RoeeAV]

@The1True Thank you
All the comment came from a good place, so no worries.

I think the format is great too.
Although the text can be a little bit shorter and more interesting (Which i already did and it works even better now).

I will post an update soon.

 

[squeen]

I understand how you've used the grey to indicate which rooms are keyed on the currently visibly pages...but it got me wondering if you shouldn't instead fade out those rooms (whiten), and instead use a lighter version of the grey to indicate with areas are dark (i.e. not lit).

Just a thought.

 

[Guy Fullerton]

For those in favor of the room dimensions next to the room names: How do you see the referee using that text? *Specifically* how does the room dimension text turn into useful words, actions, or inactions on the part of the referee?

 

[DangerousPuhson]

For those in favor of the room dimensions next to the room names: How do you see the referee using that text? *Specifically* how does the room dimension text turn into useful words, actions, or inactions on the part of the referee?

I see it like this - the DM almost always describes the room dimensions to the players to convey the scale (especially if the group is mapping, then they'll demand room dimensions). So a DM can either look at the map and count out some squares (not great for large rooms or ones with a weird shape), or they can just take the numbers they've got at their fingertips in the room key and tell the players "a 30' by 60' rectangle" or whatever.

It's information clustering. The DM needs the key to describe the room, so why not put the dimensions of the room (needed to describe it) alongside the key? Especially since two numbers don't exactly take up a whole lot of page real estate as they are?

 

[Guy Fullerton]

If I tell you the room beyond the door is, "a 30' by 60' rectangle," can you correctly map it?

Nope. The simple 30 x 60 designation lacks critical information necessary to orient the rectangle and position it properly, relative to the door. Listing the dimensions in the text works *against* information clustering; you start at the map to find the room number, then ostensibly go to the key to see/use the dimensions, but now you have to go back to the map to put the dimensions in proper context.

I agree that counting squares is a pain, but you don't need to put dimensions into the room key to solve that. Judges Guild solved this in 1976, a different way: Write the dimensions onto the map, within large rooms. They also did it in long corridors.

 

[RoeeAV]

I think that once the Room Key includes an an image of the relevant Dungeon section, the dimensions are redundant.
The dimensions also don't work if the room's shape is slightly more complex than a square of any kind.

In my opinion dungeon maps should be less realistic and more functional. An analogues tool that will enable the GM and the players to get a clear idea of where the actual drama takes place.

 

[DangerousPuhson]

If I tell you the room beyond the door is, "a 30' by 60' rectangle," can you correctly map it?

It's not about the room beyond the door though; it's about the present-state room the party is currently in. That type of information is always found in the key for the room, because that's where room information is wrangled.

I think we need to define the purpose of the map: it is not a tool of the present, but rather a tool of the future - to show the connections between areas, and to show what is in beyond those doors in case we need to know ahead of time. Unless the map is being directly used on Roll20 as a battlegrid, then only the DM sees it, and only the DM cares what it says.

But room dimension is not a DM-only bit of information; it is conveyed directly to the players. All the rest of the information conveyed to the players is held in the room key, not on the map, so what benefit does it serve to split the information between key and map like that? To save space? Because, again, room dimensions are unobtrusive - they can be glossed over, they don't take up much space. And even if you are duplicating effort, so what? You still put little icons for statues and stairs on a map then describe them in the key anyway - that's duplication, but that gets a pass?

I see a module as containing 3 distinct types of information: administrative information the DM uses to run things in the background (like random encounter tables and NPC relationship matrices and hooks and whatnot), player-facing information the DM uses to describe a situation to the players (read-aloud, interaction consequences, monster tactics, etc.), and upcoming information which gets communicated to the players when they press onward (light sources seeping through the door crack, noises ahead, where the North hallway leads, etc.).

Preamble and annexes hold the administration information. Room keys hold the player-facing information. Maps hold the upcoming information (unless used as a battlemap, but we are not discussing battlemaps here). Page-flipping and information scanning is minimized this way.

These bits of information stand the benefit from being clustered because they are addressed at different times. You wouldn't put a blanket random encounter table into a specific room key, for example, because it is not needed when describing the room to players. Likewise, you wouldn't mention the implications of pulling the statue in Area 7 in an annex, because it is needed well beforehand. Room dimensions are the same - it's player-facing information, so as a best practice, it should be kept with the rest of the player-facing information.

 

[Malrex]

I look at the map, then I go to the room key....I need the dimensions AFTER the room has been seen/encounter dealt with, etc., because how can characters map if orcs are attacking or whatever? Then when the players ask for dimensions of the room, I can glance at the numbers since I'm already at the key, then go back to the map and help orient them. Otherwise I have to waste time counting squares. I agree, it would be fine if it was on the map as well--as long as the map is still easy to scan and not too cluttered with information (light/dark, noise radius, water areas, etc). I'm only talking about large rooms as the map in this example is easy to scan/count real fast. I just don't see it as 'wasted' space if its in the room key, especially how its presented above (it's not good as part of the sentence/description--the way its presented above I think is perfect)--its just a tool for the DM.

 

[DangerousPuhson]

Agree with Malrex.

Information density is a critical thing to mind, but the practice of effective information management essentially boils down to keeping what is relevant at the time of reading vs. cutting what is unrelated or better placed elsewhere. I think cutting room dimensions from the key for the sake of slimming down information density is a marginal benefit at best (slightly less text to scan, though again, room dimensions are very easy to gloss over), and a detriment at worst (not being there when you need it). In that case, I'd say it's better to err on the side of caution and provide more than is needed, rather than risk providing less than is needed.

 

[Beoric]

don't let the haters put you off bulleting; it draws the eyes and prioritizes information; as long as you don't take it to ridiculous lengths (which you havn't).

I find bullets are useful notes/reminders if you have already internalized the properties of the room, but are poor at conveying that information as first instance. I am starting to lean towards a room format like the MMs where there is a "stat block" for the room that contains the dense abbreviated information you need, followed by a narrative description, preferably to be read not at the table, which puts everything in context.

For the record, I was lauding the use of @RoeeAV's combat experience, not denigrating @Guy Fullerton's design experience.

I find room dimensions in the writeup to be very poor at conveying information to players, since (a) most people have a poor concept of distance (quick, if you don't already know, what are the dimensions of the room you are sitting in right now, without pacing it out?) and (b) it often does not help in describing where the players are entering the room. If I'm not using a VTT, and don't just draw it out for them, and it is somehow relevant (it often isn't), then I usually need to refer to the map to give an accurate description anyway. I never find the inclusion of dimensions in the key helpful, and tend to gloss over them (in fact, in this case I didn't even notice they were there). Usually they just add to the wall of text. However I will say that in this particular format they don't add to the wall of text, so at worst they are harmless.

 

[DangerousPuhson]

I find room dimensions in the writeup to be very poor at conveying information to players, since (a) most people have a poor concept of distance (quick, if you don't already know, what are the dimensions of the room you are sitting in right now, without pacing it out?) and (b) it often does not help in describing where the players are entering the room.

As to a) - while fair to assume that some people aren't good with visually conceptualizing spatial dimensions, it's poor design philosophy to assume that nobody will find the dimensions helpful.

As to b) - this is true, but we are talking about a mere "hexagonal, 20' sides"-type entry in the room key. While a useful thing to know at a glance, knowing it won't give you all the details you need to run the room - the rest of the room key covers those kind of questions.

 

[squeen]

I find bullets are useful notes/reminders if you have already internalized the properties of the room, but are poor at conveying that information as first instance. I am starting to lean towards a room format like the MMs where there is a "stat block" for the room that contains the dense abbreviated information you need, followed by a narrative description, preferably to be read not at the table, which puts everything in context.

I'm intrigued by the sound of this. Would you post an example?

 

[RoeeAV]

Personally i really love the Room Keys in the 'Dungeon Age' adventures.
It has a very good combo of 'Read out loud' and bulleted descriptions.
The only downside is that Joseph doesn't include an image of the relevant dungeon section.

An example from 'Kraken Corpse Delve':

 

[squeen]

Not bad!

 

[Beoric]

Personally i really love the Room Keys in the 'Dungeon Age' adventures.
It has a very good combo of 'Read out loud' and bulleted descriptions.
The only downside is that Joseph doesn't include an image of the relevant dungeon section.

An example from 'Kraken Corpse Delve':
View attachment 929

Sure, that works with a simple room like this, where the readaloud conveys .

I would quibble, though, that the readaloud is an example of language that is too complex for oral communication. I'm (at least) as likely as anyone to use complex sentence structures and words that are not broadly known in my writing. But effective oral communication requires simpler language and sentence structure. Poetical oral language can convey a mood but is ineffective at communicating the physical space.

This example doesn't even tell the players that the "sails of flesh" are fins, or how big they are, or whether they block movement or can be avoided easily, let alone hinting that there may be a slide present in the room.

 

[RoeeAV]

Yeah i agree, the text of the readaloud could have been simpler and less poetic.

In general the big advantage of this format is that it makes the GM's work a lot easier.
Just read the readaloud and then give the details in the bullets when needed.

But, it's disadvantage, is that it's very strict and doesn't invite the GM to make the room his/her own.
In a way the GM's work is a lot more technical and less imaginative/creative with this format.
Another problem is that certain elements are not mentioned in the readaloud, so players might not know that they exist and might not interact with them. And then, it's the GM's work to find out a way on how to describe them or let the players be aware of their existence in addition to the readaloud.

 

[The1True]

I'm intrigued by the sound of this. Would you post an example?

Isn't he just talking about entries in the Monster Manual? Or are you asking for a dungeon room version of an MM entry.

 

[squeen]

Isn't he just talking about entries in the Monster Manual? Or are you asking for a dungeon room version of an MM entry.

The latter.

Also, @Beoric : I grok what you are looking for in terms of room prose/format --- maybe I can post a strawman if only I can eek out some time this month.

BTW: We haven't heard from @The Heretic for quite awhile --- hopes he's doing alright.

 

[Beoric]

I'm intrigued by the sound of this. Would you post an example?

Ok, this was just a hypotheses, so we will see how it works. I picked the entrance to the kobold liar from B2, since we all have it to compare. I added a bit at the beginning with "readaloud" information, although not in that form. I also added additional description, information from the "DM Notes" section so the players would get structural information as soon as they enter the cave, some sensory information to help the PCs choose a direction at the intersection, and some tactical information for the kobolds in the next area (area 1 is kobolds, area 2 is rats). I omitted the reference to planks that aren't there; that should probably be moved to the area 1 description.

I should probably make an effort to make the "description" section more evocative, but I don't have time.

Original:

A. KOBOLD LAIR: There is a 2 in 6 chance that as the group enters the cave-like tunnel, 8 kobolds will come out from hiding in the trees above and attack. Kobolds: AC 7, HD 1/2,hp 3 each, #AT I, D 1-4, MV (40’), Save NM, ML 6). Each carries d8 silver pieces.

Note: 30’ inside the entrance is a pit (X). There is a 3 in 6 chance that each person in the front rank will fall in unless they are probing ahead. There is a 1 in 6 chance that individuals in the second rank will also fall in, but only if they are close to the first rank and the character ahead has fallen in. The pit is 10’ deep, and those falling in will take 1-6 points of damage. The pit lid will close, and persons within cannot escape without aid from the outside. The noise will attract creatures from areas 1. and 2. Planks for crossing the pit are stored at #1 ., beyond.

Rewrite:

A. Kobold Lair: This cavern entrance is nestled at the edge of a large stand of trees. Weeping branches hang low over the lintel; medium creatures will have to brush past them or duck under them. The tunnel beyond is unlit.

• 2/6 chance that 8 kobolds lurk among the trees. (AC 7, HD 1/2, hp 3 each, #AT I, D 1-4, MV (40’), Save NM, ML 6)
• 10’ pit inside entrance (marked on map). 3/6 first rank, 1/6 second rank, 1d6 damage, hinged lid closes to prevent escape. Detect automatically with probing.

Kobold guards may lurk in the underbrush around the cave entrance; if present they carry 1d8 sp each. The entrance itself is braced by a heavy stone lintel on stone pillars, set into the earth. Beyond lies a 10’ high tunnel roughly chiselled from the living rock.

There is an intersection 30’ into the tunnel; the din of conversation from area 6 can clearly be heard, and prevents any attempt to hear noises from areas 1 or 2. The intersection is protected by a pit with a hinged metal lid, camouflaged to look like stone. Tapping the metal lit will reveal its presence. After the pit is triggered, the lid will close and latch from the outside. The pit mechanism is noisy and will alert the creatures in areas 1 and 2.

The kobolds in area 1 will be alerted by any light source, but will take no action until they know if the party will fall victim to the pit trap.

The intention is that the shorter beginning section is a reference to be used during play, and the longer description helps provide context when you are reading the dungeon before you run it. It would probably be a better test if I used a more complicated entry, but I have limited time. The whole thing is a bit longer than the original, but also contains more information. The question is, does it add sufficient utility to be worth the added space?

 

[The1True]

Interesting first hack at it. Still a little verbose.