The Tavern

This is not a big thing, but escape hatches might as well have something showing you where they end up. As it is today, the game remembers hatch destinations for you anyway, and you can see them when you use Ctrl+X. The biggest downside is clutter - another special tile or two per level - but there's tons of clutter in crawl anyway. What I imagine, approximately, for spring- and trap-door destination tiles:

Can't you see the destination with X and ] or [ ?

Exactly, so there should be no issue in taking the game's invisible marking (through X and ] or [) and making it visible.

The destination might be any kind of feature, so a large graphic like landing_pad might be too likely to cover up something important. An icon-like designator like escape_flap could work though. Not sure how one would show it in console: perhaps a different background colour, since we don't use those for very many things?

There's a number of features of which there can be only one per tile: stairs, traps, shafts, portals, shops, water, lava, etc. I think The destination is one of them. If it is not (wtf devs?) then it can be easily forced to be one. Cover up something important - what? An object on the ground? Most items on the ground get obscured anyway, usually by monsters or other items.

In console it can be a staircase with an uninviting color (e.g. a purple "<" for a landing pad)

Pollen_Golem wrote:There's a number of features of which there can be only one per tile: stairs, traps, shafts, portals, shops, water, lava, etc. I think The destination is one of them. If it is not (wtf devs?) then it can be easily forced to be one. Cover up something important - what? An object on the ground? Most items on the ground get obscured anyway, usually by monsters or other items.

In console it can be a staircase with an uninviting color (e.g. a purple "<" for a landing pad)

Misthanked. It shouldn't be on < since every other < is something you can press < on.

Does seeing where a hatch leads, while on the target floor (not the hatch floor) ever affect a decision? If I care about where a hatch goes I'm on the floor with the hatch and will use X ] if possible. Seems like a COME FROM statement.

Well, suppose you peek down a set of stairs and see a landing pad in a corner with no monsters in sight. You go back up and continue clearing the level. If you see a trapdoor, you'll know it likely goes to a safe place.

I think most players avoid escape hatches while they're clearing levels, and don't bother triggering them afterwards, so the destination of an escape hatch typically remains unknown.

rchandra wrote:It shouldn't be on < since every other < is something you can press < on.

You might as well say that trapdoors shouldn't be > since all the other > let you come back up after you press >. :roll:

Pollen_Golem wrote:I think most players avoid escape hatches while they're clearing levels, and don't bother triggering them afterwards, so the destination of an escape hatch typically remains unknown.

I trigger many of them because I do believe Auto-Travel uses them if the distance is shorter, but only if they've been pre-explored. This is why I try to "clear" every "convenient" up/down on each level. This should also help if auto-traveling on the Orb Run.

neil wrote:The destination might be any kind of feature, so a large graphic like landing_pad might be too likely to cover up something important. An icon-like designator like escape_flap could work though. Not sure how one would show it in console: perhaps a different background colour, since we don't use those for very many things?

If and when we add this, I don't think it's critical to be able to show it in console; there are already other interface conveniences (e.g. easy display of monster statuses & weapons) that console doesn't have access to. As mentioned above, it's already possible for console players to view this through X]<[ and X[>], and that won't change.

Of course, I'm biased.

Pollen_Golem wrote:There's a number of features of which there can be only one per tile: stairs, traps, shafts, portals, shops, water, lava, etc. I think The destination is one of them. If it is not (wtf devs?) then it can be easily forced to be one.

It's not at present, and it can't easily be.

We generate levels individually, not en-masse, so when creating a given level, we may not know the contents/layout of adjacent levels. (We generally know what's going on in the level above & don't know what's going on in the level below, but that's not always the case; it's possible to use shafts to 'skip' multiple levels, meaning that when ascending, the level generator knows the contents of the level below but not the level above). Given this, we can't pre-place 'landing pad' features, since we don't know how many hatches will be on the adjacent levels - if any!

You could suggest 'reserving' a fixed number of landing spots, but the main problem there is that the level generator uses escape hatches as a figurative escape hatch for the design. They're placed in otherwise-inaccessible areas, e.g. islands surrounded by deep water, diggable rock, etc, where the player would otherwise be trapped. You'd need to reserve a very significant number of escape hatches (conservatively, half a dozen per level, each way), which seems like it'd make a large and undesirable impact on gameplay. Plus, you'd still end up having to reject some levels for requiring 'too many' hatches... it's a huge can of worms for very little benefit.

e: and retroactively editing the level after later levels are generated, or after you actually use a hatch, is an even worse idea...

PleasingFungus wrote:
Pollen_Golem wrote:There's a number of features of which there can be only one per tile: stairs, traps, shafts, portals, shops, water, lava, etc. I think The destination is one of them. If it is not (wtf devs?) then it can be easily forced to be one.

It's not at present, and it can't easily be.

*good stuff*

You can't easily force a destination to land on a non-stairs, non-shop, non-trap location? As in 99% of the game's terrain?
You can make stairs slide for Xom's sake!
Come on guys, you've already figured out a way to make escape hatches NOT throw characters into lava and NOT go to sealed-off rooms.

PleasingFungus wrote:e: and retroactively editing the level after ... after you actually use a hatch, is an even worse idea...

OK, why? There are already things you don't notice until you go through them, or come nearby, i.e. some traps. They just "pop" into existence. So are traps also an even worse idea :?:

PleasingFungus wrote:end up having to reject some levels

So is that something currently practiced in level generation? If so, how often does a generated level get rejected?

The Tavern

Escape hatches having destinations marked and visible

Escape hatches having destinations marked and visible

Re: Escape hatches having destinations marked and visible

Re: Escape hatches having destinations marked and visible

Re: Escape hatches having destinations marked and visible

Re: Escape hatches having destinations marked and visible

Re: Escape hatches having destinations marked and visible

Re: Escape hatches having destinations marked and visible

Re: Escape hatches having destinations marked and visible

Re: Escape hatches having destinations marked and visible

Re: Escape hatches having destinations marked and visible