Pyrel dungeon generation

[fizzix]

It just occurred to me -- you can readily detect this situation by examining the tiles on a line between * and B. If any of those tiles are already a part of the tunnel, then breaking away from the wall will not be profitable.

Sorry if you've already gotten past this problem; I haven't managed to follow most of the IRC conversations you've been having with d_m about all this.

That fails when you have two separate obstacles. (see the second choice). There you want to break away even though there's an obstacle in the line.


My current plan is to try to implement the breadth-first search as d_m described it and then use whichever works better as the main connection option and save the other as an alternate.


Mikko: I hope that stuff like this will be trivial to support in pyrel. The nice thing about the archetype + priority system is that you can add any feature you want and have a very good grasp on how often it will show up.

[RogerN]

Is there any particular reason you wouldn't just use A* for all your tunnel-planning needs? Granted, it can be slow at times, but it's guaranteed to find a solution (if one exists) and by tweaking the cost function it's really quite flexible. Once I started using it in my own variants I've never encountered a feature that it couldn't handle.

Unless, of course, you want extremely twisty, totally illogical tunnels that bend back on themselves and reenter rooms... sortof like what Angband has

[fizzix]

Is there any particular reason you wouldn't just use A* for all your tunnel-planning needs? Granted, it can be slow at times, but it's guaranteed to find a solution (if one exists) and by tweaking the cost function it's really quite flexible. Once I started using it in my own variants I've never encountered a feature that it couldn't handle.

Unless, of course, you want extremely twisty, totally illogical tunnels that bend back on themselves and reenter rooms... sortof like what Angband has

That seems like it might work, as it's an improved version of what I was trying to code. We can make twistiness by creating a noise function on the granite floors with various granite walls taking higher costs to traverse them. It won't create the illogical twistiness that we currently have, but some of those (especially paths that leave and return) are ornaments that can be added on later.

thanks.

[Patashu]

That seems like it might work, as it's an improved version of what I was trying to code. We can make twistiness by creating a noise function on the granite floors with various granite walls taking higher costs to traverse them. It won't create the illogical twistiness that we currently have,

It could (I think) if the kind of noise used is very patchy rather than randomly per tile. I don't know what kind of noise function would make that though, maybe picking seeds of +1/-1 cost and growing them outward randomly for some amount.

[fizzix]

It could (I think) if the kind of noise used is very patchy rather than randomly per tile. I don't know what kind of noise function would make that though, maybe picking seeds of +1/-1 cost and growing them outward randomly for some amount.

d_m suggested perlin noise. And that's probably what I'll go with. It seems to produce exactly the behavior type we want.

[Patashu]

Perlin noise looks great!