Some Hex Mapping

I've been tinkering with hex mapping lately, and thought I'd post what I did in the order I've done it. The scale is 25 mi = 1 hex, and the map spans roughly the 35th parallel to the 60th parallel.

The climate information was developed using the Climate Cookbook, and the software used is primarily Hexographer and GIMP, with Koppen climates added in Inkscape.

Now that I have big hex map made, I'm going to pick an area that looks interesting to me and make a 5-mile-hex map of it. Then it'll be time to start building details on that map. Rinse and repeat until the entire 2.25 million square mile area is done!

1. Landmass

2. Landforms

3. Climate - Precipitation

Summer

Winter

4. Climate - Temperature

Summer

Winter

5. Koppen Climates (WIP)

6. Landform Updates & Major Rivers

7. Vegetation

Jayquaysing the Caves of Chaos

That's a lot of little linear maps!

I just finished my first pass of another dungeon entrance - the Caves of Chaos. But I couldn't leave well enough alone. The original Caves are pretty cool in their layout, but it still has some issues.  For one, it's weird having a dozen different sentient species, some of whom are enemies, all living in one valley together. Another is that the caves don't interconnect as much as I prefer.

The first issue is easy for me to address. This is where the beast-men disciples of the Horned One live, so while it seems like there are a dozen different sentient races here, they're really just one big group. That coordinate. That should amp up the difficulty for the PCs.

The second required some redrawing, adding, and tweaking. That required drawing the entire map into InkScape for further manipulation.  Thankfully, once that was done, I moved a little bit around, stuffed in some secret doors in reasonable looking places, added in a corridor or two, and made the minotaur's labyrinth well, more of a labyrinth. I may also need to stat up David Bowie with horns. Finally, I am adding at least one more level below the caves that will lead to the main body of the megadungeon.

So as it stands, the PCs can access the Caves the normal way, and once they are inside, they can get to any other room on the entire map without going outside, if they want. This is as much for the monsters as it is for the PCs. Since the factions coordinate their defenses, this lets the monsters shift forces to reinforce points of attack, pass information, and move supplies in ways the PCs might not expect. It allows for a far more flexible defense of the caves, and that should make this less of a cakewalk.

After all, my job is to provide problems, not solutions.

Another Mapping Tip - Rooftops

I'm a strong believer that the entire megadungeon doesn't need to be subterranean. I am mapping four separate above-ground "levels" for my megadungeon, each of which is a unique entrance to the dungeon proper. This is in addition to other, more generic entrances like caves, wells, tavern basements, sewers, etc. In mapping out these above-ground entrance complexes/levels, I have come on what I think is a worthwhile piece of advice. Of course, like any unsolicited advice, your mileage may vary.

The Advice: Map Your Rooftops!

