|
Post by thecoldironkid on Apr 3, 2017 0:16:36 GMT -6
For my game, I am attempting to write a series of dungeon tables (somewhat like Appendix A in the DMG, but tailored to my own material) so that I can generate game content randomly, at the table, on the fly. Ideally, once these tables are complete, they would facilitate a zero-prep game. However, what I've come up with (like the tables in the DMG) can only produce endlessly-branching nodes without making explicit provision for "loops" or a "jacquayed dungeon" or whatever you want to call it. Is the only way to achieve a more complex, interconnected dungeon in this manner to wait for the ever-expanding map to just run into itself, and then decree, "Yup, this is where the loop is"? Maybe someone here has some insight into this that I'm missing?
|
|
|
Post by foxroe on Apr 3, 2017 1:28:47 GMT -6
Hi thecoldironkid , and welcome! While random generation is fantastic for spurring the imagination, I don't think it should be relied on entirely. It's up to the DM to make sense of what he/she rolls up and "massage" it to taste. Create your own loops. Example: You've rolled up an area of a dungeon that contains an evil magic-user who's adjacent to a wererat lair. You could keep rolling to generate more randomness (totally viable), but another option is to stop and assess what you've already generated and how it relates to itself. Maybe these two encounters are associated. Maybe the wererats work for the wizard... and maybe it ties in with the giant rats you randomly generated on the first level. Then just fill in the dungeon between the encounters appropriately, relying on your imagination (gut) and not so much on random tables. Hope that helps!
|
|
|
Post by Starbeard on Apr 3, 2017 6:56:19 GMT -6
Welcome thecoldironkid ! What foxroe says is probably the sagest advice you can get on the subject. It's far easier to start randomly and then connect where it makes sense or seems like a good idea at the time. I am a big softy for entirely random dungeons, though. My first complete D&D experiences were from sending endless parties of adventurers through randomly generated hexcrawls using every table I could pull from the DMG and Judges Guild Ready Ref Sheets, as often as possible. Sure, 75% of the time the results didn't make much sense, but it was a whole lot of fun playing and not knowing what was around the corner, or how it would respond, until I rolled it up. I always used the random generators like you, moving along 'nodes' until they happened to loop together (or not). After a while I found that I could occasionally get the map to loop around more by skillfully exploring it: 1) If you use a sheet of graph paper, always treat its size as the hard limit for the possible size of the dungeon. That way you can't just keep going forward forever. 2) Each time you are presented with possible turns, look at the map as you've been exploring it. It's smart to try to turn in a direction toward that which is already explored; you're more likely to find your way to familiar territory if you flee an encounter and get lost, less likely to wander into something you aren't prepared for, and more likely to produce good paths for yourself. If you stay going in a linear direction for too long, you put yourself in danger of getting cut off by a random encounter that comes from behind. But yeah, it's pretty random. Some maps come out great, some come out like labyrinths in the true sense of the word—an endless serpentine tunnel without any side corridors or alternate routes. Sometimes you'll roll up a stupid dead-end dungeon with three rooms, no monsters, and no treasure except for a wet rag and broken chair. I've never figured out a way to make the dungeons ALWAYS come out like B1 or B2 without simply fudging things a bit.
|
|
|
Post by aldarron on Apr 3, 2017 8:41:35 GMT -6
I have an article in & Magazine on setting up dungeons HERE that might be os some help to you, but I confess to being unsure exactly what you mean by "loops". It sounds like more of a map issue to me. In regards to setting up your monsters, btb, the first thing you have to do is roll dice to determine what "level" the monster is. You should do that for all the inhabited rooms on the dungeon level you are working on, before picking the actual monsters. I'd advise you to pick the actual monster type of the "level" you rolled for the room rather than dice for it so as to avoid a nonsensical situation or funhouse feel. So if the room roll indicates a "level 1" monster, you might pick goblins off the level 1 list because that fits with what you want for that area of the dungeon.
|
|
|
Post by Stormcrow on Apr 3, 2017 13:10:08 GMT -6
There are random dungeon generators online that generate the rooms first in a finite space, then connect them with corridors. You could find one of these or write such a thing for yourself. You could then determine the connection algorithm that best produces the kind of circular paths you're looking for.
|
|
|
Post by talysman on Apr 3, 2017 13:10:14 GMT -6
If you want loops in the map structure, you need to either change the way connections between nodes are made, or select your loops in advance, before generating the nodes. The problem with the Appendix A generation method and most other random dungeon generators is that corridor generation is based purely on shape -- corridor heads straight, turns left, ends in T section, and so on -- without any regard to where the corridor leads. Dungeon loops can only happen by chance, and that chance is basically determined by how crowded the map is already. The first way to fix that is to roll for a corridor's destination instead of its shape. For example, number each room as you go along, and when you check what's behind a door or where a corridor branch leads, subtract 5 from the current room number to get a Room Number Mod, then roll a d10. Roll | Destination | 0 | New Room/Node | 1+ | Add Room Number Mod to result |
Draw the corridor as straight as possible from the starting point to the destination, putting in one or two turns if necessary. Optionally, you can check the corridor every 60 feet for doors or branches, but a simpler way might be to add Corridor Branch, Door, T-Section, and Four-Way Intersection as node types. The other way to go about this would be to define loops in advance. Appendix A has you roll for the dungeon's starting area. Similarly, you could roll for the main corridor structure in advance, so that you are guaranteed one or more loops. Assume your dungeon map is going to have four quarters, for example, and then roll for corridor patterns in each quarter on this table: Roll (d10) | Letter Pattern | 0 | R | 1 | A | 2 | D | 3 | T | 4 | Q | 5 | L | 6 | X | 7 | P | 8 | B | 9 | lowercase g |
Draw the corridors in the shape of the given letter in each quadrant. 70% of the shapes have loops in them, 30% are linear. For added variety, roll a d4 for orientation (1=normal, 2= turned 90 degrees clockwise, etc.) Make an additional roll for an overlay of corridors that connect the quadrants. Check each section of each corridor for doors, then fill in your rooms. These are simple approaches to the problem, but there are other ways to do either, or to make the process more elaborate.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Apr 5, 2017 7:54:30 GMT -6
If you want to use a table then insert "loop" as one (or more) of the items. When you roll it, then just reject rolls that are not compatible to forming a loop. In addition feel free to ignore the table and just put in what you want.
I never use a table, I generate dungeons on the fly in real time during play. Limiting yourself to one sheet of paper is a good way to begin. Later when you go mega-dungeon each level may sprawl across tens or hundreds of sheets of paper.
|
|
|
Post by talysman on Apr 5, 2017 16:13:26 GMT -6
I realize now I left a lot of stuff out in my description of the first technique (rolling for destination instead of shape,) so it probably didn't make a lot of sense. I should do a rewrite of both, plus a variant way of rolling for destination I had that might be easier to implement and a little more interesting in terms of layout. However, I'm also working on a major block problem, so it may take me a while to get to it.
Perilous Dreamer's post reminded me that there is technically another way, which is to stick primarily to the old way of rolling for the shape of the dungeon, but have one result which says "roll for the destination instead." If you get a "loop" result on your table, you would roll for the destination next and design the corridor to fit the result. You could even use the d10 roll I described as the destination roll, although one of the flaws of that method is that most of the loops will be short, connecting to nearby rooms or nodes. (The "new room/node" result is meant to give a chance for larger loops, but it's one of the things I failed to describe.)
Since you can have shape-based corridor generation, destination-based corridor generation, mixed shape-and-destination (Perilous Dreamer's method,) and front-loaded looping (the second method I described,) that raises the question "can you mix shape-based and front-loaded looping?" I don't really think so, since the front-loaded method is about pre-defined loops. I suppose, though, you could use a corridor shape generator that included "pre-defined loop shape" as one of its results. This would mean that you wouldn't get "room-based loops", where for example two different rooms have doors that connect to a room adjacent to both (no corridor.) But that's also missing from the pure front-loaded looping method.
|
|
|
Post by talysman on Apr 18, 2017 16:35:51 GMT -6
UPDATESince I didn't really explain one of the suggested non-linear methods very well, I started a blog series on the topic. You can skip the intro, since it basically just explains what this thread is about to people who haven't read this thread. The other two posts are suggested ways to modify an existing random dungeon generation method like Appendix A so that it will produce loops and diverging branches of the dungeon, avoiding a linear structure. The pre-loaded method is the second method I described in my post above, using letter shapes to define a tunnel structure first, then checking every intersection and 60-foot section of corridor for doors or side passages to build the dungeon around that base structure. I think I explained the method reasonably well above, so you don't really need to check out this blog post unless you want alternative tables for checking junctions and 60-foot sections of tunnel wall. The pre-connected method is the method of rolling for the tunnel's destination instead of its direction. Or, at least, one such method. I made a clearer table for rolling the destination of a tunnel and explained the process better, plus I included another table for determining if a tunnel goes over or under an already-mapped area. The post is a little longer than the description above. I plan on posting one or two other methods similar to the pre-connected method, which is why it's labeled "SubMethod I". Oh, and the Blood of Prokopius blog posted a sample dungeon using the pre-loaded method in conjunction with tables from the Tome of Adventure Design, which proves that it can be used with more than just Appendix A.
|
|
|
Post by krusader74 on Apr 29, 2017 14:48:53 GMT -6
I had a few thoughts on this subject. Too long to post here. But even though my exposition is long, the core mechanic I use is very simple -- just a d20 roll and a table lookup to get the initial dungeon topology; followed by some 2d6 rolls to get room sizes, shapes, and exit types. I provide an example of how it works in the text, as well as a Palamedes online helper app. Please take a look -- it's available in several formats: UPDATE: - Uploaded version 0.3 (Sunday, April 30, 2017) of the document (HTML/PDF/Markdown) with three corrections, notably an error in the definition of self-dual
- Uploaded version 0.4 (Monday, May 1, 2017) of the document (HTML/PDF/Markdown): corrected the definition of the wheel graph
|
|
|
Post by Red Baron on May 12, 2017 9:13:30 GMT -6
when i draw dungeons I start by making small loops and then connecting together. to make loops, I use sloping passages to create internal elevation changes within a level. a very simple corridor layout of one loop of a level could look like this: Then I flesh out the loops by adding room complexes, secret passages, one-way turnstyles, portcullises, bridges, and so on. Here's an example of a completed loop. Note how you must often make two or three complete circuits of the same area just to wind up where you started - kind of like a mobius strip. Then I connect several loops together. A single dungeon level will have about 16 to 32 of those loops linked together. i space dungeon levels 30 to 60 feet apart in depth to allow elevation changes, pits, underground towers, etc.
|
|
|
Post by krusader74 on Jun 9, 2017 16:56:34 GMT -6
when i draw dungeons I start by making small loops and then connecting together. Knot bad... I've used this technique myself. Back in 2014 in the Gottam Cnihtas thread, I posted a scenario called King Arthur's Tomb that uses a Hopf Link inscribed in a Klein bottle as the floorplan of a dungeon. See the post for more details, but here are the 2D and 3D representations I provided there: I've considered randomly rolling knots and links as floorplans. Take a look at the Knot Zoo. You could roll a d8 for the knots up to 6 crossings. Or you could roll a d10 for links with 3 components up to 8 crossings. Looking at your diagram above, you could do a slide and an untwist to turn it into the unknot. You can confirm this with Sage which knows some knot theory. To get the Gauss code for your knot, I sketched it, numbered the crossings 1-4, and provided an orientation: Then I input the Gauss code into Sage and did some computations: sage: L = Link([[[1,2,3,4,-2,-3,-4,-1]],[-1,-1,1,-1]]) sage: L.is_knot() True sage: L.is_alternating() False sage: L.number_of_components() 1 sage: L.writhe() -2 sage: L.jones_polynomial() 1 sage: L.genus() 0 sage: L.plot() Launched png viewer for Graphics object consisting of 17 graphics primitives The writhe tells us how coiled it is. The Jones polynomial being 1 doesn't prove it's the unkot, but there's no known knots other than the unknot with this value. The genus of the Seifert surface being 0 proves that this is the unknot definitively -- there's a theorem that says the genus is 0 if and only if it's the unknot. Here is Sage's plot of your knot: It might be fun to use the "Monster" unknot as a dungeon floorplan: If only there were a knot called "Treasure," then we could make a "Monsters and Treasure" Link and turn it into a dungeon!
|
|
|
Post by krusader74 on Mar 9, 2022 18:10:12 GMT -6
Goofing around on the JavaScript Turtle Graphics page, I developed a short, simple script that produces random, non-linear dungeons. Paste this script into the "Code Area" on the left side of the IDE: /* Random non-linear dungeon */
function square() { var theta = 0; while(theta!=360){ fd(10); theta += 90; angle(theta); } }
function move() { var direction = random(0,100); rt(90*direction); fd(10); angle(0); }
function step() { square(); move(); }
function map() { reset(); repeat(3000, step); }
Then type "map()" (no quotes) into the "Command" line at bottom center, and press the Return/Enter key. I recommend clicking on the drag bars and making the Canvas column wider. Here's what my screen looks like on Windows 10 running MS Edge: palamedes.altervista.org/images/TurtleGraphics/TurtleGraphics12.pngHere are a few additional output examples: palamedes.altervista.org/images/TurtleGraphics/TurtleGraphics02.pngpalamedes.altervista.org/images/TurtleGraphics/TurtleGraphics05.pngpalamedes.altervista.org/images/TurtleGraphics/TurtleGraphics07.pngThe algorithm is quite simple: - Draw a 10x10 square.
- Move in a random, cardinal direction: North, South, East, or West. (You could simulate this by hand by rolling a d4.)
- Go To 1.
The script repeats this loop 3,000 times. Note: It is possible to backtrack over the same spot repeatedly. If it goes off the edge of of the canvas, the turtle wraps around, like the old arcade games PacMan and Asteroids; in other words, the canvas is topologically a torus; but this fact is not critical to drawing loops. The code can certainly be optimized, polished, and improved to make better dungeons. But I thought these examples weren't bad for such a simple algorithm. This code is in JavaScript, so it runs in the browser. But I want to point out that Python supports Turtle graphics out of the box, and it would be easy enough to translate the code to Python, if that's your preference. Python has the advantage that you can set the random seed used by the random number generator, so you can reproduce your experiments; JavaScript does not support this -- you'd need to write your own PRNG or use a non-standard library.
|
|
|
Post by tkdco2 on Mar 23, 2022 22:37:16 GMT -6
|
|