Perhaps millions of nascent megadungeons have been abandoned before they ever really got off the ground. A megadungeon is usually considered to be an open sandbox setting where players are free to roam wherever they want; many DMs seem to believe this means they need to have the entire dungeon sketched out, if not fully mapped and stocked, before the game begins. The sheer weight of what seems necessary all-too-often kills the whole project.
Of course, nothing could be further from the truth. It seems clear that Gygax, Kuntz, Arneson, and other early DMs employed a lot of improvisation and just-in-time development at the table in order to keep up with their players. That said, it can be very hard to run an entire game on the fly by rolling on random tables—especially with later, more complex editions of D&D.
The classic science fiction game Traveller shows us one way to approach a sprawling megadungeon efficiently and effectively. Traveller is, as the name suggests, the ultimate sandbox game and has an elegant way of being able to move between planetary, subsector, and sector scales in a way that allows a referee to easily zoom in and out and only develop detail as needed—there's even an acronym for it: MOARN, or "Map Only As Really Necessary." This eliminates the need for the referee to generate detailed information for an entire sector prior to starting a game. You might only develop a handful of worlds or a single subsector as needed.
The Traveller world/subsector/sector model was very helpful as I starting working on the Great Dungeon. The sector scale is like a cross-sectional view of all the different levels. The subsector scale is like the individual level. And world scale is like individual zones or areas within a level. A Traveller referee can start out with developing only one world or maybe a handful of neighboring worlds. The world/subsector/sector mapping scheme allows her to work on discrete pieces while also placing them within a larger, if undefined, context.
Traveller also allows a referee to generate as much or as little data as desired at the smallest scale. A referee can build out an entire system complete with stellar details, individual planets and their associated details like moons, atmospheres, orbits, and so on. This would be like mapping out and stocking an entire section of a level. Or, the referee might only determine the best starport present in the system, which helps determine whether the PCs would (or could) travel there. This would be like marking off a section of the dungeon map as “orcs are here.”
With this in mind, I started with the sector perspective: an overview of all of the main levels of the Great Dungeon. For most of the levels I had an overarching theme or idea. This might have been the primary inhabitants (hobgoblins on level 3) or an architectural features (canals on level 4). A few levels were left open.
When I turned to individual levels, I didn't try to map out the whole thing, I just sketched out the location of different zones within the level using a crude flow chart. Did zone A connect to zone B? Did zone C have a way to get to the next lowest level? For some levels I had definite ideas for how 3 or 4 different zones would relate to each other. For other levels I might have started out with ideas for only a couple of zones. If I were prepping for a delve, I would only worry about having a handful of zones ready to go.
There are many advantages to this approach. Most importantly, you are eating the elephant one bite at a time. It can be exhausting to try to key 40 or 50 rooms at one time and it is easy to lapse into tedium. Dungeon making isn’t factory work, and if it ever starts to feel like that one should do something else. The other big advantage to this approach is it allows you to keep large areas of the dungeon open to future development and prevents you from getting boxed in.
No comments:
Post a Comment