Why do I say to map your rooftops? Well, it's because your players have seen a lot of movies with crazy rooftop fight scenes. They've also played a lot of crazy video games where fights happen high up on rooftops. The earliest example of this that I can remember is playing the shareware version of Star Wars: Dark Forces (yes, I'm old), and one of the cooler levels in that had you force-leaping from rooftop to rooftop while shooting storm troopers. Of course, plenty more exist!

And let's not kid ourselves. There is something exciting about fighting giant gargoyles on the rooftop of an ancient cathedral or leaping from building to building in pursuit of some Big Bad. So when you're mapping your dungeon (or city or whatever), don't forget to map the rooftops!

A fun corollary is that rooftops don't need to be pleasantly flat and offer good traction. Having spent a fair amount of time on my own rooftop as a child, I can assure you that they are neither flat nor offer good traction. Pitches are must steeper where snow and ice naturally occur, and any sort of shingle roof will have loose gravel on it. Slate or other rooftops may also accumulate ice and snow in the winter. Make note of this! It makes those rooftop battles all the more memorable!

This last bit touches on something I need to write a proper essay on: Your players' PCs are defined by the challenges you give them. Coddle them, and they will be lame. Push them and they will be awesome. And those who perish will be remembered. But all of that is for another blog entry.

3D Modeling and Mapping the Dungeon

As you probably know if you have followed this blog lately, I am mapping a dungeon again. Today, I'm going to talk about different approaches I've used to making 3-D maps and representations. But first, there are a few ways to produce these. I'll talk a little bit about them below.

CAD Software

Computer Aided Design Software is software used to create thee dimensional models of things in a computer. There are a great many of these, but the ones I am personally familiar with are SolidWorks and Pro-E. I have a passing acquaintance with SketchUp and access to YouTube, so I'll go out on a limb and claim to be able to use that, too.

The benefits of such software is that you can make a 3-D model of every room in your dungeon down to nails and brackets, if you want. The level of detail is up to you. And then you get move it around, hide walls, take screenshots, etc. SketchUp lets you do walk-throughs. Engineering software lets you do things you will never ever ever need to do like model the voticity of blood flowing through your dungeon. Well. Maybe that might be useful for some...

The drawback to using CAD software is twofold - there can be a rather steep learning curve to such software and it takes a while to produce a good model.

SketchUp

This probably falls under "CAD Software", but I'm going to break it out because it is cheaper, more popular, and doesn't seem to be nearly as sophisticated as the professional CAD programs I'm use to working with. Also, it was originally geared toward architectural applications, and not engineering ones.

SketchUp lets you build 3-D models of just about anything, but it was originally targeting architectural designs - buildings, landscaping, etc. This focus potentially makes for some excellent end products, complete with lighting, shadows, and everything. That can be really cool, if you go ham with it, but doing so takes time. I don't profess to be a SketchUp expert, so I doubt I'm any form of fast, but I can see where you can quickly bang out an important room or locale to get a nice visual for players. Just as with the CAD software mentioned above, I still think it's too cumbersome to use for an entire dungeon, at least unless you just love doing that sort of thing. Then good on ya!

Isometric Maps

These maps offer an isometric view (think Diablo and its clones) of the dungeon. They are fantastic for showing relative heights of rooms, but they require special graph paper - or more talent than I will ever have - to draw really well by hand. I haven't found a computer map-drawing tool that makes these, either, though I am probably just missing it.

The benefits of isometric maps is that they are simple to read if drawn well, display height differences well, and are far faster to make than using CAD software. Drawbacks are that you won't get the degree of detail and versatility as with CAD software, and it takes talent to make these look good. Moreover, some 3-D dungeon designs may not read well, no matter how good you are (try to imagine a 3D maze in isometric perspective).

Is It Worth It?

In my experience, isometric maps just look cool. They can also help give a sense of elevation, which for very vertical maps can be essential to understanding the flow. My only issue with using these is that I suck at drawing them. So I tend to gravitate to a computer-based approach.

I have used both SketchUp and SolidWorks to produce models of dungeon elements, rooms, etc. I am far more familiar with the likes of SolidWorks and Pro-E, so I tend to get faster and better results from those than SketchUp, but I can see where someone versed in the latter-most might be more productive than me.

What I find works well for me is breaking out CAD software to produce images like the one below. I created this to get a sense of scale between the towers, wall, and enclosed courtyard. I now have the dimensions of all of these elements in a way that makes visual sense to me and can begin drawing a map of the keep. I also have a spiffy visual for the players.

This took about 2 hours because I kept fiddling with dimensions to get the sizing just right.

Another Set Piece for the Dungeon

I just finished mapping up another set piece for the dungeon, and I think most players will like how I mixed a pair of RPG and myth tropes to get something a little different and potentially terrifying. This set piece is all about ambiance, but that foreboding atmosphere will be backed up with one heck of a level boss.

This time around, I'm trying to make heavy use of the environment, which direction doors open, locked versus unlocked doors, and a general degree of creepiness to keep the players on edge, catch them off guard, and ultimately hit them hard with a single monster that will use the environment to its full advantage.

Granted, a typical GURPS party is horribly deadly when facing a single opponent, but that's where the environment comes in. The players will have their mobility noticeably limited, with any mistake in movement resulting in the sort of debilitating condition that can ravage defenses and leave a PC helpless at a critical moment. I'm piling on top of this doors that open in specific directions and locked doors to make running away more difficult, unless they specifically prepare a path of retreat as they advance.

My hope is that these two things will combine to make for the sort of encounter my players will talk about with horror and gratification (once they get past it!) for years to come.

What sort of things have you done in your games to make a single monster actually effective against a well-prepared party?

Automating Architect of Worlds Update

Lately I've been learning a lot about Python and how it handles objects through another side project, and I'm starting to see where I should go back and rework what I have so far for Architect of Worlds. This comes at a good time, since I've gotten up to generating everything but moons, and that step is looking like it will be a bit more intensive than the text suggests - in terms of programming, that is.

So I think my next step will be to go through the original code, clean it up as much as possible and implement a cleaner data management system. I also want to break out a couple of bits into their own functions so they can be reused whenever necessary...I'm looking at you, orbital placement! Once this is done, I'll proceed to do moon placement.

I also have a couple of questions about the model being presented, since it doesn't appear capable of producing the insane number of moonlets our gas giants have (79 for Jupiter and 62 for Saturn). Mind you, in terms of storytelling, most of those moons are inconsequential, but knowing their total number is helpful, and if I know that, I can place them automatically and develop them from there. So, because my application doesn't involve a human rolling dice and interpreting results, I don't see an issue with rolling up 120+ moons no one will ever care about visiting.

Also, When you roll things up randomly, sometimes you get interesting results that spark creativity. So I'd rather roll up a bazillion moons and risk getting a GM's creative juices flowing than say, "There are a lot of them, and they probably won't be interesting enough to justify the time you'll spend rolling dice to generate them." But that's because of the medium, not a fault in Jon's system by any means.

So that's my plan. I'll keep you updated on progress. Hopefully I"ll have enough put together to use soon!

Random Mapping Tip

I have come across something that is pretty obvious and I should have been doing this entire time, but hey, we aren't all perfect. So in case you're not perfect either, I thought I'd share this tip with you:

If you are mapping an area and think of what a room or group of rooms should be, WRITE IT DOWN!

Right now, at least half of you are probably shaking your heads thinking, "Man, this guy didn't do that before?" and I don't blame you. But I cannot explain how much faster mapping this abbey has been because I laid out all the rooms as I drew them. I know it won't always be this easy, and as I leave the more systematically-designed regions behind, it'll get harder, but that's all the more reason to follow this tip!

And I'm going to extend it to more than just what a room is. If I think of what goes somewhere, it get noted. If I think something needs an object or treasure or trick or trap, it gets noted. No more going back and sorting rooms later. My later pass will be to fill in the gaps and then check that everything makes sense.

I hope this helps someone out there!

Mapping around the Abbey

Today I worked on an overland map for the 60-mile area surrounding the abbey, largely to see how it connects to the outside world. Now I can definitively say that the abbey sits on a forested hill at the end of what would be generous to called a wooded road. Even trail might be generous. The nearest village is a day's hike away, and the trail ever got used to bring the monastics at the abbey food and supplies.

More Progress on Architect of Worlds Automation

I'm happy to report that I'm ever so closer to being up to date with what Jon Zeigler has already published. I've not completed Step Eleven (yikes! that was a mess) and finished off Step Twelve, as well. That just leaves a little more basic planetary information from Step Thirteen, and I can dig into the moon stuff.

If I am able to get this done before Jon drops the next portion of the system, I'll go back and try to clean up the mess I've made everywhere I making this work. I think I can get it much cleaner than it currently is. Then I'll start working on using the data generated to create a database I can further manipulate in a program like Access.

That or I'll get back to fleshing out mechanics and making setting content. Either one will work. But being able to generate systems quickly is key to making this game work at all. I want players to have the agency to just shoot off in a random direction or ask, "What's over here?" and I'm just a couple mouse clicks from some sort of answer.

Mapping an Abbey

[1]

While it may not look it from my posts as of late, I have been trying to split my time between making progress on a science fiction setting and doing some mapping and worldbuilding for dungeon crawls. To will be a post on the latter.

So lately, I've been mapping up a small abbey to serve as the first level of a larger dungeon. Naturally, it is dominated by its cathedral that has two towers and a central dome. Unlike traditional catholic cathedrals, I decided the bells would go in this dome, and the entry-way towers would be spires. This just felt good when I was making the map.

The outlying buildings are a two-story affair with the usual rooms associated with a monastery - refectories, calefactories, scriptoriums, and lots of other churchy-sounding names. And like any good dungeon entrance, this abbey has a cellars and an underground burial catacomb so the monks and nuns that live there never need leave the walls of their sanctum.

So that's a quick rundown on the abbey, but how does it sit within the region? Well, for starters, it is an ancient complex perched upon a forested hill about a day's ride from what remains of the village that once supported it. Both are now abandoned, but the abbey has fared far better than the village. Many legends and superstitions attribute the abbey's well-preserved condition to any number of supernatural causes - none of them particularly holy or good.

This is what I'm currently working off of. I'm sure it will grow deeper as time progresses, just as Alnwich did when I worked on it. For now, though, I can definitively say that there is an abbey - with a map! - that definitely qualifies as a Bad Place, and under it is some sort of dungeon. How mega it will be is up in the air.

Automating Architect of Worlds Update

I feel like I haven't made much progress on my automation of Architect of Worlds project. Step Eleven has proven far more troublesome than originally anticipated, largely owing to the fact that I didn't save enough information from Step Ten - specifically how far inward the dominant gas giant migrates. I had just stored the final position for later use. Oops.

Once this was rectified, I ended up reevaluating my approach to Step Eleven to put it more in line with what Jon wrote in the first place. See, originally, I was generating all of the orbits, stocking all of the orbits, and then deciding which orbits to delete, but I realized this was just taking extra time and wasting memory. So now the Step Eleven function will run through Step Eleven then decide whether or not to place another planet, and continue from there.

There is also the matter of how I will store all of the planets' data. I am still not 100% sure about how to set up the data structure for this project in the most efficient way possible. As it stands, I have a bunch of separate objects, but I'm starting to wonder if these should go in lists in a variable in the parent or not. So, frex, System has a variable called Stars that contains a list of Star objects, and each Star object has a variable called Planets that contains a list of planet objects, and so on.

I'm not sure I like this and haven't committed to it, yet. But it looks like I will need to pass a list of planets out of Step Eleven, and future steps will process this list, one planet-object at a time. I am really hoping someone leaves some suggestions in the comments, below, because this is definitely pushing my understanding of data handling.

Automating Architect of Worlds: Update

I recently reached Step 10 - Place Dominant Gas Giant in my quest to automate Jon Zeigler's Architect of Worlds star system generation system when I read his post on how reality is impinging on his development plans. While I agree with his approach, it got me thinking about how I want to deal with this particular issues and future updates to the program.

Mapping Update: Placing Locations - not Encounters

I have been working to place interesting locations on my hex map, and I've come to a conclusion. I am placing locations, not encounters. Why make that distinction? Because "encounters" has a specific connotation that revolves around conflict and implies a degree of railroading. If you enter this hex, the GM rolls and if the dice come up Encounter, the players have to deal with something predetermined by the GM. That isn't good GMing, in my view.

So instead of placing encounters that unfold a predetermined way, I place locations where something might be happening. I will roll to see if the players stumble on the location, and if so, give them information based on what they witness. What happens from there is 100% up to them. It might be a dungeon entrance. It might be a gnarled tree with a rope tied about its trunk. It might be a pile of rotting corpses. Whatever.

That doesn't mean there aren't random encounters rolled for hexes. These represent stumbling on an event that potentially provokes action. These could be combat-oriented like a dozen orcs charging a wagon with drawn swords, or they could just be creepiness like catching a glimpse of fish-men playing pipes in the distant fog. Again, these provide the opportunity for the players to make decisions. They don't exist to force players into a specific course of action...unless they really mess up a Perception check and get ambushed by a hostile encounter. But even then, there is a string of rolls that create that situation - Reaction rolls by the hostile party that indicate it will attack, opposed Stealth checks to see if they can sneak up and waylay the party, failed Perception rolls by the party, etc. The players get their chance to avoid it, dice gods willing.

So that's a whole lot of ranting about a concept, but how has it been implemented in the hex map? I have placed several locales in the uncivilized parts of the map so far. These are, for the most part, stationary (with one fun exception that might move once per week). I'm generally picking locations that scream out for something initially and then going back to fill in other ideas afterward. So far, Alnwich is pretty well covered, so I'm starting to expand the adventure bubble outward.  This method seems to be working well, so far.

Mapping Update: Alnwich

I have finished filling in terrain and towns for the entire northeast corner of my hex map. I started out going this direction because it provides natural barriers to PC exploration. To the north are the Skaldafjoll, which as subarctic to arctic mountains, present something few prepared high level PCs will easily cross, let alone starting PCs. Of course, the foothills and forests to their south are definitely good adventuring sites.

Mapping this corner first also gives me some ideas about how Alnwich relates back to Northmarch and Usk. It has already become apparent that there is a main road that leads back southeast toward civilization, and there is a full-blown town town around a week or two away.

I'm also starting to see what the edge of civilization looks like in Usk. There are a string of fortified villages that run along the wilderlands' edge in the north and the west. These are largely supported by market villages one to two day's ride away, depending on the sparsity of the local forest. Trails connect these village-forts to each other, and roads connect them to their supporting market villages. this suggests that they can shift resources to support each other as needed, but not very quickly.

We also see that where the forest has been cleared or grows thin, dirt roads tend to replace footpaths and trails and villages tend to be about five miles apart, instead of ten or more. Furthermore, the land tends to be cultivated with small patches of woodland still presenting physical barriers to travel.

I suspect that as one travels deeper into Usk, villages tend to reach their maximum packing density and the map becomes far less interesting from an adventuring standpoint. This also provides a barrier to PCs. If you move into Usk, there are fewer opportunities to get rich, achieve glory, etc. because there just aren't many monsters sitting on hordes of treasure left. So if players want a game of intrigue and cunning, head to Usk. If they want game of exploration, violence, and adventure, head to the wilderlands. And that's exactly the point!

Monster Lists & Mapping

As everyone who has read this blog for any time knows, my system of choice is GURPS, mostly out of laziness. Yes laziness. GURPS can handle any play style and genre pretty well, even if specialized systems might potentially outshine it on a case-by-case scenario. So what that means for me is that, while I might not get optimal performance for each genre I enjoy, I only need to know one system. That is valuable to me. It doesn't hurt that GURPS handles my two favorite genres pretty well, too!

This post isn't a plug for GURPS, though, so I'll get to the point. I use GURPS. I am lazy. These are sometimes at odds. GURPS does not have a dedicated bestiary in the way that Dungeons & Dragons does. There's no single book I can open and get my hands on hundreds of premade monsters. Sure, Dungeon Fantasy has four books of monsters, now, and I use them, but two are toolkits for making specific types of monsters - oozes and dragons, and the other two have 60 monsters combined, at most. My point here is that as a GM, if I want monsters, I very regularly have to make them myself.

Of course, I've been doing this for a while and have my own repository of monsters at this point. I've even posted some of them on this blog. So that helps, but that doesn't mean I always have the monsters I need on hand when I start placing them on maps. So this is what I do.

As I map, I jot down notes of what goes where and keep a running list of every monster I've placed. This includes different flavors - e.g., Goblin Archer, Goblin Mook, Goblin Priest, Goblin Fighter, Goblin Kamikaze (don't ask), etc. I also jot down monsters with affix combinations - e.g., Possessed Berserk Killer Minotaur of the Juggernaut and such. Some of these will eventually turn into monsters in and of themselves. Lastly, I jot down any monsters that might be traps or traps that might be monsters. Sometimes there are gray areas.

