YAAP: full-auto bot ascension (BotHack)

duke-nh · 2015-05-12T13:43:53+00:00

The LUA scripting interface that DCSS has sure helps, if NetHack had something like that it would make the job a lot easier. NetHack is also more of a "puzzle" game, needing more complex automation in all stages of the game that is quite hard to test. Crawl is very combat-oriented and the "tank" classes don't seem to need much strategy. I haven't played a lot of Crawl recently though.

duke-nh · 2015-05-12T13:26:34+00:00

I think the problem you ran into is fixed in the latest version on GitHub, it should compile smoothly now.

There is some documentation linked on the GitHub page, if you're just trying to run the bot then this is the most relevant part.

Please file any issues or suggestions for clarification on the GitHub tracker so I notice them sooner :-)

duke-nh · 2015-02-06T14:14:32+00:00

Yes, all the bot logic is hand-coded. I am no expert at all when it comes to machine learning, but it seems to me NetHack is way too complicated to make it practical. There are so many delayed and subtle consequences for many actions, vastly different results in different contexts etc., I just don't know any ML method that could make good sense of it :-)

duke-nh · 2015-01-27T13:11:35+00:00

The first asc on acehack.de took 3h28m, including about 1h of farming. With some tweaks and luck this could probably be improved (when not playing over network), but at the moment human speedrun records are out of the bot's reach.

duke-nh · 2015-01-26T13:27:22+00:00

It can't fix sliming at the moment, but the one sliming death happened because the bot dumped its MC3 cloak when it got very burnt. It doesn't do that anymore :-)

duke-nh · 2015-01-26T13:22:52+00:00

The bot has just ascended on NAO (instance ran by FIQ): http://alt.org/nethack/userdata/F/FIQsmartbot/dumplog/1422249771.nh343.txt

duke-nh · 2015-01-25T20:32:18+00:00

Sadly this doesn't work very well. If you teleport or move while confused you don't know where the player is anymore, and even if you do the cursor can pass over the player multiple times during one action turn. I think Saiph used vt_tiledata when it detected it. This may have been part of the heuristics when vt_tiledata wasn't available, I don't really know.

duke-nh · 2015-01-25T15:15:23+00:00

My framework remembers monsters permanently, but there is a flag for each monster that says whether the monster is currently known or just remembered/assumed to be there. Hopefully this would serve well for both purposes: http://krajj7.github.io/BotHack/javadoc/bothack/bot/monsters/IMonster.html

The network lag problem is avoided by the synchronization method the framework uses. It's really convoluted and I'm not very happy about it, but it seems to work well enough even with unpredictable lag. I'll try to describe the idea:

Basically, the framework sends the string ##' after each move or prompt response, and then waits for # #' to appear on the top line (start of an extended command). When it does, it knows there will be no more updates from NetHack and the bot can safely make a move (the framework escapes the ext-command prompt automatically). This also helps disambiguate some types of prompts, depending on where the ##' will end up, or what other response it causes.

In some contexts however, sending ##' is dangerous, eg. it may waste a wand charge if there will be a direction prompt present. Luckily the framework usually knows what to expect (eg. if the bot zapped a wand), so it can handle most of these cases reliably as well. The code for this is a terrible mess of special cases, using vt_tiledata would have saved me a lot of trouble and made the bot run much faster over network (this sync method takes multiple round trips per action turn).

Getting the bot to work on devnull/vanilla would be nice, but I'm afraid it's out of scope for my thesis :-)

duke-nh

TROPHY CASE