Pyrel dungeon generation

[fizzix]

I've been thinking a lot on how to best write the dungeon generation for pyrel. In keeping with the spirit, the goal would be to improve on how the generation algorithm handles certain things so that the client (i.e. programmer) has more flexibility in determining the dungeon style.

My basic ideas is that each dungeon feature should have an associated power rating and an associated rarity (or strangeness) rating. A greater vault would have both a high power and rarity rating, while a bizarre empty room might have a large rarity rating but a low power. Conversely, a OoD monster or a unique could have a high power but a low rarity. Bog-standard features like normal rooms, corridors and doors have 0 for both.

At the beginning of each level, the RNG rolls for both rarity and power and those rolls determine the features. This gives the client the capability of tweaking the dungeon in fundamental ways with very simple changes. I envision the power rating to be very highly tied to dungeon levels and the rarity rating to have a much weaker dependence. I could also envision the capability of gradually reducing the power of a level each time it's visited to encourage deeper exploration, but that's an entirely different conversation. The point is that the capability would be there.

The basic algorithm goes like this.

1. Choose dungeon template (see below)
2. Roll for power/rarity
3. Place large features (GVs, labyrinths, caverns) if justified by rolls.
4. Place smaller features (MVs, LVs, pits nests) if justified by rolls.
5. Fill up remaining allotment for strangeness with abnormal rooms.
6. Fill up remaining allotment for power with OoD monsters and items.
7. Make remaining normal rooms
8. Make corridors for connection, magma and quartz streamers.
9. Place random monsters and items

For 1. currently the dungeon templates are town, normal, cavern and labyrinth. I plan to subsume caverns and labyrinths as large scale sub-features of a level as opposed to their own type. However, this step is useful for differentiating the town from the dungeon in V and for differentiating different types of dungeon maps (overland, mountain, different dungeons) in variants. Since the rarity rolls could conceivably depend on dungeon templates, I move the rolls to the second step.

2 has been explained already.

One of the current drawbacks of dungeon generation is that features are often limited by whether or not they fit. In step 3 we place the largest features as the first features in the dungeon. This way we can ensure that you get a GV if one is called for. The main advantage is not to make GVs more common, but to give the client the capability of setting their frequency in a very transparent manner. I'm envisioning High rarity, low power levels to get a cavern. High rarity, medium power levels to get a labyrinth and High rarity, high power levels to get a GV.

For 4, I lumped a lot of thing together but you can imagine further stratification. You can first check for MVs, then LVs, then pits and nests if you want. I'm not sure this stratification is necessary right now, but it would be useful if you have some features that are much larger than others.

5 is how you get somewhat interesting dungeons with low power levels. This way the first 10 levels can still have interesting features instead of the current boring situation. These would be the rooms in room_template.txt as well as the moated rooms, the cross rooms, the circle rooms, the double rooms, the pillared rooms and all the other non-standard rooms.

6 is how you satisfy a high power low rarity dungeon. Basically this looks like a normal dungeon except it's chock full of dangerous monsters and awesome loot.

7,8,9 finish out dungeon generation similar to what's done in V.

I was going to go into more details about how to pick features based on the rolls, but my lunch break is over. Maybe later tonight.

[Patashu]

If you want a case study, Dungeon Crawl: Stone Soup has a LUA interface and plugins for (most? all?) of its dungeon building styles, and it has its own file format for 'vaults', special rooms that have their own defined layout (which can have elements of randomness, subvaults, randomized subvaults, arbitrary embedded LUA, etc)

[ekolis]

Heh, Crawl actually has Lua? I must have missed that - wasn't Lua actually removed from Angband around 3.1.0 or so?

[Patashu]

Originally Posted by ekolis

Heh, Crawl actually has Lua? I must have missed that - wasn't Lua actually removed from Angband around 3.1.0 or so?

Crawl has LUA for a lot of things - you can put LUA in your configuration file to define macros, scripts and so on. There is at least one bot written entirely in client-side LUA.

[Antoine]

I must be confused - I thought pyrel was intended to be a port of Angband - do I have that wrong??? (Could I be thinking of pyAngband?)

A.

[Derakon]

Pyrel is a port of Angband (or will be when it's done!). I believe Patashu was simply suggesting that we check out Crawl for inspiration as to implementation mechanisms, if not content.

(Of course, how much Pyrel will resemble Angband when it actually starts being playable is an open question. Devs like to meddle.)

[fizzix]

Here are what I envision to be the changes to the "final product" of dungeon generation.

1) Labyrinths and Caverns will become features on a level instead of their own level. This was actually a design goal for a while, so it's well in the intended spirit.

2) Angband splits up the dungeon into smaller sub-blocks and then creates rooms contained entirely in those blocks. Vaults can span multiple blocks. I think the original idea was to prevent rooms from spanning across a window boundary (this is prior to window resizing and center on player). I'm not sure there's another good reason to split the dungeon this way anymore, so I have a feeling rooms will be placed more or less randomly in the pyrel generation script.

3) Frequencies of various features may change. This is probably for the better, since the current allotment is far from ideal (every level in the 90s is almost guaranteed a demon, ainu, undead or if you're lucky dragon pit).

I have lots of other ideas for improvement including making pits variably sized, making sections immune to item/feature detection and mapping, and creating sections where certain monster types are prevalent. But I'm not even sure I'll be able to get generation working given the poor state of my python abilities. So these extra things may not happen.

[Antoine]

Originally Posted by Derakon

How much Pyrel will resemble Angband when it actually starts being playable is an open question. Devs like to meddle.

So they do. Then, as I always anticipated, this will be a variant in another programming language, rather than a port.

A.

[Magnate]

Originally Posted by Antoine

So they do. Then, as I always anticipated, this will be a variant in another programming language, rather than a port.

No, it'll be a 100% faithful port of Vanilla Angband, because YOU, along with Timo and and everybody else who likes to carp from the sidelines, will step up and contribute to make sure it is.

And if you don't, you'll stop bitching about the difference between a faithful port and a variant rewrite, won't you?

[Antoine]

Originally Posted by Magnate

No, it'll be a 100% faithful port of Vanilla Angband, because YOU, along with Timo and and everybody else who likes to carp from the sidelines, will step up and contribute to make sure it is.

And if you don't, you'll stop bitching about the difference between a faithful port and a variant rewrite, won't you?

ha! surely you jest sir. the more people were involved, the less likely it would be to be a faithful port.

let me be the first to welcome this fine new variant!

a.