[BUG/Question] Choose Door called after IsValidDungeon

[VGO08]

Hello and thanks for all the project first,
I really appreciate your work and it helped me a lot for my project,
but i have on quick question :
Why is choose door called after IsValidDungeon?
I want to know how many unused door are spawned to know if its even or odd.
(Im trying to create a lethal company style procedural generation and also if you dont mind giving me some tips on how to reduce the dead ends because on some maps a lot of time i get really a lot of dead ends, what i aim for is more like 2-3 big zones but thats isnt my real question)

Technical informations

• OS: Windows 10
• Unreal: 5.3
• Latest for 5.3

Expected behavior
I expected that Choose Door will run before IsValidDungeon

I really appreciate your help and i hope i will find a solution :)

[BenPyton]

Hi @VGO08,

There are 2 main reasons why it is called after the dungeon has finished its dungeon creation:

• First, this function is called to spawn the door actors, this is done during the room level instantiation (which is the step after the dungeon had been created).
• Secondly, since this is used to spawn door actors, if the Is Valid Dungeon returns false, the generator would wipe the generated dungeon and start over from scratch, I the doors would need to be destroyed instantly. This is a waste of resources.

However, I'm thinking of reworking the doors in a future (major?) version. I think of adding a door data type to hold instance related data of the doors (for example the lock state, and the actor class) so we could set them during the Initialize Dungeon event, and the Choose Door call could be moved before the Is Valid Dungeon, so we can validate those data in the Is Valid Dungeon too.

I will not work soon on this feature, it could take months (or even a year if for the next major version) before I'm working on it.
Nevertheless, you are not without solution.
What do you mean exactly by "unused" doors? If you mean unconnected doors (room only on one side), then there is a solution.
During the Is Valid Dungeon (I recommend creating a function to encapsulate this logic, though), you can do that:

• Get all rooms from the Rooms variable, and get the room data in a for each loop.
• Get the door count from the room data and do a for loop on it.
• Check if the door is connected, and if not, increment a local variable (e.g. Unconnected Door Count).
• After the for each loop on all rooms has finished, do a modulo 2 on this local variable to know if it is even or odd.

Here a screenshot:

[VGO08]

Thank you so much i really appreciate the help, just after writing i had almost the same code but with slight difference that bugged it so really thank you !
But like now i tryied different things ect with the generator and i really think it goes a bit everywhere and with a lots of dead ends and some times maps are actually incredible but most of the time its a bit more one or two paths and some rooms right and left,
i try both gen methods and both are good but do you have any tips on how i can maybe enhance that a make it more connected between them,
I dont want to take too much of your time or annoy you,
Have a nice day :)

[BenPyton]

Well, it really depends on how you want your dungeon layout to be.

Before writing code in the Choose Next Room function, I would strongly recommend to design your dungeon layout on paper.

Someone linked me this blog post explaining how dungeons are generated in Enter the Gungeon.
My plugin does not work the same way, so you can't implement the same logic as they did.
However, I would suggest you to create a graph of your dungeon layout like you can see in the blog post (keep in mind that my algorithm generates one room after another, unlike in Enter the Gungeon).

After that, you should define your Room Unit appropriately: the smaller the Room Unit is, the less likely your doors will be able to connect (outside the doors that connect previous and next rooms).

So, keep something rather large to increase the chances of creating loops.
For example, in The Binding of Isaac, or in th old 2D Zelda games, one room unit is the size of the screen, so most rooms are of the same size, making it easier to arrange rooms without gaps between them and connect doors to make loops.

Another tips is to use breadth first generation (BFS) because the generator call Choose Next Room on all the doors of a room before going to the next room, resulting in a more large dungeon than long, and increasing the chances of creating loops.
While the Depth First generation (DFS) will call the function directly on the next room returned, resulting in a more linear dungeon and creating lots of dead-ends.

Finally, you should keep in mind that you don't need to fill the entire room volume.
Only the doors locations are important. You should choose the Room Unit depending on how fine grained you want to place your doors: the more precision in door placement (small Room Unit) the less likely the doors will be aligned properly to create loops.

[VGO08]

Ive tryied all of these just didnt really understand room unit
Here are the generations from my game and what i aim a bit for :




And thats what i want to approximately achieve:

Maybe with what ive actually done is ok but if you look closely with the debut lots of parts arent connected even i sometimes it make pretty things,
maybe its just me stressing a bit about all and i need to mess with the weight probability of the rooms but i think its better to get an expert advise,
thank you for helping me and have a great day !

[BenPyton]