This list becomes my To Do List for monster creation. Anything that doesn't come in flavors or with affixes are just base monsters. Those that have flavors get a base monster and then flavors built on those base monsters. The same goes for monsters with affixes. Finally, those that blur the lines with traps get a final sorting at this stage, and those that make the monster cut get statted. Usually, inspiration or tangents grab me during this process and spawn a few other monsters for the ever-growing folder of That-Which-Paper-Men-Were-Not-Meant-to-Survive.

So if you're mapping and have an idea for a monster, jot it down on a list. Keep that list handy. It's nice to know what's in your dungeon or wilderness area. It's also nice to have a ready-made list of stuff to do when you find some down time.

Map of the Region around Alnwich

As promised here is a hex map of the area around Alnwich. It uses 5-mile hexes and has all of the major geographic features and points of interest mentioned so far. I'll start dropping interesting locations, next, and cataloging those in a database. After that, it will be time to start rolling randomly.

It's worth noting that I will likely steal profusely from my favorite published material for "interesting locations". So expect Caverns of Thracia and the Dark Tower to make an appearance somewhere., and I'll probably do my own spin on the Demonweb Pits and Tomb of Horrors, too. That said, this map will likely be lair-heavy, owning to the extensive wilderness areas.

And on one last side note, I haven't really placed any rivers yet because the Trollenmere specifically lacks any inflows or outflows. As I map out more of the Skaldafoll or other elevated regions, I'll start drawing them. After all, rivers flow downhill, and until I know where that is, there's no point in starting!

