[FEATURE] Map generation with barriers and calls to tunnelers

[rabbitfr]

Hi,

It would be really nice to be able to populate a dungeon map before generation to add these 2 features :

• Barriers to prevent pathways from linking areas on either side of them
• Mark some cells for a tunneler to start digging its way to link up with the rest of the map (when its generation proper begins)

These two features will allow prefabs integration as described in

https://www.gridsagegames.com/blog/2017/01/map-prefabs-in-depth/ https://www.gridsagegames.com/blog/2014/07/dungeon-prefabs/

Secondly, it will also allow cyclic generation :

http://ctrl500.com/tech/handcrafted-feel-dungeon-generation-unexplored-explores-cyclic-dungeon-generation/

See also below screenshot :

Will be happy to discuss the feasibility of these features on IRC or here.

[tommyettinger]

These sound good, but I don't understand the second request. By, "Mark some cells for a tunneler to start digging its way to link up with the rest of the map (when its generation proper begins)" do you mean start and end cells for things like MixedGenerator.putBoxRoomCarvers()? Or do you mean connecting two separate dungeon maps, making them some kind of sub-regions of a larger map?

It might help me understand what you want if you post some pseudocode for how you would prefer to call this kind of generator (not necessarily any implementation, just how using it would look).

I think MixedGenerator can do a lot of this already, but it might not currently expose much of the functionality in a usable way. There is an internally-tracked grid of barriers that block cave and room generators from spreading into them, and some corridors are allowed to break through those barriers to form a door. It's a little complex, but the MixedGenerator constructors that take a Map should already allow a lot of arranging rooms, like MixedGenerator(int width, int height, IRNG rng, Map<Coord, List<Coord>> connections).

[rabbitfr]

Hi @tommyettinger,

For the second request I mean sthg like adding a prefab in an empty map

#####
#   #
#   #
##+##

where + needs to be connected to the rest of the map.

The idea of connecting two separate dungeon maps is also really nice :) by adding + at a map border.

For the implementation I was thinking of a character convention where :

! means `barrier`
+ means `need connection to the rest of map`

[tommyettinger]

So the connection thing, does a + act like the endpoint of a carver? (I'd also suggest using & to mean attaching this room and this dungeon together, since + is used for closed doors currently). Does a + or & have to attach to a walkable cell, or to some stricter requirement?

I'm also not totally sure where barriers should be placed and if it's OK for "piercing" corridors like those connecting walled rooms to be able to go through those barriers. I think this should be implementable once this is all more clear.

[rabbitfr]

Hi,

It's on purpose I used + to mean "carve to this door to make it accessible from the map but keep the door in place"

#####
#   #
#   #
##+##
 # # 
 # # 

The '&' may be used to mean "carve to this position to make it accessible from the map and clear blocks"

#####
#   #
#   #
## ##
 # # 
 # # 

I think that "attach to a walkable cell" is the only requirement.

Another sign may be used to mean "you may carve throught these but it's not guaranted"

like in

#####
?   ?
?   ?
##+##

which may lead to

#####
#   #
#   #
##+##
 # # 
 # # 

########
#    
#   ######
##+##
 # # 
 # # 

but the only guaranteed access will be from the southern side.

For the barriers the idea is sthg like that :

where you can see 2 prefabs which needs to be connected and 2 vertical barriers (in light grey) wich prevents carving.

[tommyettinger]

Oh my god. I JUST noticed that there is an incredibly faint dark gray outline around the round shapes; you really need to get your monitor looked at, @rabbitfr if that outline looks like "light grey" (This is what SquidLib calls Light Gray). I knew I was missing something looking at those images, but I couldn't tell what. I think that outline around the round shapes has holes in it, but it's so close to the black background that I can't tell what is intentionally placed in that image. I think a hole explains how a door was attached to the round part of the northwest prefab?

I'm not really sure what I should be looking at in any of these images, but I think the idea is that the prefabs will be given during initialization, already placed on a mostly-empty map by someone writing code that calls SquidLib, and then SquidLib's job will be to add rooms and "corridors." The white sections between rooms don't act like the 1-or-2 wide hallways used by other dungeon algos for their corridors, so maybe we should call them something else? Passages? They'll still be categorized as corridors... Anyway, the rooms and corridors can't overlap existing prefabs, so there will probably be some algorithm used that places rooms at random, moves or removes rooms to avoid overlap with prefabs or other rooms, and places corridors between rooms (maybe with a straightening step that chops off sections of non-prefab room that stick too far into a corridor). There is a possibility this algorithm can fail if there are too many prefabs that can't be connected; I think that's fine since people using this code shouldn't be putting in dozens of prefabs into a small map anyway.

I'm still really unclear on what the end product will look like, but I think I have enough of an understanding to try now.

[rabbitfr]

Sorry ! That screenshot is not from me and the first time I didn't get the 'gray' lines too :)

[tommyettinger]

I saw the lines, but there's more of that same color around the other prefabs (the two almost-circles have almost-black and actual-black around their edge). Getting the rooms to line up along straight edges for the corridors will be challenging; is that something you want or just a feature of these examples?

[rabbitfr]

for the color around the two prefabs see my comment on Mar 28 about "Another sign may be used to mean "you may carve throught these but it's not guaranted""

2.

the 2nd feature "Barriers to prevent pathways from linking areas on either side of them" is a requirement to
allow cyclic generation as described earlier.