Tuesday, February 5, 2013

Streamling the Node based Megadungeon

I was having a conversation the other night with Keith of "In my Campaign" about mega-dungeons and publication. Keith is the author and sometime GM of his "Node based Megadungeon" which is a great little project he did streamlining a megadungeon and constructing it via general areas and interrelation rather than classic module style room by room description.  This is a novel approach to a megadungeon, and one that while it may ask a bit more from someone running a megadungeon it has the advantage of allowing a much larger dungeon, a complete mega-dungeon to be produced in far fewer pages, and likely with a greater sense of continuity because the nodes focus on interrelationship between the areas and factions of the dungeon rather than cataloging every empty room. 

There is problem with this approach as it relies on the GM for everything: maps, encounters, traps, tricks and atmosphere without giving anything more than vague clues.  It seems that a useful megadungeon overview would contain that following for each area of "level".  Below are more specific thoughts on how to handle each major component of a dungeon Node.



1) Maps - A map for each node.  The departure that allows the retention of a streamlined presentation is a lack of specific keying (except for important set pieces, unique traps/tricks and major points of interest). Instead areas would be simply shaded or coded as part of a node are and each node filled largely through tables.  Codes code be more specific with "lair" spaces generally noted, but specific residents and details unfixed.  Lair spaces could be filled by Encounter lists, while non-lair spaces filled randomly with dressing and, mysteries and traps as appropriate.

2) Encounters - An order of battle style of approach for each Node and faction is the first order of business - monsters of course would also note their personal treasure, general faction motivations and any individual quirks rather than specific lairs.  The GM simply places the factions as appropriate and marks off monsters as they're killed.  This works both with random encounters and room invasion scenarios and might help avoid the sense that each room is a sealed off universe.  For example, if the GM knows that the Dogmen of the Moss Forest number: 64 Warriors, 102 Non-combatants, Barkbark and Yipgrowl the shamans, Droolsnuffle the Chief and 12 Elite Warriors including the chief's 3 sons who will split the tribe into small factions if the chief is slain.  This (and maybe a table of Dogman names) is all you need for the faction.  A list of special treasure might also be appropriate (especially if Droolsnuffle wields a magic spear or an ornate spiked collar of emeralds, raw gold and human rib bones) - but all this would just be flavor.  The GM can figure out the space the dogmen fit into the map (or randomize it), placing the lair and then randomizing the treasures/details from the appropriate tables or deciding the details in play.

Random encounters tables are often uninteresting and very short.  Yet these comprise the bulk of the encounters characters seem to face, especially in a large mega dungeon as the party winds about and makes multiple expeditions through the same parts of the dungeon.  A good random encounter table could be keyed for each node (or sub-node) noting if the creatures come from a faction (to keep track of that faction's strength and possibly the party's reputation).  Given that there's space being saved by not keying thirteen rooms full of dried dung, dust and covered pits the tables can provide details (perhaps by linking to detail/monster activity tables) or even nest, with a special "one time" encounter table that covers unique beasts, intruders from other nodes or special strange encounters by node.

3) Treasure - Treasure can again be placed by random table.  Either through random generation in rooms or by faction.  Treasure tables, can be broken up into packet, a "mundane" table with small packets randomly generated, a larger hoard table with specific hoards per node (there are four hoards in the Moss Forest) to be placed like factions or with factions. Each packet of treasure can be used once and thus made specific for the node again creating distinct feel, with a more general table by value replacing already discovered packets.  In a less procedurally generated dungeon this might work as well.  I used treasure tables/packets when running Fetid Pit as I knew that the PC's weren't going to plunder the whole location and didn't want to map out each pile of treasure.  My notation is something like "Floating Anglerfish - Treasures in Areas C1, C5, C6 - 2xsmall, 1xsmall/2xsminor magic, 1xsmall+Eggs (200 GP, go bad if abandoned)".  This worked well because I got to write out fewer interesting treasures.  The only danger would have been if the characters cleaned out the "node" based list and I was stuck turning the end of the session loot into nice piles of coins.  Of course a general setting treasure table would fill in the blanks.

4) Dressing and Traps - Another table or two could be used to fill areas with dressing and traps.   Dressing tables are specifically useful as it allows empty rooms to be flesh out rapidly.  I noticed running a megadungeon this week that there can only be some many rooms of the same block construction, same doors, floors and walls.  With a random table of dressing empty rooms can be fleshed out.  This table might also be nested with a traps and puzzles table tailored to the node.

Obviously this method of creating a megadungeon kit rather than a unique dungeon works better as a space filling device the more space there is to be filled.  It's a waste to spend 25 pages of tables to fill a 25 room dungeon, but I don't see the number or complexity of tables increasing much between a 25 and 100 room dungeon node.

A minor advantage of this system (and one I could use running ASE) is that if players had the product one was running they wouldn't harm their game as much by reading it.  Knowing that there are dogmen, and a bit about them is different than knowing where the dogmen are and that they have the best treasure.

More thoughts on Megadungeons:

My definition and key elements of Megadungeon

Thoughts on Set Pieces and One Shots in Megadungeons

4 comments:

  1. I agree that what is presented so far is not yet fit for use as a dungeon, and it was not intended to be. I've done the high-level design of a megadungeon, and not yet the detailed design.

    I am considering a contest to design the various regions of the megadungeon, to see how other people might go about it and how divergent the results might be.

    ReplyDelete
    Replies
    1. Oh of course Keith, I didn't mean to imply that your project was finished - I just really like what you've done, and am trying to see my way to the net steps. Be glad to help out/take part in any contest.

      Delete
  2. I like this approach very much. Mostly because I like to have the story before the mapping (I'm yet to start with my own megadungeon). I saw something very similar years ago with a game about preparing a dungeon:

    http://howtohostadungeon.wikia.com/wiki/How_to_Host_a_Dungeon_Wiki

    The result is a dungeon with a history and all those intersections, but not "room by room".

    ReplyDelete
    Replies
    1. That's a neat site, not sure the complete dungeon history is something I'd want to build procedurally, but it's an interesting idea.

      Delete