Generating rooms from external layout

I’ve been trying to generate rooms from random layouts and it’s working out nicely.

However, there is 1 issue when I want to create an exact number of rooms. Somewhere I made a mistake with my counter variable NumberOfRooms, as it never returns the exact value of 10 and it mostly overshoots.

Logic behind it is pretty straightforward, sorry for the long event sheet.

How many of each Gizmo side objects of what I assume are placeholders are there? Could you post a screenshot of the scene? I’m having a bit of a problem visualizing your process. I don’t want to make a bunch of assumptions.

I don’t think the pick a random object does anything. If the for each object and pick random are using the same object name then there’s only ever going to be the current for each instance to pick a random object from. So, the sequence will always be the same.

You are correct. Gizmos are used as placeholders to check what kind of layout I want to create on it.

This is a starting room that is placed by hand on the scene. From here all other rooms are being placed.

Example of a room from a layout that contains openings from top, bottom and right.

layout1

Example of a room from a layout that contains openings only on bottom.

I have layouts for all possible combinations.

And this is how it looks when room generation finishes, it lines up all the rooms as it should. However, the room counter is almost never 10.

EDIT: However, I noticed if I make a few changes (highlighted green) I get the correct number of rooms. The changes feel very wrong though.

I think the problem might be that if the rooms is less than 10 It adds a room that could have more than 2 doors.

Possible situations
6 rooms exist add room with 4 doors. Adds 1 room and 3 doors require end rooms. 10 rooms

7 rooms exist, adds room with 4 doors equals 11 rooms.

Since it’s doing one direction at a time, it could also add a room on top with 4 doors as room 8 and room 9 could be a room on the left that has 4 doors. The end rooms get added separately.

Maybe, for your counter instead of adding 1 it needs to add the number of new doors.

Edit: you might also need to generate a random number based on the current number of rooms.

If it’s 9 you add an end room but if it’s 8 then you can only add a room with 1 or 2 doors. 7 then 3 doors and <= 6 you can add any room.

By implementing this, the variable always shows a 10, but the actual number of rooms is different. I’m not sure how to implement amount of new doors to the counter variable.


I like to test code before I make suggestions. Especially, projects that are challenging or interesting. This is both. I would prefer to use an array for the layout name and maybe # of doors but I don’t have the time to get into that.

This is how I did it. I only added one direction but the others would use the same technique. I’m not saying this is the best way.

I didn’t understand how you were placing the rooms because that part doesn’t show with the add layout action. I choose to use the position of the Gizmo object in the for each object and add to the x,y. IDK if I have my layouts setup different but the delete with the nearest object was deleting the default red sprite. Since I was placing the layouts next to each other, I decided to use a collision condition.

I started with a room count of 3 because I decided to basically count ahead.

Use as much or as little as you want to.

My project: (escape is used to restart the scene just for testing) Since my project only goes in 1 direction, it doesn’t always create 10 rooms or 10 doors.

Try it. Escape restarts.
Since my project only goes in 1 direction, it doesn’t always create 10 rooms or 10 doors.

IDK how you plan on preventing rooms from wrapping around or stacking on top of each other if there are too many turns.

I’ve tried doing it the way you did, but I haven’t been able to do it with my layout. And as you said I couldn’t find a way to check if the rooms are overlapping.

I’ve tried many different things but I’m getting mixed results, sometimes it’s working, most often not. And even when it works, the layout of the rooms seems like it is not a true random, in a sense that most of the rooms created are with 2 doors or dead end.

Here is my project if you want to take a look. There are layouts for every possible type of room ( I could have added some extra more that weren’t needed on accident).

https://file.io/9btNvEYHds97

I’m not going to be able to look at your project right away. Maybe tomorrow. This is a new concept to me as well. Check the forum or Google it. Even if it’s for another programing language, it will give you a path; a method.

Edit: Your file is showing deleted. If you still want me to look at your project, let me know.

That’s alright. I managed to do it. The only persistent problem is that it sometimes takes too much turns to create the full layout. The issue is most likely that rooms overlap too often, so generation restarts a lot of times. I have to think about what condition to put in place to reduce the chance of overlapping.

Thanks for looking into this.

1 Like

You’re welcome. Good luck. I’m intrigued by the concept. So, I restarted it from scratch. Instead of using different rooms for each direction, I decided I’d just use the same rooms and delete doors.

This version only adds rooms with 4 doors except the last rooms. I also need to work on the overlapping rooms. I started to add a condition to count the number of doors. It needs work. The numbers are the external layout. You can see when layouts overlap. I also made objects draggable. So, I can examine things at runtime.

I decided to place the rooms based on the picked connector. I pick a connector and then the opposite one in the new layout and align the 2.

Try it:

source:

It’s based on my former version. There’s still leftover variables and resources. It also draws a green dot to help debug and rotate multiple doors. I add the last room separately, That also needs to check for multiple rooms.

Sorry about the file, it gets deleted after 1 download. I think someone else downloaded it. I uploaded it again.

