Hacker News new | past | comments | ask | show | jobs | submit login

I am curious as to how this avoids generating overlapping rooms. I actually used this random dungeon generator back in the day, and there was nothing about the algorithm that prevented one room from overlapping another, besides 'DM's Discretion'.

Of course, given how unworkable most of the rest of the DMG was if treated strictly literally, patching the almost entirely unworkable outcomes that result from literal readings of the DMG was pretty much the core Dungeon Master skill.




I am also looking forward to a future release of this, which will populate the rooms based on the rest of the subtables. If I don't see a faithful implementation of "TABLE VIII. C.: MAGIC POOLS" (e.g. roll 16-17 on a D20 and get "Talking pool which will grant 1 wish to characters of its alignment and damage others from 1-20 points.....") I will be gravely disappointed.


The plan is to populate the rooms in the future :)


Iteration, I'd imagine.

1. Generate a pile of random rectangles. This is an additive operation (this is only important for #4, below).

2. Check to see if any overlap. If they do, remove one.

3. Repeat 2 until no more overlap.

4. Check to see if there are too few rooms in the map. If there are, go back to 1.

5. Add corridors (this is a whole 'nother topic).


This is an appealing algorithm; its only flaw is irrelevance to the case at hand. Our original poster is proudly following Appendix A of the venerable 1st Edition Dungeon Master's Guide, which essentially is a breadth-first search with corridors generated 'as we go'. This is not to say that your proposal is worse; just that it fails to capture the early-80s grognard magnificence that the designer appeals to be looking for.


Actually, I resisted making it purely breadth first since it would result in more of a dungeon crawl that a sprawling dungeon. However, I might offer this as an option in the future. It's not a difficult modification to make.


Good question.

Whenever the program goes to place a room or corridor, it firstly checks whether those squares are unoccupied. If not, the room/corridor isn't placed.

I originally made it place the room anyway, since it might result in some interesting structures. But in practice, it just made a complete mess and there was no easy way to decide when to make the algorithm stop.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: