Angband Forums

Angband Forums (http://angband.oook.cz/forum/index.php)
-   Vanilla (http://angband.oook.cz/forum/forumdisplay.php?f=3)
-   -   Borg? (http://angband.oook.cz/forum/showthread.php?t=8332)

Gwarl April 3, 2017 21:47

Borg?
 
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 April 3, 2017 22:04

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 April 4, 2017 01:39

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 April 4, 2017 01:56

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

Siemelink April 4, 2017 18:13

Quote:

Originally Posted by Nick (Post 119625)
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 April 4, 2017 19:11

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 April 4, 2017 20:51

Quote:

Originally Posted by Derakon (Post 119651)
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 April 4, 2017 21:18

Quote:

Originally Posted by Pondlife (Post 119657)
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 April 4, 2017 22:32

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
Code:

        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
Code:

        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 April 6, 2017 00:05

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:

Code:

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.


All times are GMT +1. The time now is 15:26.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.