My dungeon has a problem of being both too small and too large relative to player and enemy size and area they can comfortably fight in.
What I mean is that the player can travel a lot through the dungeon. At the same time, the rooms are tiny for actual combat. The hub above is pretty much the maximum single room size. There’s a lot of approaches to this and I won’t go into the details of every option I considered.
I am going to add arenas as main gameplay rooms. I will make my current “hub” rooms an internal-only designation for generation and connecting purposes, but spawn them in-game as halls. That way I don’t need any of the hub rooms and I can focus on having the same features in arenas. I do need to modify a bunch of things first before I can full-on remove hubs.
First, I need to be able to place arenas the way I want — the way hubs currently do without any hackery. I already previously discussed that I needed arenas placed without having hubs near them:
The way I “solved” it is by having halls end in dead-ends, place arenas at dead-ends, and then trim excess dead-ends. But that unfortunately doesn’t work for me any more if I am to treat hubs as intermediate connecting logical nodes. So, first I converted my arena logic to explicitly being an arena adjacent to an existing node, like a hub:
Then I can copy the step and make a new one for overlapping the source/origin node it connects to:
This adds a few additional steps, like re-connecting to previous connections of the replaced node. I also need the final variation of arena room with two doors. But it works out nicely, more or less (note the red arena entrance connection formed directly with halls):
Of course, I’m back to the whole “stuff too close” problem where arenas appear right next to hubs. I already have some similar logic to prevent this and I can add additional restriction for arenas:
Thankfully, these are similar enough that I can implement extended similar versions:
Another big thing was the bridges between hubs. It’s pretty easy to make a similar step for making bridges between hubs/arenas and arenas instead. And this works out nicely when there are compatible arenas to connect:
Of course, all the other hub construction steps are similarly lost on arenas. For example, “connect to halls” works, but there is no “connect to arenas step” (can be seen in above screenshot where arena is next to a hub without connecting). Or remove dead-ends should removed hubbed dead-ends too. So I need to add those as well.
All in all, I need to go through the motions of adding and tweaking the generation steps as I did before until it looks decent. And this didn’t actually take that much time, since I made things fairly modular and easy to modify and extend. And the result is decent (dark red debug circle are removed dead-ends):
Next step is to remove gameplay content (enemies, loot) from hubs and have it only appear in arenas. First, I have to never place anything in hubs. Then convert my content distribution to only have one type of “room” and use far/close flags to distribute loot. All of this is just finicky small changes that take me longer to describe than to do. At this point, I can pick hall rooms instead of hub rooms for actual room placement and just remove hubs rooms from the game.
One more thing is to actually generate arenas specifically close or far from start and mark them as such. For this, I can introduce the relevant restrictions and just generate arenas in two steps for each case:
And this works out nicely by biasing far arenas farther from the start and keeping closer arenas closer (green background – close; yellow – far):
I can also spawn the goal/exit room at a far arena this way:
I also thought that my branch logic (snakes, straight) would get a lot of use. But I see now that it’s mostly just overly complex branch generation code that’s not seeing any real use. In fact, I don’t even need snake branches. And then I can just as well trim all the branch overhead and just call it a “tunnel” step:
It also makes additional checks much easier (by avoiding various corner-cases in counting and checking nodes), such as:
There is just one important feature I lose and that is being able to make sure the tunnel actually forms a bend, if it’s just extending another tunnel:
In other words, so stuff this doesn’t happen:
All in all (lots of tweaking and step-by-step experimenting later), the dungeons look okay for now:
So now (that I have arenas as 2×2 joined rooms) the big step is to do something about the room sizes. I am thinking about reducing them by a couple tiles. This will either go fine or really badly. My argument is that arenas can now be pretty big:
In fact, arenas are bigger than I ever need them to be (and if I need them bigger, I will make 2×3 or 3×3 arenas). On the other hand, all the other rooms are now irrelevant, as they are all halls and connectors of sufficient size.
My rooms are currently 9×9 tiles big, and I will make them 7×7 instead, which mean there’s a room every 6×6 tiles (as I overlap walls/doors). The actual change is literally a single constant I have for the room size. And since I kept this number adjustable, that’s pretty much there is to it code-wise. I only need to fix the actual room assets, which got their edges truncated.
And the “resized” dungeon looks… well, almost exactly the same. The big change was removal of hubs, but all tunnels are pretty much the same width. The arenas are the only ones notably smaller.
Now that I’m using arenas, I actually need to adjust my content placement, because it only uses the top-left arena room and doesn’t know how to spread content across multiple rooms. So like this (of course, it won’t be this many in an actual game):
So I think this takes care of the major problem of the dungeon — being inappropriately sized for combat. I may need to invest a little more work into making the arena rooms, but at least I don’t need to make hub rooms any more.