Over-engineering dungeon generation

[emulord]

normally I love ascii, but that is beautiful.
If this was incorporated into the regular game, I might have to try playing with tiles.
I dont like tiles with regular angband because the walls are boring, and stuff like Unangband has too many types of walls and floor that do different things. This has flavor, but not chaos.

[RogerN]

This post will attempt to summarize my thoughts on spawning monsters in the dungeon.

Most variants employ a monster definition list (monster.txt or r_info.txt) from which monsters are spawned directly. Monsters have associated depth, rarity, and flag values which indicate how they should be spawned. Wolves come in packs, for example. There are also some hard-coded pits which can spawn large quantities of a certain monster type.

Rather than employing just a monster list, I think the flexibility of monster generation can be improved by using the concept of an encounter. A monster encounter could be extremely simple, such as a single Ogre. It could also be more complex, like a Dark Priest escorted by a dozen acolytes and a pair of paladins.

Monsters would still be pulled from the monster definition list (monster.txt), but there would also be an encounter definition list (encounter.txt) which defines various ways to spawn monsters.

Now for some examples:

Name            := Single monster
Depth           := 0
Frequency       := 100
Spawn 1 Family  := SpawnSingle
Spawn 1 Depth   := 0
Spawn 1 Count   := 1


Name            := Pack monster
Depth           := 0
Frequency       := 20
Spawn 1 Family  := SpawnPack
Spawn 1 Depth   := 0
Spawn 1 Count   := 3d3

The above examples are generic encounters. The first entry is a level 0 encounter which will spawn a single monster. The monster must have the "SpawnSingle" flag to be eligible. Also, the depth definition for the monster (Spawn 1 Depth := 0) is a relative depth, meaning that the monster depth must be equal to or less than the player's current dungeon level.

The second entry is similar, but spawns a pack of 3d3 monsters of the same type. The monster must have the "SpawnPack" flag.

Now for a more complex example:

Name            := Dark Priests
Description     := You hear chanting.
Depth           := 10
Frequency       := 10
Spawn 1 Family  := SpawnSpecial|Pious|Human
Spawn 1 Depth   := 0
Spawn 1 Count   := 1d3
Spawn 2 Family  := SpawnSpecial|Pious|Human
Spawn 2 Depth   := -5
Spawn 2 Count   := 2d3

This is a level 10 encounter. It's somewhat dangerous, so there's now a Description associated with it. The description will be used to give "feeling" text to perceptive characters. As you approach the monsters you might receive the special text: "You hear chanting."

The encounter consists of two different spawn entries. The first entry creates 1d3 priest-like monsters, whose depth is roughly equal to the current dungeon depth. The second entry creates another 2d3 priest-like monsters, but with a depth equal to the player's current dungeon level minus 5.

One more example:

Name            := Plague of snakes
Description     := Snakes!  Why'd it have to be snakes?
Depth           := 5
Frequency       := 10
Spawn 1 Name    := Large Yellow Snake
Spawn 1 Count   := 4d4
Spawn 1 Area    := 20

The only new feature in this example is the addition of the Area parameter (Spawn 1 Area := 20). Instead of spawning all the snakes in a densely-packed glob, we want to spread them out over a large area. Monsters will be placed in an area which extends up to 20 tiles from the center of the encounter.

[bio_hazard]

That sounds like you could work in a little more depth to the types and behaviors of monsters- cool! I can picture finding arenas with sparring monsters and a mixed crowd of onlookers, prayer circles, mining operations, zombie factories...

[nobody]

i usually don't like tiles either, but this looks nice and exciting, especially console windows, don't lose those please

[fizzix]

Do your 'encounters' get seeded on the level in the same way that the monsters do? As in, X encounters get put on the level, and each turn has a Y% chance of adding a new encounter.

Also, along with your idea of 'you hear chanting' I always thought that a pack of fire hounds should be easily noticeable by looking at the dungeon walls and noticing that everything is burnt. Similarly, a pack of ogres should be detectable by someone who is searching for signs of them, and has some skill in tracking (i.e. a ranger). In my conception these would be programmable as terrain changes, but not visible ones. You'd be messaged though as you passed by a square that the floor was burnt, or that you see ogre tracks. Of course you could squelch these features like you can any other dungeon item. I'm fond of this approach because it reduces dependence on detection/telepathy and allows these spells to be nerfed, without losing fun in the game.

