So, I added auto-explore to Angband..

[memmaker]

I am now ready to receive the wrath of the dev team :P

But, really, maybe you guys should give this a try, it's not as bad as some people make it out to be.

https://github.com/memmaker/angbandX/tree/auto_explore

For me, it made the tedious Shift-Running obsolete. And it wasn't really working on my laptop anyways, since the diagonals always gave me trouble.

Now exploring feels fun again.

DISCLAIMER: I take absolutely no responsibility for any character deaths that could result from using this code.

[backwardsEric]

There's two minor interface or documentation issues:

1. In the rogue-like keyset, 'X' is already in use for 'use an item' so you'd want to assign a different key than 'X' in the rogue-like keyset for navigating to a down staircase.
2. The new keys should be mentioned in lib/help/commands.txt, lib/help/r_comm.txt, and docs/playing.rst.

[memmaker]

As in "if you rectify this we would accept an PR"?

[backwardsEric]

As in "if you rectify this we would accept an PR"?

My, not particularly informed opinion, is this: if we need to automate exploring then we are doing something wrong in terms of level generation and improving level generation should be the first priority in that case rather than automation. This, however, is largely a community-driven project. If enough of the community wants auto-exploring or there's some evidence that auto-exploring would lead to a decent increase in the size of the community playing Angband, than auto-exploring should be adopted.

[memmaker]

Let me make the case here, then:

Technically, this piece of code merely removes the tedious process of clicking on the nearest unexplored tile with your mouse and letting the already existing pathfinder take over. All of this is already in the code.

And honestly, yes the generated levels would need a lot of refinement to not be just vast and empty. But just allowing to run through those empty hallways, as you already can do and probably everyone who has a life is doing currently makes it a lot more bearable.

And everyone can of course just not press that button and let people with a laptop enjoy the game for once.

[memmaker]

and yes, I do think that it would bring in new players: https://www.reddit.com/r/roguelikes/s/sm4H9Y9d1n or,
look at these discussions here: https://www.reddit.com/r/roguelikes/s/8LpKcejf4F
https://forums.operationsports.com/fofc/archive/index.php/t-71311-p-2.html
https://forums.tigsource.com/index.php?topic=26127.0

Generally people prefer not single stepping through large, sparsely populated random generated levels for the thousandth time.
That's the whole point of the "run" command existing.

And some other major roguelikes already feature an explore button and are much more accessible and successful because of it.
Let's see: ADOM, DCSS, Tome4. And even brogue, which arguably really has levels which don't require automatic exploration as they are densely populated with decisions. But they still added the button for UI/UX reasons. And it does improve the game so much.

Really, anyone with doubts (who is of course never using the "run" function, right? ) should give this build a try and see if it feels better or worse.

[Nick]

Well, I guess if you've already done it we can put it in (once fixed as Eric suggests). We can always take it out again if it proves offensive

[memmaker]

True, the change is very self-contained and can easily be removed if it should destroy the game.
Thanks for giving it a try: https://github.com/angband/angband/pull/5861

What really motivated me was this post, which I couldn't agree more to:

https://forums.roguetemple.com/index.php?topic=2846.msg23764#msg23764

Especially this part:
"In a game like Angband, auto-explore would be a godsend. The levels are HUGE and boring as fuck, and any food clock problems can be solved with a trip back to the surface."

Don't get me wrong, Angband is a great game, and I haven't yet descended below level 20ish to see if there is massive variation in the layout and the amount of dungeon features myself, but the let's plays tell me that's not the case.

The strength of Angband is not exploration in the sense of going one tile per keypress, if that would be the case the levels would have to be much, much smaller. It's about the strategical decisions in how you approach the dungeon. This feature is merely one more tool in your box and frankly I usually use this together with the run command, there is room for both.

[fph]

There's two minor interface or documentation issues:

1. In the rogue-like keyset, 'X' is already in use for 'use an item' so you'd want to assign a different key than 'X' in the rogue-like keyset for navigating to a down staircase.
2. The new keys should be mentioned in lib/help/commands.txt, lib/help/r_comm.txt, and docs/playing.rst.

Suggestion: what do you think about reusing `>` for this purpose, rather than adding a new key? Currently, that key does nothing unless you're already standing on a staircase. It would be possible to repurpose it to "travel to a staircase".

[Gwarl]

suggestion: tack this on to the travel interface. In poslikes you press ` and then you can select a square to travel to, or you can press ` > or ` < to travel to stairs. If vanilla already has a travel key you could do the same.

Poslikes also have ctrl+G which gathers and destroys items based on the autodestroyer which is probably the most useful aspect of DCSS's autoexplore.

It can't hurt but I always thought the lack of autoexplore was good because autoexplore would encourage people to fully explore levels, which is good in DCSS but bad in angband.

[backwardsEric]

In Vanilla, I think the closest analogue to the travel interface is in the targeting system. Press '*' to begin target selection and then press 'g' to try to move to the selected square when satisfied with the selection. One could augment the keys available there to include '<' and '>' (to move the selection to the nearest known up or down staircase, respectively, to the current selection) and 'u' (move the selection to the closest (to the current selection) known passable square that is adjacent to an unknown grid, closed door with an unknown neighbor, or rubble with an unknown neighbor). That would augment the proposed autoexplore commands: they'd require more keystrokes but you'd have a clearer sense about where you were going. Except for the handling of stuff offscreen, it would not help much when there's a mouse available: can directly click on a grid to try to move there or, within '*' , click on a grid to make it the current selection.

[Gwarl]

I don't think it's a bad thing to have it behind multiple keystokes because you can make keymaps and macros.

In composband I changed walking to accept a target so you can do 'hit nearest monster' (the other 'magic' DCSS command) with *t;5 but you can make a keymap. Very helpful for dealing with packs of wargs etc on a melee character.

[agoodman]

This breaks the borg a bit. Right now the borg frequently assUmes it is on some stairs and then watches for the "I see no xxx staircase here." message. I can work on fixing that.
That said, I like the idea of putting this behind some configuration flag so people can have it both ways. Would that be possible?

[backwardsEric]

That said, I like the idea of putting this behind some configuration flag so people can have it both ways. Would that be possible?

Yes, it would be possible, but adjusting the documentation for the player to describe what '>' and '<' do would be messy. Could have alternate versions of lib/help's commands.txt and r_comm.txt and load whatever is appropriate depending on the configuration flag, but that comes at the cost for more files in lib/help to keep up to date when there are other changes to the command keys. The descriptions of '>' and '<' in the online manual would be awkward since they would have to describe both behaviors and how which one was in effect depends on a choice made when the game was compiled.

[agoodman]

they would have to describe both behaviors and how which one was in effect depends on a choice made when the game was compiled.

I was thinking of a runtime option rather than a compile option. "Does the up and down stairs key require you to be on stairs?" or some-such or even "Enable experimental auto-explore mode" if you wanted to put everything behind a flag. Maybe the help stays a little simpler that way since you can just call out "and if auto-explorer mode is enabled ..."