Dungeon 176

A random idea for an interesting dungeon layout may give me some more insight into the tools needed for designed dungeons.

While dozing this morning and thinking about not getting up yet, I started thinking about Bryan’s dungeon builder, which we looked at during Friday’s Zoom Ensemble, or, as Hill calls it, Geek’s Night Out. Bryan uses a different approach from mine, and it gives him a bit of trouble.

Thinking about a new scheme, different from mine and his, I quickly ran into a case where my idea wouldn’t work for him. But it looked, in my head, like it could lead to a very interesting designed level using my current toolset.

The idea I have is a narrow hallway all around the periphery of the dungeon area. There might be small 3x3 rooms at the corners if it looks better. Then there’d be rectangular rooms–I was thinking all the same size, but that’s not critical–all around the hallway, completely open on the hallway side. The various rooms would be stocked with treasures, monsters, and puzzles. In the central area of the dungeon, one of the rooms would connect to the final puzzle, boss room, or whatever. It might only open up when various other puzzles were solved or quests completed.

It would look kind of like this:

Whether that would be fun or not is almost irrelevant to today’s topic, which is to think, just a bit, about how we might represent such a dungeon in a dungeon-building “app” or language for our dungeon design team.

I think the basic approach I’d recommend to the designer would be to place four rooms at the corners. I’ve shown them of a certain size, but they could be made size 1 if the designer prefers. That might also give them another few tiles to work with in the inside. Let’s call those rooms 1,2,3,4. When hallways are drawn, we’d just connect 1-2-3-4-1, making the rectangle around the outside.

Of course, we lay in rooms before hallways, but now we can see that if we place our rooms abutting where the hallway will be drawn (or overlapping by one tile), the layout will appear as it does in the sketch. There’s just one more hallway needed, connecting the inner rooms. The easy connection would be centered. To place the connection as it is in the sketch, we’d have to do something special. Putting a 1x1 room at that point would amount to a hallway.

The tricky part of a manual layout, at least for me, is the arithmetic. We’re in an 85x64 space, or maybe an 86x65 space, since there’s those two mysterious + 1s here:

function Dungeon:createTiles(tileCountX, tileCountY)
    self.tileCountX = tileCountX
    self.tileCountY = tileCountY
    self.tiles = {}
    for x = 1,tileCountX+1 do
        self.tiles[x] = {}
        for y = 1,tileCountY+1 do
            local tile = Tile:edge(x,y, self.runner)
            self:defineTile(tile)
        end
    end
    return self.tiles
end

I think that’s in there because I didn’t want rooms coming right up to the right or top edge of the space. But it’s one of those legacy hacks now, that no one remembers and no one is quite brave enough to remove.

Anyway, point is, when we lay out a dungeon like this one, or any one, really, we need to end up knowing the corner and width/height, or the two corners, of each room. And we need to leave at least one tile of space between them, or the rooms merge into one larger room.

So, supposing that the little square corner rooms are 3x3 in my sketch, we can count in and out to see how much space we have for rooms. Looking at the bottom room on the left, and supposing we can just count the tiles that we see, that first room needs to start at (6,4), assuming we start it adjacent to the hallway, not on top of it. Similarly on the lower right, the lower right corner of the room over there is at (80, 4). So we have a total of 80-6+1 tiles to work with, i.e. 75. Unless I’m off by one.

Then we think about how best to fit reasonable sized rooms into that horizontal space of 75 tiles, remembering to leave at least one tile between each room pair. At this point, I start counting on my fingers, and I don’t have enough fingers. We can have:

If this is right, the general rule is that each of N rooms can be (75-N+1)/N wide. And it may or may not be right. I’m terrible at fencepost problems.

What tool do we need for this? Probably the designer would like to sketch, say, the enclosing rectangle for the inner space, and then ask to have equal sized rooms allocated across.

I’m already thinking that if I were doing this, I’d want to view the layout. There’s just about no way out. We might imagine textual commands, or a graphical paint kind of thing, but either way, to design a dungeon, we’re going to want a graphical tool.

That raises an interesting question for our very small team. Since we only have one developer, and he works only a couple three hours a day, should we divert time to build him a better tool, or just have him plug ahead creating the few custom dungeons we want by programming?

Of course, like so many either-or questions, this is a false dichotomy. A better question might be: how can we best balance our time between building the Shipping App and the Making App, or between building the product, and building the tools?

In a real product situation, we often think of a tool that would be useful, but that would take a long time to build. When we’re faced with a long gap between now and our next feature, the tool will almost always get nixed. When we can think of ways to improve our tools incrementally, we can more readily justify the time to build them.

Now, since this series of articles isn’t just about getting a dungeon product, it’s about what happens when we try to get any product, I could pause dungeon development and divert to a dungeon building tool for a bit, and we’d learn something. But instead, I think what I’ll do is to try to improve dungeon building bit by bit, just as we try to improve the program bit by bit.

We’ll start on that tomorrow. I even have a couple of ideas that may be useful. We’ll see!

Thanks for reading!