Anyway, good work, and congratulations on your daughter.

[RogerN]

Do your 'encounters' get seeded on the level in the same way that the monsters do? As in, X encounters get put on the level, and each turn has a Y% chance of adding a new encounter.

At the moment I'm not planning on generating new encounters after the level has been generated, but that's for gameplay reasons which I don't care to mention just yet

Also, along with your idea of 'you hear chanting' I always thought that a pack of fire hounds should be easily noticeable by looking at the dungeon walls and noticing that everything is burnt....

Those are great ideas and are a very logical extension of the encounter system. I'm not going to get that detailed for now, but it's something to think about for future releases - and for other variants which might want to implement a similar encounter system.

One issue I'm currently struggling with is an issue which Andrew mentioned in his discussions of Unangband dungeon generation. You've got these groups of monsters in your dungeon, and you'd like to give perceptive characters some sort of warning that they're nearby. Scorch marks on the walls, smells, tracks, whatever. The trouble is that these monsters are potentially awake and moving around - so where do you place these "warning signs" such that the player will encounter the warnings before the monsters?

Hmm... as I'm typing this post I just got an idea. Each monster could have a reference to the encounter from which it was generated. The flows table, which is already being generated for the monster AI, could then be used to determine if a monster was close enough to the player to trigger the encounter description. I can't think of any reason this wouldn't work pretty well.

You'd occasionally have stragglers, separated from the main group of monsters, which trigger the encounter description a little bit early. But I can live with that.

[Derakon]

If you set monster target pathing to stick close (for config-specified values of "close") to their leader if they can't see the player, then that would keep the group together. Then you could trigger the flavor text on getting close to the leader. This would require a singular leader for each group, though.

[fizzix]

One issue I'm currently struggling with is an issue which Andrew mentioned in his discussions of Unangband dungeon generation. You've got these groups of monsters in your dungeon, and you'd like to give perceptive characters some sort of warning that they're nearby. Scorch marks on the walls, smells, tracks, whatever. The trouble is that these monsters are potentially awake and moving around - so where do you place these "warning signs" such that the player will encounter the warnings before the monsters?

Hmm... as I'm typing this post I just got an idea. Each monster could have a reference to the encounter from which it was generated. The flows table, which is already being generated for the monster AI, could then be used to determine if a monster was close enough to the player to trigger the encounter description. I can't think of any reason this wouldn't work pretty well.

I had a slightly different approach.

1. When the level is created the monsters have some probability of affecting the dungeon tiles near to them. Maybe a monster has a 3% chance of affecting a tile 3 squares away and a 0.5% chance of affecting a tile 10 squares away.

1a. Alternatively, each monster can effect XdY tiles and these are plac+ed at some average distance from the monster location. I think playtesting would be needed to determine what distance is usable and what number of affected tiles are complete overkill.

2. When monsters move around they have an small chance of affecting the floor or the walls that they pass by. This does not really help much with warning the players, however it makes realistic sense, especialy if you allow.

2a. Monsters can erase other clues. You could imagine a gelatinous cube completely obliterating any hints of what used to be in the dungeon as it sweeps the walls clean and coats everything in a gooey substance.

[ghfame]

Random Dungeon Generation

Roger, your sorurce code is not downloadable. I would like to look at intergrating it into an OSRIC type version.
ghfame

[RogerN]

I don't have much web space through my ISP, so I probably removed those files to make room for something else. The code is included in the Cryptband source, though (see the release thread for details).

I dropped the text-mode display during development, so that might not be exactly what you want.

[Nekoninja]

Source code available?

I've posted the source code for anyone who's interested in playing with it. It's well-documented (for me at least). Just a couple of notes:

- I'm using Visual C# Express 2005. But the code should also compile in VS 2008.

- If you want to explore the dungeon properly then you might consider modifying the CreateRandomDoor function so that it only creates open doors. I haven't implemented lock-picking or searching for secret doors, so you might get stuck otherwise.

I tried to click the link but it was dead as zombie. Can you please cast resurrection spell? I am interesting to review the code and the dungeon picture look interesting.

Thank you for your time,

[wobbly]

Is this it?:

http://www.zaimoni.com/zaiband/Angband.ref/Cryptband/