Hex Mapping and Resources

I have begun creating a hex map of Alnwich and the surrounding land. I am largely following the advice of The Welsh Piper and The Alexandrian for my process, not to mention all of the work Rob Conley has done over at Bat in the Attic. I am also going through a lot of the resources Charles has already posted on his blog, Nature Kills: A Hexcrawl for GURPS.

What do I know so far? Well, I am using 5-mile hexes because they mesh well with the average Joe's Basic Move in GURPS. I have also mapped out the bits of around Alnwich I have already described or mentioned. I figure that is the first place to start - putting down what I already know. Once I have that looking good, I'll start expanding outward. That way, I can keep an appropriate level of detail without getting too bogged down in stuff.

I will need a few things for this, though. First, and probably second, third, fourth, fifth, etc., are a good set of tables. These will be extremely helpful in generating hex contents and placing features and encounters. Next, I will need a database to serve as my key. If this grows to a large size, having that information neatly organized will be critical. Better to start now than to have to do data entry later. Lastly, I need more free time. But I think every hobbyist needs that.

I'll try to post the fruits of my labor in the coming days.

Progress! A City Takes Shape

I have finally begun making some progress mapping again. Today I started in on the ruins of Thanras. This is the dungeon entrance I really need to get mapped before I get players in the dungeon. There might be some other entrances, but they'll need to find those for themselves. In the meantime, I am attacking what should end up being a fun area.

