(Good grief, who writes these blog post titles?)
As I noted recently, I’ve been thinking about a streamlined way to handle megadungeons or large dungeons, in which play occurs almost entirely on geomorphs, “Dungeon Areas” where the dungeon’s dangers and rewards are focused - and the rest of the giant dungeon is referenced only abstractly as “Flux Space,” rather than mapping it concretely.
Last night, via Zoom, I ran a short dungeon crawl into just one geomorph (the top one pictured below). It was fun! Though…I did kill off two player characters and the third fled the geomorph Dungeon Area in terror at the end…
Speaking of leaving the Dungeon Area: in different ways two reader-commenters on my previous post raised the important question of how to link between and describe movement between the Dungeon Areas. This post is just a brief sort-of-answer to note some possibilities and also apply some things I’ve noticed in thinking it through.
First, it’s worth highlighting that all of the standard ‘elements of good dungeon design’ should still be involved as much as possible, but mostly inasmuch as they can apply to each single, geomorph-sized Dungeon Area. That is to say that the best geomorphs for this process will be relatively “Jacquayed” geomorphs, tiles in which most of the spaces mutually interconnect in looping ways. In fact, since many geomorphs are made with the big multi-tile dungeon in mind rather than as stand-alones, one might need to whip up new geomorphs specifically for this kind of application (you can see below some recent rough samples that I made for fun this weekend, and used in play last night).
|Alas, farewell to the character who was picked up, |
lofted airborne, and then eaten by harpies in that stalactite chamber...
Ok, great, but how to connect and travel between the different geomorphic nodes? Some options:
POINTCRAWLING vs ABSTRACT CONNECTORS
Pointcrawling is an immediate and strong contender. Make yourself a node-network chart and you’re off to the races (a recent commenter suggests using the London tube map :-) ). A fixed network map has the signal advantage that it boosts player agency based on knowledge of the game’s concrete ‘reality’ - though (again), player agency can still be important in this system, but pushed as much as possible into the realm of the primary ‘adventuring space,’ the dungeon geomorphs…
Normally, I really love point crawls for designing campaign and adventure spaces. They strike a very nice sweet spot between abstract and concrete. There are much more abstract options available, too - the “depth crawl” has been making the rounds very recently in the blogosphere as one semi-abstract way to handle movement between dungeon areas. Another way is spelled out in The Perilous Wilds…in a nutshell, one has a table of themed dungeon areas, a minority of which are unique. When players travel between dungeon areas, you keep rolling to generate new areas from this table, and once all of the “unique” areas have been found, the dungeon has been fully explored. (In some ways, the whole idea that I’m chewing on could be conceived as an attempt to combine the fast, abstract dungeon design from Perilous Wilds with the concrete spatial reality provided by small maps and geomorphs).
When I first started thinking about all this, I initially thought right away that point crawl network maps would be more pleasing than the abstract options - and particularly much more realistic.
But then I got to thinking, and I realized that if you’re working with a truly mega megadungeon, the abstract methods aren’t actually necessarily less realistic. It just depends what kind of network you’re dealing with.
In network theory, some networks are “decentralized” - they are connected by many disparate connections between network nodes; they have, essentially, no or few chokepoints. A network that is less decentralized does have more chokepoints, more nodes that control the flow of traffic across the network. The more decentralized a network is, the easier it is for traffic to flow uncontrolled; the less decentralized the network, the easier it is for specific nodes to wield influence over the entire network.
Now, let’s think of a megadungeon as a network of nodes, areas, connected by the various paths one might take around the megadungeon.
A Pointcrawl is a particularly realistic way to model a megadungeon only if you want that megadungeon to include some chokepoints. Think, again, of the Bridge of Khazad-Dum in Moria: a pretty dramatic chokepoint. Hold - or destroy - that bridge, and you’ll sway the flow of traffic across much of the dwarven city.
However, think about the other parts of Moria - the endless, winding corridors, the dim unseen neighborhoods that we can only guess at, down all the myriad paths not taken by the Fellowship during their journey beneath the mountains. How to model those areas?
Well, if we accept that a megadungeon as a whole is and should be heavily “Jacquayed” for easy navigation, then modeling that megadungeon using abstract navigation instead of a pointcrawl is not actually any less realistic! If a megadungeon is a decentralized network, there should be many ways for a traveling party to wander around obstacles, and find a slightly different route from Point A to Point D, perhaps even bypassing Points B and C entirely.
I used to think about abstract dungeon-area navigation methods as mechanically helpful due to their simplicity, but displeasingly unrealistic. I’ve realized, instead, that they can be quite realistic if the dungeon being modeled forms a decentralized network - if, in OSR gamer terms, it is heavily Jacquayed.
So, what method do I prefer for the time being for this little project of mine?
Hmm. Hmmm. To really answer that, I need to chew on this some more. While I’m chewing, however, I might as well write with my mouth open, and spill a few more thoughts.
One option: compromise. Hybrid. Go ahead and assign (say) a single “chokepoint” Area - our Bridge of Khazad-Dum analogue - and treat it as a middle-point for the dungeon. All other areas are either West or East of that chokepoint. You can move abstractly among any of the Areas on your side of the chokepoint, but to switch from West to East you MUST clear and pass through the chokepoint Area.
Parties won’t spend much game-time in the Flux Space, apart from a few exceptions:
+ what if the PCs are chased out of an Area and still pursued? I’d suggest that they make an escape/flight roll…and if they fail, you simply generate a new Dungeon Area immediately and grab a new geomorph (one that hadn’t existed as a designated ‘Area’ yet) in which they fight out the next rounds of the pursuit combat.
+ a number of games include travel montage rules for overland travel. These could be modified for use in the megadungeon Flux Space. Give the players a quick sense of the kind of areas they’re traversing, and perhaps even some clues as to what might await in the next Dungeon Area they find.
Well, these last few posts have been ramble-fests in a very busy time, but I’m enjoying this new (for me) direction in thinking about dungeons. Thanks for reading.
Have you looked at how _Ironsworn: Delve_ handles its dungeons? They are a pointcrawl but the events/results can open up deeper access or shortcuts.ReplyDelete
I've just been playing a 5e Adventure with a beginner DM form our local group and with only a few hours in the evening we waste a lot of time doing repetitive mechanical things that eat up our evening. So I am also looking at ideas that cut out a lot of the mechanical stuff and get right to meaningful player decisions without wasting too much time. I'm not entirely happy with _Ironsworn_ ... maybe it goes too far? But I'm still looking.
Thanks! I do have Ironsworn and Delve. I admire them very much in terms of design, but the only time I tried to play the co-op mode Ironsworn (with my kids, to be fair) it felt a bit clunky, ironically.Delete
I couldn't help but think of Iron Crown's Lord of the Rings CCG (late 90's?). You moved around between key locations, but every location had one or more terrain symbols attached to it. These represented abstract terrain you had to move through to get to the location; the other player could play hazards keyed to those terrain types.ReplyDelete
For example, moving to Moria might mean moving through 2 forests, 1 mountain, and a ruin, any of which could invite a hazard (random encounter?). As locations were played, kind of like dominos, concrete paths began to emerge based on location placement, but the intervening space was hand-waved aside from hazards.
I’m a huge fan of the dungeon approach in Perilous Wilds and think you can directly apply it here.ReplyDelete
With your LOTR example, you could set up “West of Bridge”, “Bridge of Khazad-Dum”, and “East of Bridge” as separate themes with sizes of X, 1, and Y. Everything West of the Bridge is handled as usual until the requisite number of unique rooms are explored. Then, the party would encounter the Bridge theme, which is size 1 with a single unique space. After that, it’s another theme with Y unique rooms.
In play, I find theme, size, common, and unique to be good guides for thinking but actually require some specific tooling to work for any specific implementation.
Very thoughtful bllogReplyDelete