Making a "good" autoexplore

[Odds]

Spurred on by autoexplore taking me in a straight line across an entire level directly away from safety, I'm toying with the idea of trying to write an improved autoexplore algorithm (mostly for my own amusement). One key step would be working out what on earth that means. Here are things that make me happy to explore a new tile:

- I am near stairs (easy escape).
- I am near walls (I won't be surrounded).
- I am far from the tile I am revealing (the nasty unique in it won't catch me).
- I am near the tile I am moving to (probably important to prevent over complicated rules starving me to death).

What else is good in a tile or player position when exploring?

[Gerad]

I'd value efficient exploration highly -- e.g., explore the nooks that look like dead-ends close to you first before moving off to explore another large segment of the level. This is admittedly more of a turncount/boredom fix than a "help me not die" one.

[chequers]

Minimise the number of unexplored squares revealed with each step for added safety.

[Sprucery]

In the meantime, setting explore_wall_bias to something else than 0 should make you explore squares close to walls first. I have it at 20 but I have no idea what would be the 'optimal' value.

[duvessa]

big autoexplore improvement: get rid of plants and shallow water

[Arrhythmia]

nothing because no matter how autoexplore kills me i'd just go "oh well I would clearly have explored left instead of right saving me from this horrible death; thanks a lot for ruining everything forever [dev who committed most recent change]"

[lethediver]

Been wondering this for a while. An option to always auto explore the nearest unexplored tile from a known stair would be swell...

[Odds]

Been wondering this for a while. An option to always auto explore the nearest unexplored tile from a known stair would be swell...

This actually looks... quite easy (unlike all the other options I've thought of). Famous last words before my first attempt to change the codebase, but I'll give it a go.

[Leszczynek]

It will also quite easily bump up the turn count by some crazy amount as "the next square closest to the known stairs" will be likely in the opposite direction to the one just revealed.

Anyway, if you really feel like doing this, you should probably do two or more different settings, one of which would focus on safety and the other on turn-wise efficiency, and let player switch between them at any given time. I think it should be possible with the current available clua functions.

[Odds]

It will also quite easily bump up the turn count by some crazy amount as "the next square closest to the known stairs" will be likely in the opposite direction to the one just revealed.

Anyway, if you really feel like doing this, you should probably do two or more different settings, one of which would focus on safety and the other on turn-wise efficiency, and let player switch between them at any given time. I think it should be possible with the current available clua functions.

Sure. I'm not expecting this tweak to actually give a competitive explore algorithm! But it's a nice place to start.

[Odds]

Been wondering this for a while. An option to always auto explore the nearest unexplored tile from a known stair would be swell...

This actually looks... quite easy (unlike all the other options I've thought of). Famous last words before my first attempt to change the codebase, but I'll give it a go.

I ended up writing (in a hacky kind of way) a slightly more subtle version of this; an option to bias exploration to like squares near stairs. The score of a square is [distance from you] + x*[distance from the nearest upstair to you].

For x=infinity, this takes forever; exploration will typically go down two or more branches one square at a time, switching between them.

For x=2, this explores D:1 and D:2 in reasonable time (800-1000 turns), and felt like it was having the desired effect - the explored area felt safer.

[lethediver]

Give me the lua implementation to add to my rc file pl0x

[Odds]

I'd value efficient exploration highly -- e.g., explore the nooks that look like dead-ends close to you first before moving off to explore another large segment of the level. This is admittedly more of a turncount/boredom fix than a "help me not die" one.

Are you aware of the explore_wall_bias option? No idea if it works, but setting explore_wall_bias to something greater than 0 in your rc file is supposed to explore nooks before going off elsewhere.

Give me the lua implementation to add to my rc file pl0x

Ha. This would be... tough. However, I am asking in more appropriate channels than CYC whether an option like this might get merged.

[Implojin]

I'd value efficient exploration highly -- e.g., explore the nooks that look like dead-ends close to you first before moving off to explore another large segment of the level. This is admittedly more of a turncount/boredom fix than a "help me not die" one.

Turncount fixes translate directly into "help me not die" fixes in Crawl's current ruleset:

Monster respawn rate, monster OOD respawn chance (at depths less than 13), and piety decay (for most gods), all work directly off of turncount. God gifting, as a function of piety, also tends to happen relatively more often with faster turncount progression due to higher sustained piety levels (this is *despite* gift timeouts decrementing at a fixed turncount rate). [There are other indirect reasons why lower turncount helps character survival, but I'm mentioning some of the most commonly applicable here for brevity.]

A more turncount-efficient autoexplore function would mean that game balance for players who autoexplore (most players) would come closer to that of players who manually explore (patient veterans playing for streaks and turncount speedrunners), and would be a Good Thing for DCSS in general.

[An autoexplore function that manages to do the above, while also avoiding suicidal positioning decisions wrt LOS breaks and staircases, would be a vast improvement indeed over the current implementation.]

[ZipZipskins]

Autoexplore is the typical kind of crutch I'd expect lazy handout-generation millennials to rely on

[Odds]

I'd value efficient exploration highly -- e.g., explore the nooks that look like dead-ends close to you first before moving off to explore another large segment of the level. This is admittedly more of a turncount/boredom fix than a "help me not die" one.

Turncount fixes translate directly into "help me not die" fixes in Crawl's current ruleset:

Monster respawn rate, monster OOD respawn chance (at depths less than 13), and piety decay (for most gods), all work directly off of turncount. God gifting, as a function of piety, also tends to happen relatively more often with faster turncount progression due to higher sustained piety levels (this is *despite* gift timeouts decrementing at a fixed turncount rate). [There are other indirect reasons why lower turncount helps character survival, but I'm mentioning some of the most commonly applicable here for brevity.]

A more turncount-efficient autoexplore function would mean that game balance for players who autoexplore (most players) would come closer to that of players who manually explore (patient veterans playing for streaks and turncount speedrunners), and would be a Good Thing for DCSS in general.

[An autoexplore function that manages to do the above, while also avoiding suicidal positioning decisions wrt LOS breaks and staircases, would be a vast improvement indeed over the current implementation.]

Interesting. While this is true, I'm not sure how big an effect it is. When I explore manually for safety (which is rare; usually on a few levels only, when streaking) I'm not doing it for turncount - I'm doing it so that the level is always as safe as possible.

So my instinct is that safe exploring beats turncount. So a change which increases turns by a little, and increases exploration safety, is a good thing.

[Odds]

Minimise the number of unexplored squares revealed with each step for added safety.

I tried this one out too. It's kind of weird. In large spaces, you make lots of little moves around the known area to reveal one square at a time. Might work better with a less harsh penalty than I'm using atm.