Thanras isn't small, but it isn't ginormous, either. I blocked out a square of land about a quarter mile on a side to work with. I doubt I will fill the entire square, but I can't say for certain just yet. I started out by plopping down some major buildings and connecting them with roads. This is getting closer to finished, and once it is, I'll drop in some squares where they seem like they belong. Then I'll start throwing down buildings somewhat haphazardly along the existing roads and see what side streets naturally take shape. From there, I'll add in most buildings on those streets and see how it evolves. I'm hoping for something somewhat labyrinthine, as would be natural for most unplanned cities.

Of course, these are the ruins of Thanras, so when I say I'm placing buildings, it's more like I'm placing foundations and whatever might still be standing on them. Most of the city has cracked and collapsed with countless years of freezing and thawing. Still, some of the beefier structures might be partially standing. After all, the Parthenon was stood for 2,119 years until the Ottoman Turks filled it with gunpowder during the Great Turkish War. And even today, it is still largely standing, albeit without a roof.

So Thanras will have a few structures still largely in tact, but mostly they'll be decayed and collapsed. What lives there now I won't hint at, nor will I mention what loot might be hidden beneath the rubble. But not much screams "Adventure!" like the ruins of an ancient city. I just need to make something that Indiana Jones would approve of.

Unforeseen Consequences in Dungeon Mapping