Okay, it's better now with screenshots to know where you are.

So, if I understand properly your issue, your biggest concern is about those final corridors (pointed in orange) and you want more specialized dead-end rooms (pointed in green)?

If so, then I think your generation rules are too simple (from what I can see in your variables of your dungeon generator on your screenshots).

You ave many ways to get better results, I'll describe below some of them (I strongly recommend to mix them).

Split your room array into categories

You should make multiple arrays of room, for example a gameplay room array (storing the important rooms in your dungeon) and a corridor room array. You will have better control on what is generated when.
For example, you can alternate, one corridor and one gameplay room.
You can also choose randomly the array before choosing a room inside it, adding weights to their probabilities (e.g. 70% proba for a gameplay room and 20% proba for a corridor).

Create multiple array of corridors

You can also create "sub-categories" arrays of rooms that you can combine before selecting randomly a room from them.
For example, you can create one corridor array per number of exits (e.g. Corridors2 for corridors with 2 doors, Corridors3 for 3 doors, etc.).
Then you can join the arrays depending on the current state of your generation process (by creating a temporary array that is filled with rooms of the arrays you want to join together).
For example, you can use corridors with 3 or 4 doors at the beginning of the generation, then when you reached a specific number of room in your dungeon, you select corridors of 2 and 3 doors, and after another number of room reached, you select only corridors with 2 doors.

It's not mandatory to end the dungeon when reaching a number of room

In the wiki and example project, I'm using this way to end the generation, you can set any other condition to end the generation.
You can also always return true in your Continue To Add Room function and let the generation ends naturally when there is no unconnected doors remaining.
Be careful however in that case, you should make sure to either:

• Force your dungeon using only rooms with 1 door after a certain point in the generation
• Add a railguard in your Continue To Add Room to stop the generation after reaching a room count (could be a big number like 100 or 200) to avoid getting infinite loops (I will add this feature built-in in the next version).

Stop using corridors at a certain point

You can define a condition that when met will prevent the use of corridors.
For example, once you have placed all your mandatory rooms, you will just skip the placement of corridors and only place your specific gameplay rooms. It will feel less than a useless dead end for the players because even if they have to backtrack, they will have something to do at the dead end.
This point can be combined with the previous point if using dead-end gameplay rooms with only 1 door: no more corridor will be placed and you can let the generation end when all the remaining corridor doors are filled.

[VGO08]

Thank you, changing the generation to end naturally reduced walls spawned on unconnected doors from 25-30 walls to only 5-6 but for the rest it might change a lot in the quality of the generation but i was unable to do something i tried a random int with a bool to choose between random room with weigth of "Gameplay Rooms" and "Corridor Rooms" but each time i did it it gave me the Check IsValid function is valid? and because i cant do that i can do the sub array.

I didnt thinked about the stopping using corridor at certain point but do you mean when for example the Minimum nuber of room have been placed, there is a lot i need to learn and improve so could you give me hints and tips to when and how to achieve that,
Thank you again for your help

[BenPyton]

What do you mean by "but it might change a lot in the quality of the generation"?
Do you mean a change in good or bad quality, comparing of what you have currently?

could you give me hints and tips to when and how to achieve that

Well, I don't know what you exactly want and what you have coded currently...

First, if you didn't done that yet, write down on paper (or in a text editor) what dungeon layout you want to create (what rooms, how they place themselves according to other rooms, etc.).
Draw a graph if possible of your dungeon layout on paper (or any drawing app, like this one).

Note

The screenshots of what you want in your previous message don't really help, because they're too dark and I don't understand the layout of the dungeons.

Once you have your description and/or a drawing of the graph you want to achieve, please share them here so I can help you coding your dungeon rules.

I'll share you here a screenshot of Choose Next Room I made for someone else on Discord, to show you how to make a branch based on a probability:

You can change the secret room array by your gameplay rooms, and normal roo array by your corridor rooms.

It also shows you how you can stop using room corridors based on a number of room and after you've placed specific rooms (the first branch).

Maybe this will help you setting it up.

[VGO08]

Thats great,
Okay so let me tell you what is my objective,
before let me clarify i wanted to say change quality in a good way for sure and what i've coded is only like what you told me and the wiki/other guy issue (37 or something) nothing more,
My game has different "maps" that are house, mall, shop, factory... for the horror-multiplayer genre,
like a "real" design for mall and most of large places they have limited dead ends, sometimes a sort of maze-like and different paths design,
there isnt a need to have a specific logic (like next to the bedroom a kitchen and two bathroom in a row ect) but really my main points are limited dead ends and a maze-like design,
I don't also think there are any "special" rooms i want to add, could you clarify "how they place themselves according to other rooms" ?
Also im really sorry of the poor image quality i've provided to you here are some better ones that i have found on google:


