Time to work a bit on the room definitions/templates, so that I can create dungeons with proper room layouts. One of the “issues” with rooms is how to connect them correctly. If two rooms currently “connect”, it looks like this:

Firstly, rooms point in every which direction and the doors lead to nothing when there isn’t a neighboring room. This is, of course, because all my rooms have doors in all four directions. For my first attempt, I added a direction for each tile and a secondary tile layer to rooms; here’s the editor for this (the orange arrows let me “paint” direction on tiles):

Once directions are specified, I can check them against the required directions and switch to secondary layout tiles as appropriate. The two toggleable editor modes looks like this (arrows are colored according to the secondary layer):

The second issue is that rooms don’t overlap, which is obvious in how they (mis)align (note the double doors):

Now, that’s a much easier fix. I simply make the distance between rooms one less than the room size:

This works because I always assume that the edge tiles are empty, walls or doors and the doors are always in the middle. So I can just not place duplicate tiles for walls and doors — nothing should conflict. I might change this in the future, but that’s the assumption for now, which let’s me not worry about a whole slew of complications.

At this point I did a bunch more dungeon generations stuff and realized some deficiencies in my approach. It sounds cool in theory that each room can “transform” to match entrances and exits. But it turns out I don’t actually want to do it this way, because I cannot have that many variations and future specifying of room contents would be cumbersome at best. For example, it’s hard to specify or assume “this room has a corner here, so there should be spiderwebs” or “this is a cave, so there are some organic features”. So, for my second attempt, I simply made the rooms specify which direction the room is for:

I am still keeping the secondary tile layer, but I’ll likely just use it for something else. Of course, explicit room directions now means that I need to make a bunch more rooms for each direction combination (the letters are the cardinal Up, Right, Down, Left directions):

But it’s not actually that many. From here, I can apply rotational “symmetry”. That is RightDown room is the same as UpRight room rotated 90*. Nothing in the dungeon really cares about being in a certain orientation (and if it does, I can make the room non-rotatable and add the remaining orientation). In any case, that’s a bit easier than having 7 more room assets (RD, DL, LU, RL, RDL, DLU, LUR, LOL).

This is also where having collections of rooms instead of individual rooms comes in handy. A collection can collect all the variations and possible direction setups of the room:

But the level definition only needs to reference the collections of principal room types:

I currently only have exactly 1 variation for everything. But when themes are introduced, the levels would use different (but potentially overlapping) collections of rooms.

Now all that’s left is to have the dungeon generator actually decided what directions it needs, find a matching room, and rotate it before placed.

While working on this, I further realized I don’t actually care what the exact directions are if I am always using Up as the base direction (and if I don’t, I can just specify the  direction explicitly). In fact, I only care about the 5 direction layout cases:

This also makes the code for comparing and searching for directions easier and somewhat more modular. First, I need to compare if room’s direction layout matches the required layout for the kind of room I want to place:

So the above places the right rooms. Now I only need to determine how I need to rotate each room, which is just comparing the principal directions:

And there we go, an approach that let’s me customize rooms differently based on their neighboring connections without a complicated editor.

Perhaps I could have avoided changing my approach and redoing some of the work. Perhaps a better initial design would have led me to the right answer sooner. But I think my framework is more stable after surviving the several iterations. And the direction/rotation approach is more robust than hand-specifying finicky room details and potentially getting it wrong. I’ve spent longer on this than I wanted, but at the same time, rooms are a core feature that I don’t want to get wrong.

MicroRogue DevDiary #6 – Room layout
Tagged on:

Leave a Reply

Your email address will not be published. Required fields are marked *