Skip to main content

Real dungeons.



Progress  as of this afternoon. Some areas are still not being linked. I'll have to take another look at the linking algorithm. There's also something funky going on with the tunneling algorithm. In some cases it seems to be going a few squares in the wrong direction before doubling back. I think I left out a stage in the old A* script that I used, I'll have to switch it with the more developed (but more complicated) one I was using for movement in the main game.

Anyway, today I want to talk a bit about dungeons.


What does a dungeon look like? I've chosen perhaps a rather strange style of dungeon, with small packed areas linked by winding corridors. You don't need me to show you a roguelike dungeon from times past but here it is anyway:


Long corridors and rooms. Nothing special. other roguelikes from more recent times have used different types of dungeon generation. Often a theme is to try to pack in more rooms in to the smallest space to get the most of your array. Empty space is often seen as a bad thing. Sometimes I've seen levels made up of only rooms, with doors linking directly to other doors. Maybe this plays really well as a roguelike dungeon. Maybe it makes things like pathfinding and AI more efficient.

Do real dungeons look like that? Surprisingly not.

What is a real dungeon? Well there are lots of reasons for building underground. The catacombs of Paris, the tomb of Tutankhamen, the underground bunkers of the cold war, storage and living areas below WWI fortifications. Each example is different and has a different layout but they share some key features. I've walked round several castle dungeons in the past, both here in Korea, Japan and back in England and each has its own design philosophy.

Here are some examples of underground structures:





You'll notice that they are usually built as a long rectangle rather than a square, and that the usual layout is long tunnels joining smallish rooms or groups of rooms. In fact a usual method of building an underground structure is to make a long tunnel, enlarge a section of it and then partition that section in to smaller rooms. It's easier to make a large room first and then put in dividing walls than to make several rooms in different parts of the tunnel because of the way tunnels are built. Also when people live underground they like to make areas for different functions, just like in a castle above ground. You really do have torture chambers, food storage areas, underground libraries and war rooms which are not just a single room, but a collection of rooms close together.

There are other reasons why I've designed my maps like this. If you look at traditional pencil and paper roleplaying maps they follow a similar layout, but not always for the same reasons.

For a dungeon master it's important to be able to control progression through the dungeon to allow them to follow a narrative. There will be points where the players can make a choice about where to go next, take the left or right turning for example, but they will be placed between narrative encounters. You can't have players running around opening every door in the place and having all the different monsters and NPCs come running out to find out what's happening.

Areas or levels of a large dungeon are also often set up so they will take a single gaming session to complete. You don't want to have to go home halfway through an encounter.

These are issues that affect my game too. I want the game to be in manageable chunks. You can clear out a section of the dungeon, check out the loot and then save the game and quit, all in a short time. Narrative areas are important too. In my project prefabs are the way I control narrative and create puzzles. Prefabs are set up to have an entrance and exit (sometimes the same place) and many have a puzzle element. For example you kill a boss and get the treasure. You find a room with a locked door, on the floor is a key, but it doesn't fit the door. Nearby you discover a hidden door to a room which has the real key. I need these prefabs to flow and changing the position of the door, or having a linking corridor cut through in to a room will disrupt a prefab and kill the puzzle.

There are other factors too. In this game you'll be controlling a party of adventurers, not just a solo hero. Formations and character placement are important, so a mix of different types of rooms and corridors is important to tactical considerations. A corridor is two characters wide, this means you can make a shield wall there. But you can't fire arrows or cast spells through another character, so corridors are not good locations for ranged combat unless you're ready to reposition your characters quickly.

There are many different ways of generating a dungeon, I have to choose one that works for my game, even though another might be more popular for other types of games. If it looks real or not, or if it looks good is not important, the important thing is if it is suited to the game play. Hopefully we'll find out about that sooner or later.

Comments

Post a Comment

Popular posts from this blog

Automating Level imports from Blender to Godot

  Recently I've been making some levels in Blender an importing them into Godot. There are only about 7 or 8 shaders for each level, not counting dynamic objects which will be added later. But to improve rendering performance, it can be a good idea to split the meshes up into sections. At that point you might be faced with a list like this: Or it might be even more chaotic, if you didn't use simple names for the objects in your level. So it can take a long time to sort out all the meshes, make them unique and add textures and so on. Blender imports with simple Blender textures, or with placeholder materials. This is sometimes OK, but if your Godot shaders are very different to those used by Blender, it means applying new materials to every mesh object in the level when you import the scene. I found that during the design process, I was importing and readying a level several times before I was happy with the final layout. So at first I was wasting a lot of time. In Blender, I us

Dynamic terrain in GODOT

Long time no posts. I haven't been keeping up with the projects I started. At first it seems fun and exciting, but I always run in to limitations in the setup, plus the grind of just making stuff without any real challenges... It ends up being something that I don't want to commit to. So right now I'm just messing around with some ideas and see what comes out. No commitment to a bigger project, just some time to try new things. This week I've been working on procedurally generated terrain.  In the past, there were some big limitations on how I approached this, because the game world had to have the whole map, from the micro to the macro. I had to choose a scale somewhere between, which meant I couldn't have really large maps, or really small details. I think I've found a way around that. Below you can see two types of map data coexisting on top of each other. The wireframe is the collision data, used for physics and for clicking on the map, to move characters ar

Make your game models POP with fake rim lighting.

I was watching one of my son's cartoons today and I noticed they models were using serious amounts of simulated rim lighting . Even though it wasn't a dark scene where you'd usually see such an effect, the result was actually quite effective. The white edge highlighting and ambient occluded creases give a kind of high contrast that is similar to, but different from traditional comic book ink work. I'll be honest, I don't know if there's a specific term for this effect in 3d design, since my major at university was in traditional art. I learned it as part of photography. You can find plenty of tutorials on "what is rim lighting" for photography. It basically means putting your main sources of light behind your subject so that they are lit around the edges. It can produce very arresting photographs, either with an obvious effect when used on a dark subject ... ..,or as part of a fully lit scene to add some subtle highlights. See ho