so in the first map you can the real layout in game of what i wanted to show you, ignore the colors they are useless here
Second image is an inspired design but works well with what i want, you can choose multiple paths that can go to a location or a same end location of another paths (also here you can ignore the legend i don't think it's useful),

[BenPyton]

Okay, I think I will be able to help you better now.

there isnt a need to have a specific logic (like next to the bedroom a kitchen and two bathroom in a row ect)

Well, there is always a need to have a specific logic. you can't just place a bunch of rooms randomly in a total chaos.
It's not always logic about placing specific rooms at specific order, but more like "constraints" or "rules" so that the whole dungeon layout will looks like something real (like you said a house, a mall, a factory, etc.)

First, if I analyze your examples, you can see that you can draw a grid on them.
This grid defines the Room Unit of the dungeon and will help the creation of loops.

Example of a Mall-like dungeon

Now, I will take the mall to create an example of a simple dungeon layout.
This is to help you understand the process behind creating your code based on a desired result.
I hope you will grasp the idea behing and you will be able creating any dungeon layout you want after that.

Basically, a mall is composed of 3 types of room:

• corridors
• shops
• large open spaces (which contain stairs in general to navigate through the floors).

Here a drawing of a layout we would want to generate (I keep it simple for the example):

Note

I have drawn only one floor of the dungeon to keep the drawing simple, but the open spaces are meant to have doors on multiple floors, so the generated dungeon will have multiple floors like a real mall.

We have our 3 types of rooms (blue for corridors, red for shops, green for open spaces).
I've made 2 types of doors:

• Doors connecting corridors to shops (in orange) that would have automatic sliding doors.
• Doors connecting corridors between them or with open spaces (that will have no door at all to create a feeling of continuity)

I've used only 4 rooms for that:

Note

Those rooms are just the room definitions (size and doors), but several rooms can be created for each of them (for example different kind of shops), breaking the feeling of repetitiveness for players while keeping the dungeon layout simple.

Now, we will have to deduce the "constraints" or "rules" from that ideal layout:

• 2 open spaces can't be directly connected.
• 2 shops can't be directly connected (if 2 shops are touching, the doors will connect but a wall actor will be spawned instead of a door actor).
• corridors 1x1 are less placed than 3x1 (about 20% 1x1 and 80% 3x1)
• corridors 1x1 are not connected to another corridor 1x1, unless no other possibility (see the upper open space with 3 corridors 1x1 connected in a row)
• open spaces are less likely to spawn than any other corridor (about 10% open space and 90% corridors)

Now, we can write the logic (in pseudo-code here) to tell which room will be generated after another.
I'll use the terms currentRoom for the room already generated, and door for the door used to connect the next room to the currentRoom.
I didn't created a "start" and an "end", so I decide to use an open space as first generated room, and stop adding corridorss after a number of room is reached (called minRoomCount in my pseudo-code).

if (door.type == shopDoor) and (currentRoom.type != shop) then
    return random shop from a list of shop room
else if (door.type == corridorDoor) and (rooms.count < minRoomCount) then
    randomNumber := get random number
    if (randomNumber < 10%) then 
        return random open space from a list of open space
    else
        randomNumber := get random number
        if (random number < 20%)
            return corridor 1x1
        else
            return corridor 3x1
        endif
    endif
endif

Note

This pseudo-code is a first draft and will need to be iterated on to get the best result. For example the percentage values can be tweaked, the conditions can be modified, new constraints can be added, etc.

Conclusion

We didn't wrote directly the code to generate the dungeon we want.
Instead, we've got through several steps:

• Defining what are the components (room types) of the desired dungeon.
• Drawing the resulting layout of the desired dungeon.
• Deducing the "constraints" or "rules" between the rooms
• Writing code from those constraints.

[VGO08]

Hello again,
I had some issues while trying to work on that,
First I had a problem with the probabilities, i tryed what you put before the code to select between "secret rooms" and "normal rooms" but for me the image isnt here anymore but still i had reproduced it and it doesnt work, i only get the "IsValid" Error and when i remove checks there is 3-6rooms spawning,
also i was wondering why we dont just use the function you created: "Get Random Data Weighted" that with one Map variable you can just, like you wrote in the Wiki, change values and it does change probabilities. I've had tryed it before opening this ""Issue"" and it worked well even if its not really precise for lots of different rooms.
Secondly, the recent "pseudo code" so maybe if i understand you removed old screenshot and advice me to use a similar code, if i dont misunderstand it is in the "Choose Next Room" Function, but i dont really understand how it knows the door type, is it set during the "Choose Door" function ?

