Steven Portzer

@sportzer
7 Followers
55 Following
35 Posts
Occasional roguelike developer
Pronounshe/him
My Gameshttps://sportzer.itch.io

I've submitted my #7DRL entry: https://sportzer.itch.io/unremembered-vault

I don't generally use pre-existing tilesets, but 32rogues by @seth happened to work really well for this

Unremembered Vault by sportzer

A roguelike where you outmaneuver a handful of unique enemies and take them down with a variety of weapons

itch.io
I've hit the point in #7DRL development where productivity drops because I'm getting distracted playing the game instead of actually working on it. I guess that's a good thing, but I still need to finish the thing.

Messing around with including hallways. I'm placing hallways first and then adding rooms around them.

The hallway placement logic is placeholder. I'd prefer the hallway segments to be more connected, but it's not bad as a first pass.

I probably also need to improve the room placement logic since it's currently generating a valid placement only around ~5% of the time. Having hallways which are narrower than the smallest valid room breaks a lot of the assumptions I was using for room placement.

Here's some more examples showing off the flexibility of the approach.

The first tries to place larger rooms first and then falls back to placing smaller rooms to fill any remaining gaps.

The second tries to place long narrow rooms first and falls back to shorter rooms.

Bonus images: here's the same algorithm run with different room sizes. Interestingly, with the larger rooms it still succeeds roughly 75% of the time.

One thing that does have a big effect on failure rate is the range of room sizes. Restricting the range of possible room sizes down to between 2 and 4 results in a success rate of only ~33%. I'd guess it's mostly due having to place more rooms (since the average room size is smaller) so there's more opportunities for problems to arise.

A nice thing about just placing rooms randomly is that it doesn't rely on the area you're trying to fill being a perfect rectangle, so you can use more irregular shapes or preplace certain rooms. Here's the algorithm run with a very big room preplaced in the center.
Here's an example failure. It would be possible to place some additional rooms in the red area, but that would require adding walls which are too close to existing walls without being fully aligned with them (which tends to cause problems). AFAICT there isn't a way to fully fill the red area with validly sized rooms. In practice, trying to place more rooms once we're at this point very rarely succeeds. I'll probably just handle these failures by retrying the entire generation process.
I'm back to generating random room arrangements. The method used here is to just randomly place random sized rooms in random locations. I reject any rooms that would create gaps which are too small to ever fill with rooms. I also avoid placing rooms in certain circumstances where it wouldn't necessarily prevent filling the entire space with rooms but does tend to cause problems. Sometimes it'll fail to generate a valid room tiling, but at the size pictured below it succeeds ~75% of the time.
Another variant I tried is post processing the irregular grid to sometimes merge 2x2 and 2x1 groups of rooms into a single larger room. With the fixed checkerboard of intersection constraints it would be impossible to ever merge anything if the room sizes were continuous, but I'm using an integer grid with a lot of the rooms being 2 or 3 wide. So in practice there's enough wall alignment that happens by chance rather than due to constraints that you can do a lot of merging.
I mainly took that approach since it straightforwardly handles both keeping the rooms on the edges of the map reasonably sized and having overall map sizes that can't be evenly divided into square rooms of equal size. But, an added bonus is that it doesn't assume anything about the intersection constraints, so you can seed them randomly rather that using a fixed checkerboard pattern. Though I think it actually looks a bit less random since it's less consistent about breaking up straight lines.