I took a look into your events and I’m glad you are using while loop, because that was my initial way of doing it and it seemed more appropriate, but decided to drop it as I deemed it too complex for me.

I do not take starting room into account when counting number of rooms. So I actually have 11 rooms in total, but generating 10.

As I mentioned before, my estimate is that on average it takes around 20 seconds to generate rooms so it might take a while before it is finished.

EDIT: More importantly, if the room generation goes for long enough it fills up the memory very quickly since it’s constantly creating layouts and when it reaches the threshold, white screen appears and crashes the preview.

Ok, I got it. I see what you mean. It can take a long time to create a valid map. You definetly need to find a way to check for a valid location before adding one. Maybe through a collision, a ray cast or point is inside. Let me look at and I’ll see if I can think of an easy method.

I added some events to find out why it’s taking so long. I had it add a text object with the current number of rooms as the value. I disabled the events that cause the scene to restart on collision.

In this one, it added 5 but 1 was above it. (there is a top door under the “5”
When it added 8 it didn’t know that 4 had a door going to that position. Also, 2 was above it.
image

It’s not just a matter of checking if there’s a room next to the new room but also all of the spots on each side of the new room. Also, the door. There could be a room but by chance the door might line up.

I’m not sure how to make it so it fixes the rooms instead of just running through all of the configurations until it gets a valid setup.

I added these events to the last line of each gizmo group to add the text objects. You would to create a boolean variable for the room object and set the instance value (not default) to true. When you add a room it’s placed boolean is false, you select all the false ones, add the text object and set the boolwena to true. Just add a text object name it RoomtText with the font size to like 350.

Did you try using the event that was disabled at the top of the event sheet ( Gizmos is in collision with Rooms; Delete gizmos) ? Not sure if you meant that when you said “it’s not just a matter of checking if there’s a room next to the new room”. I’ve found that it reduces the time of creating the full layout (most of the time) and the layout created looks more random. Though, it still uses brute force until it comes up with the solution and I’m not sure if layout will be created correctly every time ( I’m still checking this).

But to be honest, even if it takes around 10-20 seconds is okay. Maybe I can put up a loading screen until it is finished. What worries me now is that memory gets flooded quickly and game slows down when rooms are generated this way. You can check it for yourself in the task manager.

I don’t know if there is a way to clear the cache when layout is created?

EDIT: Nevermind, layouts are created incorrectly sometimes with this event. I will add the lines you did and dig some more.

1 Like

I didn’t find any other way except by brute forcing it yet. However, I did manage to resolve the issue with the memory leak finally. The problem was that variables were being stored in memory and they were building up very quickly after each restart of the scene. So, instead of having object variable randomizer for each gizmo, now I instead have scene variable randomizer. I also noticed that I can’t have any text or panel sprite on the scene, as memory leak happen then as well.

Before every restart of the scene, variables need to be deleted from memory.

I am using this extension.

Rooms sometimes still take around 20 seconds to generate, I can see it being even longer in some cases. Reducing the number of possible combinations could lower the generation time.

EDIT: added a condition to delete gizmos that are in collision with gizmos, it reduces the chances of rooms overlapping by a little bit

I noticed it sometimes started to lockup. Would using nothing but global variables help? You wouldn’t need to destroy or recreate them.

I believe deleted objects also stay in some type of cache and get reused. All of the restarting might happen too quickly for the app to clean up.

What if you didn’t restart the scene? Would it be better to delete all of the rooms and then add the starting room from an external layout like the orher rooms.

The syatem wouldn’t have to repeatedly purge everything.

Maybe there’s a way to modify the rooms or delete just the last room and eirher try another random room or a specific room.

IDK, I’m just brainstorming.

Global variables wouldn’t fill up the RAM? I can try with them if that’s the case.

I believe too that deleted objects stay cached and restarting happens too quickly, but I haven’t had any issues with slowing down because of that. Not sure how it would behave when there will be more objects and actual tilemaps.

I don’t know how to discriminate, one by one, what rooms are wrongly placed, or which door of which room should be closed out first with the deadend. It definitely looks ugly when scene is restarted so many times so quickly.

I tried not restarting the scene, where I would delete all objects except the first room. Then I would just try creating again, but I’m not sure where did it go wrong. Rooms were all over the place. I will probably try this route again.

To guarantee a set number of rooms, I think you need to count forward. If you start with a 4 way room then that’s already a minimum of 5 rooms. The 1st room and 4 other rooms. So, you start with a room count of 5.

When you add a room, you only count doors that add a room. So, end rooms wouldn’t increase the room count because they would already be expected.

Since 1 door would always connects to an existing room, you would add the number of doors minus one to the room counter.

A room with 2 doors equals 1 new room.
A room with 3 doors would be 2 new rooms.
A room with 4 doors would be 3 new rooms.

Once the counter hits 10, any existing gizmo objects would get an end room which are already planned for.

As far as valid rooms? I don’t know.

1 Like

That’s a really good way of counting, totally forgot you did it in your example. Thanks for reminding me.

1 Like