I have realized recently that there are some major consequences to some of my early design decisions regarding dungeon entrances. See, I started out thinking, “An ancient castle sitting on top of a dungeon is cool!” so I made that the main entrance. And that sounds all well and good, but that castle is big. But it’s a megadungeon, right? Well…

The thing about players is that they are unpredictable. That’s what makes GMing fun, though; you never know what they’ll do. That’s why I prefer sandboxy games, too. If I wanted to know the outcome of every action in the story, I’d write a book. So how does this interact with Giant Castle for an Entrance?

Consider how a castle looks. It’s a big, tall structure open to the air with walls and windows and ramparts and stuff. And these players are going to show up decked out with burglary gear, ropes, and murderous intent. So yeah, I laid out entrances, and there are ways through all of them, even if some are tougher to penetrate than others. But why should the PCs settle for going in the front door when they can climb in through a 5^th floor window?

Lessons from the Megadungeon, Part II

I’ve been making a big push for stocking, lately, and in doing so, have come across a few more practices that seem to really help.

Label Rooms & Hallways Clearly

Each room should have a designation unique to it, not only for that level, but for the entire megadungeon. This will help with searches later on. I’ve adopted the following nomenclature:

[Zone Number][Zone Level]-[Room Number or Hallways Letter]

I used Zones because I will have multiple zones at a given depth. They don’t necessarily connect (or do!), but they are distinct areas with distinct features and difficulties. Each zone has multiple levels, so the zone ends up a multi-level construct within the greater dungeon. Rooms get numbers because there are more of them than hallways.

