Should ToME have auto-explore?

[Grey]

Hmm, so basic but slow function:

1. Go through all tiles on map. Give each one a distance from player value (straight distance, not A* distance, for ease of coding and speed of calculation).
2. Discard any that are walls, vault floors, doors or in field of view.
3. Bubble sort list by distance from player.
4. Run to square on top of list.

A slightly better function would radiate centrally from the player, and choose the first unexplored tile found, but it's a bit more of a nuisance to code, and potentially slower in some situations.

Since there's no food clock in ToME it doesn't matter if the function is inefficient in choosing destination, as long as it works.

[Mithril]

I think unidentified items should count as unexplored squares for this purpose since otherwise you may run past them.

[Grey]

The run function already stops on any item. If it's used for auto-explore (which makes sense) then this'll happen too. Shouldn't be too much of a nuisance for already known items.

[bricks]

Stopping is different from targeting, though. It can be really hard to see items on the ground in the Scintillating Caves, for example, and it's possible you would miss them both on initial exploration and while auto-exploring.

As far as opening doors go, I do think it is best that the player handles that, but then given no other options the algorithm should run to a door that leads to an unexplored area.

[Mithril]

The run function already stops on any item. If it's used for auto-explore (which makes sense) then this'll happen too. Shouldn't be too much of a nuisance for already known items.

It stops on items you run over them but I do not think that it stops if one only sees a new unidentified object. Which could cause unidentified objects being bypassed if the corridor is wide. So auto-explore could lead to the map being revealed but leaving many unidentifed items on it. Better would be to treat squares with unidentified objects as unexplored so that one runs onto such squares and then stops.

[Grey]

I think this is a fairly minor problem for the attentive gamer, and would cause a lot more work for implementing an auto-explore. I would suggest a simple system be put in first and tweaks like that be added later.

[tiger_eye]

Ultimately the implementation shouldn't be that hard, since the path-finding system with interruptions is already in place for running.

Indeed, and since I vastly improved the corridor running algorithm, I have an idea what pieces go where and how they work.

All that's needed is the "find the nearest unexplored square" function. In this respect I think the system should cheat a little to find the nearest unexplored floor square, to prevent it taking you halfway across the map because there's a corner wall tile you didn't fully reveal. Once it finds the square it just implements the run-to function as if you'd clicked on that square on the map or minimap.

I can be a bit more clever than that . I think it's important to run to an unseen tile or unwalked over object that is the fewest moves away, which would be more efficient at exploring zones like the Maze. There will also be no need to use the A* algorithm, since we'll have equivalent data available.

Better would be to treat squares with unidentified objects as unexplored so that one runs onto such squares and then stops

Yeah, I was going to treat objects that the player hasn't walked over as unexplored.

As far as opening doors go, I do think it is best that the player handles that, but then given no other options the algorithm should run to a door that leads to an unexplored area.

Alright. I wasn't sure how I should handle doors (other than don't open vaults ), so I guess I'll just let the player open the doors. I think the algorithm should also try to avoid traps and water, but if an alternate path isn't found, then still move through the trap or water (the algorithm will stop the first step into water or if you get hurt by the trap).

So, how does the following fallback behavior sound?
(1) If no unexplored tiles or objects, then move to nearest unopened door that is unexplored behind it.
(2) If no where else to explore, then move to next level or exit.

[Mithril]

Alright. I wasn't sure how I should handle doors (other than don't open vaults ), so I guess I'll just let the player open the doors. I think the algorithm should also try to avoid traps and water, but if an alternate path isn't found, then still move through the trap or water (the algorithm will stop the first step into water or if you get hurt by the trap).

So, how does the following fallback behavior sound?
(1) If no unexplored tiles or objects, then move to nearest unopened door that is unexplored behind it.
(2) If no where else to explore, then move to next level or exit.

Sounds great. Of course, on the final level there will be nowhere to go. Maybe just give a message in that case: "Everything explored!" or something similar.

[Grey]

Auto-move to exit would be handy. And if it treats unided objects the same as unexplored tiles then it'll actually not stop when in sight of them, but instead make a beeline straight for them, which is much better.

[Canderel]

In terms of traps... especially fire traps and the like... it should/could try to dig around them, cause really... I hate it to run walk 3 squares over a fire trap, then continue my run.

[Elkan]

I'd prefer not to dig around traps, they can be used to destroy enemies if you use alternative methods to bypass them or just "suck it up" and trigger them

[Canderel]

During auto-explore? Surely you believe you've killed most enemies during auto-explore? Or is the idea... Press Shift-A... Oh, and enemy... Kill it. Press Shift-A?

[Elkan]

You may be using auto explore to find enemies too, and traps can be used as a tool for dealing with enemies if you have reliable means of bypassing it digging around them is not the best solution when you may wish to use the trap later

[bricks]

Auto-explore shouldn't auto-path over traps, or if it does, it should interrupt you and tell you that you are taking damage. The feature should be as consistent with running as possible.

[Canderel]

Or traps could eventually "wear out" by stepping on them too much.