Dungeon Generation standard elements

[Eben]

* Bottomless pits. Can't mine them away, they don't block your view, push someone there for instadeath.

Yes indeed! I've mentally added this to "empty space" on the list.

So what I'm thinking now is I want to have the map generators take the area they're responsible for filling as a parameter.  And some dungeon generators call others to fill in some sub-areas.

Composable map generators are really really cool. I've played around with them on some of my little projects and with a few simple generators, you can make some really wild and interesting things. Especially when you start randomly combining them. I'd be interested in anything you come up with involving this.

Composability is my primary goal here. Clearly allowing for a "this is a central cavern", "this is a side tunnel", etc is important. I like the idea of the int map, but I'm not sure it's expressive enough. OTOH I don't want to go full OOP interface on the 2d array for the mapping since theoretically there'll be a lot of processing on them.

Leaning heavily towards the int[][] solution right now, probably with some predefined generator-specific constants indicating the common usage for the results.

[Zireael]

Wow, can't wait to see the dungeon generation library in use! Will it have a front-end of some kind, like the Tiled editor, and what language is it gonna be coded in?

[Cfyz]

What are the languages this hypotetical library will be useable with? Just C/C++ (judging from int[][]) or more?(i've made a fool out of myself)

About the list of tile types, I think it might be a better idea to leave such list mostly unspecified. If there will be multiple generators, most likely some of them will introduce totally new or adjust previously used tile types. Leaving the precise list of types to the concrete generator documentation should be more flexible. If there is a need for post-processing, such list may be converted to the one more convenient to the application by a simple lookup table (optionally grouping types specified too precisely for application to handle).

Also, depending on intended complexity of generation, it may be useful to allow querying tile 'properties' like water depth, glass opacity or portal ids (for entrance-exit pairing). Simpler applications may just stop on tile types (if applicable) while more sophisticated ones will take advantage of more detailed description.

[Eben]

What are the languages this hypotetical library will be useable with? Just C/C++ (judging from int[][]) or more?

Wow, can't wait to see the dungeon generation library in use! Will it have a front-end of some kind, like the Tiled editor, and what language is it gonna be coded in?

Nothing hypothetical about this library, it's going into my Java library that's been around for years: https://github.com/SquidPony/SquidLib

I've considered the idea of having a front-end before, and I might still do it. I think it would be nice to have a hand-tunable dungeon generator, or at the very least good front end for seeing what different parameter tweaks do. In any case, it would output some sort of JSON for the built dungeon. While the front end would be in Java, it would just run as a desktop app. You could then use the JSON dungeon file wherever you wanted.

About the list of tile types, I think it might be a better idea to leave such list mostly unspecified. If there will be multiple generators, most likely some of them will introduce totally new or adjust previously used tile types. Leaving the precise list of types to the concrete generator module documentation should be more flexible. If there is a need for post-processing, such list may be converted to the one more convenient to the application by a simple lookup table (optionally grouping types, specified too precisely for application to handle).

Also, depending on intended complexity of generation, it may be useful to allow querying tile 'properties' like water depth, glass opacity or portal ids (for entrance-exit pairing). Simpler applications may just stop on tile types (if applicable) while more sophisticated ones will take advantage of more detailed description.

You're right about translating being a potential difficulty with too-strictly defined starting points. That's an area where a language like JavaScript would be useful for just shoving things in as you go and sorting it all out later. The way you stated the problem though makes me think of some new approaches I could take in handling it