Borg?

[Gwarl]

I haven't been able to find/use a working borg. I have seen that the WPMBorg is updated reasonably often but the binaries don't seem to be giving me a borg - ctrl+z just suggests I press ?

I've noticed many variants have borg message/borg status windows as options and in the drop down window menus there's a greyed out 'screensaver'. Where can I get a working borg, for any version/variant, not that fussy which.

[Nick]

The APW borg for 3.4.1 is the most recent Vanilla borg, and can be found here.

One of the first things I did as maintainer was to remove the borg, because even early changes I was making were breaking it so horribly that I was spending more time on the borg than the game. I was not at all happy about that - I was introduced to Angband via the borg - but saw no option.

I live in hope that someone will rewrite the APW borg or write a new one, but that person is not likely to be me.

[Gwarl]

What's the history of the both? I saw the thangorodrim page with a lot of dead links, but were there any releases with a Borg included as part of the vanilla game?

[Nick]

I believe the borg first came into the official codebase about 3.1, and was there until 3.5.1.

[Siemelink]

The APW borg for 3.4.1 is the most recent Vanilla borg, and can be found here.

I live in hope that someone will rewrite the APW borg or write a new one, but that person is not likely to be me.

I've played with the thought from time to time. What kept me is the rather steep learning curve. So much code.
I always found the borg clumsy with gathering game data. It is all coded double! Once in the game and once for the borg. I know that is proper separation, but it dooms the maintainer to endless code updates to match game changes. Hackers just shrug and would read game data directly.
Another approach is that the game prepares read-only tables for the borg / display / addons to use. Maybe this would survive game updates best.

Nick,
how do you feel the separation could be handled?

Regards, Willem.

[Derakon]

A proper Borg implementation would basically exist as a new virtual terminal and input source, so it would read the output provided by the game just like a human player would and send input keystrokes just like a human player would. Well, except that it would be able to see "tile (5, 10) has a blue "Z" in it" instead of having to do computer vision.

This would require writing code to let the borg make sense of the more textual aspects of the game, like reading the inventory, understanding modifiers on equipment, etc. So it's not ideal from that perspective. The way I would solve that would be to provide a way for the core engine to expose object data in a non-text format, though. So you could ask the engine "give me the monster data for all monsters in LOS" and it would return a list of monster structs, for example. Or "give me the object data for the item in inventory slot 5". Nothing that the player couldn't determine through the normal UI, but a lot easier for a computer program to interpret, while still maintaining good separation between the engine and the borg.

[Pondlife]

The way I would solve that would be to provide a way for the core engine to expose object data in a non-text format, though. So you could ask the engine "give me the monster data for all monsters in LOS" and it would return a list of monster structs, for example. Or "give me the object data for the item in inventory slot 5". Nothing that the player couldn't determine through the normal UI, but a lot easier for a computer program to interpret, while still maintaining good separation between the engine and the borg.

That would basically be writing an Angband API, which would allow many different front-ends to play the game.

[Derakon]

That would basically be writing an Angband API, which would allow many different front-ends to play the game.

Yes, exactly. As I understand it, we have a pseudo-API currently in the virtual terminal system and ways of sending input to the game, but the "exchange format" the API uses is not really conducive to anything besides displaying game content in something like the traditional display.

[Nick]

The game is now set up so that when you play

• the interface accepts keystrokes and interprets them as commands, then pushes them onto the game's command queue;
• the game sends events to the interface when the game state changes, so the interface can display them.

There are actually some build tests which run a small game by pushing command directly, so

	cmdq_push(CMD_WALK);
	cmd_set_arg_direction(cmdq_peek(), "direction", 2);
	run_game_loop();
	cmdq_push(CMD_WALK);
	cmd_set_arg_direction(cmdq_peek(), "direction", 8);
	run_game_loop();
	cmdq_push(CMD_GO_DOWN);
	run_game_loop();

steps down, steps up and then goes down the stairs, and

	cmdq_push(CMD_WALK);
	cmd_set_arg_direction(cmdq_peek(), "direction", 2);
	run_game_loop();
	cmdq_push(CMD_DROP);
	cmd_set_arg_item(cmdq_peek(), "item", player->upkeep->inven[0]);
	cmd_set_arg_number(cmdq_peek(), "quantity", player->upkeep->inven[0]->number);
	run_game_loop();
	cmdq_push(CMD_EAT);
	cmd_set_arg_item(cmdq_peek(), "item", square_object(cave, player->py, player->px));
	run_game_loop();

steps down, drops some food on the floor and then eats it (ew). This is how the borg should drive the game, but I don't think that's really the question.

I guess really the borg should be getting all its information from the events (see game-event.h); the main issue there is that a lot of the information is wrapped up into EVENT_MAP, which tells the display how to update.

I don't know how helpful this is - I haven't thought in depth about how a borg should work.

[takkaria]

Also the map_info() function returns a struct for a given grid that tells you what's in it, some of which you can cheat from and some of which is just what the player can see:

struct grid_data {
	u32b m_idx;				/* Monster index */
	u32b f_idx;				/* Feature index */
	struct object_kind *first_kind;	/* The kind of the first item on the grid */
	struct trap *trap;		/* Trap */
	bool multiple_objects;	/* Is there more than one item there? */
	bool unseen_object;		/* Is there an unaware object there? */
	bool unseen_money;		/* Is there some unaware money there? */

	enum grid_light_level lighting; /* Light level */
	bool in_view; 			/* Can the player can currently see the grid? */
	bool is_player;
	bool hallucinate;
};

I think this plus the command queue stuff means the borg could drive the game fairly well without recourse to screen-reading.

[eschiss1]

I'm confused...

Wrong question surely?...

I don't think anyone's expecting the Borg to be included in every unstable branch of Angband. In the meanwhile, isn't Andrew P. White still updating the borg fairly regularly (over on his new website now) - resulting in recent APW borgs that can be compiled into Windows and Linux versions of recent stable versions of Angband, iirc (but not, unless one has the skills to compile the source code he provides and create a Mac Sierra binary therefrom, a Mac version too, so Mac users like me who enjoy watching the borg are watching one where both the 'band and the borg are several years out of date- the latter implying that it keeps running into and not solving the same problems, of course, ones APW seems to have solved the day after releasing that version of the borg, of course...

Not volunteering to create a new Mac version of the borg because I don't have a clue anymore how to program even my own Apple-product computer, unfortunately. Haven't for quite some time.

[Estie]

I really would love to watch a reinforced learning neural network thing ala alphago have a go at Angband.

[KarlM]

In theory someone could use Tensor Flow [1] and the Open AI Gym [2] to write a reinforcement learning borg for Angband.

Tensor Flow is Google's open source framework used to build AlphaGo. Start here [3] for some tutorials

The OpenAi Gym is the game interface used to run those Atari AI bots that beat human records [4].

[1] https://www.tensorflow.org/
[2] https://github.com/openai/gym
[3] https://medium.com/emergent-future/s...eural-networks
[4] http://www.jair.org/papers/paper3912.html