Limit floor count

[Perpure]

Hello, I want to implement functionality to control overall amount of floors. For simplicity let's say I don't want any room to be lower than Z=0 or higher than Z=1, so it will be just a 2-floor dungeon.

As I understand, EventOnRoomAdded won't provide me necessary information about current room position in global space.

I've tried to utilize info about door positon in ChooseNextRoom, but it's also not enough here, since I can't delete current room at this point. The only thing I can do here is simply block doors for stairs that will lead to restricted floor, which is quite an ugly workaround. Or I can remove spawning any stairs rooms from first and last floor, but it won't work with 2-floor dungeon.

Also I had an idea of just marking doors type for stairs as "1st" and "2nd" meaning the floor, but this will require to duplicate all 1-floor rooms to match either floor. Maybe there are any way to have multiple door types for a single door?

So I'm realy running out of options here, what approach can you suggest?

[BenPyton]

Hi @Perpure

It's a really interesting issue you bring to me!

If I would solve this problem currently without modifying the plugin's code, I think I will do something like this:

• Rooms on multiple levels are "specials" (meaning with no other purpose than changing dungeon floor) with the first door in the list being the previous floor, and the others the possible new floors, and unchecking the Random Door in the room data of these rooms.
• Other rooms are only on one floor.
• In the ChooseNextRoomData of the dungeon generator, I would use the DoorData input to check the Z position and choose a compatible "special" room to avoid going too high or too low.

I know this is considered a workaround, but it should work correctly with the current plugin's version (3.0.1).

However, you can always change the plugin's code to suit your needs if you want a better approach to solve your issue. I will think on my side of a way to add this feature in a future version of the plugin, and if you come with some idea or implementation on your side feel free to share it here if you want! 😉

What I am thinking of as of now, would be:

• Add a new output in the ChooseNextRoomData function to use a specific door index of the door (instead of a random or the first one)
• Add a new blueprint callable function in URoomData (something named like GetCompatibleDoorIndices) to be able to find one or more door indices passing a user-defined predicate.

So, for example, we could use them like that:

• We create a predicate function (in blueprint or C++) that take an FDoorDef struct and returns true if the door Z position is between a min and max floor values we want.
• In ChooseNextRoomData we get the Z position of the DoorData input and update the min and max values of the predicate (eg. if we want an absolute min of 0 and absolute max of 5, the DoorData has 2 in Z, then min = -2 and max = 3)
• We then call the URoomData's function (what I named GetCompatibleDoorIndices above) with the predicate defined above on the door data we want to add, so we get all door indices that will avoid going above or lower the absolute min and max we have set. (if no door index is returned then the room can't be placed)
• We choose one (eg. randomly) of the door indices and pass it as the returned value of the ChooseNextRoomData function.

This is something I have not tested, so there may be some flaws in that method. But I will try to implement a feature maybe like that in the next version to fix properly your issue.

Best regards.

[Perpure]

Thanks for your detailed response!

I agree with your approach to solving this problem. The ability to define which door from the next room will be used as the connection to the previous is exactly what I was missing. I guess I can implement this, I'll see what I can do.

[Perpure]

Implemented this feature in my fork. By the way you should decide how to handle situations where user has choosen incompatible door. On the one hand it should just be prohibited, on the other hand this will allow user to create custom logic for door types. For example TypeA can be connected with TypeB, but can't be connected with TypeC.

[BenPyton]

Good to hear you solved your issue with this approach!

I think the better thing to do for the door compatibility would be to throw an error message if the returned door index is not compatible or out of range.

And also I thought of making it random like in the current version if the returned index is negative.

Then I could remove the Random Door boolean in the room data assets.

[BenPyton]

The feature has been added to the version 3.1.0 of the plugin.