I really appreciate your help, really thank you :)

[BenPyton]

It's weird the image has disappeared...
I'll update my old post with a copy of the image instead.

Please, tell me if my example of a mall-like generation in my previous post helped you understanding the workflow.

About your issue with probabilities

First I had a problem with the probabilities, i tryed what you put before the code to select between "secret rooms" and "normal rooms" but [...] it doesnt work, i only get the "IsValid" Error and when i remove checks there is 3-6rooms spawning,

Well, I would suggest you to post screenshots of your Choose Next Room Data, Continue to Add Room and Is Valid Dungeon so I can know exactly what you've done and where the error could be located.
Without those screenshots, I can't help you more on your "IsValid" error...

About Get Random Data Weighted function

The use of this function depends mostly on the use case, and can be especially hard to use for "static" or "global" probabilities.

For example, if you want a secret room to have 10% chances of spawning, I call that a "global" probability, because the secret room always have 10% of proba, regardless of all other possible rooms. In that case, it is better to do like I said in my messages above.

However, if you need to have a room A to spawn 2 times more than a room B and three times more than a room C, you can use this function with values 6 for room A, 3 for room B and 2 for room C. This use case is made easy with this function.

So, you are right I could have used this function in my pseudo-code to replace this part:

randomNumber := get random number
if (random number < 20%)
    return corridor 1x1
else
    return corridor 3x1
endif

with that to get the same result (the total is 5 so 1/5 = 20% and 4/5 = 80%):

return weighted random room [corridor 1x1 = 1; corridor 3x1 = 4]

About the door type

The Choose Door is used only to know which door actor to spawn. It is not used during the generation process.

You have access to the door details in the Choose Next Room Data, it is provided as an input of the function:

The type is the Door Type data asset you can create and set it in the Room Data asset.

You can easily do comparisons of the door type in your Choose Next Room Data (you can also use door position or orientation too)
If no door type is set (the default None), the Type in the Choose Next Room Data function will be null (this is the default door type).

[VGO08]

For the doors I now understand, I didnt saw that you could set the DoorType thats awesome,
also i understand better for the probabilities and it is actually better the first one you have told me (the one you have that "global" probability),
also the mall dungeon helped me a lot to understand how it works and the workflow
for the code in ChooseNextRoom I'm actually trying to do the last code you wrote, it might be better than the screenshot that disapeared,
Quick question about the screenshot, I dont understand how the Is Empty is used because I never add or remove Variables from the array (or the map that i use here so i can choose with probability which types and after in the map which room has more chance so a sort of combination)
Please tell me if there anything else you need to know and I will share as soon as possible,
Thanks for the help

[BenPyton]

Alright, I think I know what is wrong.

First, Your Continue to Add Room function has the opposite logic. You should return true when you want to continue the dungeon generation, and return false when you want to stop the generation.

Secondly, the screenshot that disappeared (and I re-added it to the original post) is a screenshot I've made for someone else.
I've just re-posted it here to show you the correct way to check a probability. The other nodes are not really relevant for your case.
In that screenshot, I've used the Is Empty because it was a requirement to generate one and only one room of each room data in list of secret room.
The secret room array is copied to a temporary array in the Generation Init event, and each time a room from this list is added in the dungeon, it is removed from that temporary array (in the On Room Added event).
This is why the temporary array is tested to be empty or not in the Choose Next Room, but in your case you can forget about this part.

So, this is the second part of what is causing your issues: since your Normal Rooms array is never empty, you will never generate the end room. And thus your Is Valid Dungeon will always return false.

With those modifications, your Ending Room will be placed as soon as you reach the Min Nb Rooms.

[VGO08]

It is actually working right now thanks for that but before this when I tried the natural ending generation it made less unconnected doors but now I've got an average of 40 blocked doors but maybe i've got a dumb diversity of modules and making less and simpler like yours 1x1, 3x1 and 7x7 might affect it ,
also with my current ChooseNextRoom it doesnt affect if a door is a shop or a corridor door, is it ?
Here I tryied doing it with the code that you mentionned before that checks if ShopDoor=CurrentDoor but here what ive got:


I even changed in the map all the value to two and the "stairs" to one and even that is the result up here
And here is the result with all set to 1:

We see that the doors match but why there is so much stairs and packed in a single tiny area because the other code made them spread and I had good results