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.


Post a Comment

Popular posts from this blog

Back to Vinland.

I'm going back to my real time tactics project, Vinland 1936.
While working on the other project I overcame the problems which were stopping me from saving/loading the game and also cleaned up the base code a lot.

After a few weeks I'm getting near the the state I was in before.

Infantry are back to their previous state, and vehicles are running OK.
This time I'm going to push ahead with mocking up the combat system though before I work any more on the vehicle builder or graphical aspects of the game.


I finished working on the code for adding foliage and having some extra time I decided to experiment with the code for rockets.

The original idea I had was that rockets would be large vehicle components that can be fired very quickly, regardless of how much manpower is used for reloading.

They would use up a lot of ammo, so they would run dry after a short but devastating barrage.
The problem here is that it's easy to take advantage of this by adding a lot of ammo, which is much smaller than in bulk than the rockets.

There's also the problem of firing large caliber rockets. In real life rockets of up to 30cm were used, but I think that will be too powerful for the scale of combat in this game.

lol. Somehow that one trooper survived the mother of all explosions...

A 30cm rocket could contain nearly 30KG of explosive. That would be a very large explosion.

I've tried to balance the game by using a simple equation to make bigger guns more powerful, but hopefully not too powerf…

Infantry combat and entering buildings.

I've been working a lot on the game recently and I've nearly rebuilt it to the level it was before. Past that maybe, since now I have the beginning of a working combat system and the ability to save and load the game.

Infantry can now occupy a building. It's quite an abstract representation, since they stay at the door and turn invisible. But they can then fire from one of the windows and take damage from shots at the windows too. I think I've set it up well so that when building damage and destruction is working then the system should continue to work.

For combat I tried some new ideas, but they didn't work out that well. It seems that it's important that viewing range should be further than shooting range. Now shooting range is pegged at 18 units of distance, while viewing range can extend out past that.

In the above image one unit has an officer, so has further viewing range. The other can only see as far as they can shoot, a dangerous situation since the en…