At first I wrestled with how to number rooms (upper left to lower right or whatever) and eventually realized I will be tracking PC movement, not hunting down a particular room on a map by its designation. So I just do whatever makes sense at the time. It’s works out well so far, but I’m sure I’ll regret it later.

Name Rooms

Once you have all of your rooms numbered, go give them names. Nothing super fancy, just a name for what that room is. If you’re not sure, skip it and do it later. Those names will inform what goes in them, how you describe them, etc. Using good room names cuts down on the amount of info you need to mention in the description. Heck, name your hallways, too!

Don't Get Bogged Down in Details

Keep your room descriptions vague. List stats for things the PCs can interact with – doors, locks, chests, traps, monsters, etc., but skip the minor stuff like floor type, wood paneling, ceiling descriptions, etc. You can do that on the fly. Jot it down then. No need to waste time on what you can improvise later.

If You're Not Sure, Skip It

If you get to a room, and you’re not sure what should be in it, what a puzzle is, what trap to use, which monster combination to throw in there, skip it. After you work on the surrounding area, you’ll get some ideas. Or maybe you’ll be showering and think of something. Or an episode of Frontier will give you an idea. Whatever. Doesn’t matter. If you don’t have the idea now, it’s fine. Don’t waste time, and move on to a room you do have an idea for. There’s a lot to stock; don’t get hung up on one room.

That's about it at the moment, but if you have any other suggestions for stocking, please make mention in the comments below. I'm always up for advice on this sort of thing.