arielhorwitz / botroyale Goto Github PK

we should think about making a ci/cd script that generates the docs when we push to master or dev and uploads them to the GitHub wiki or a hosted docs in GitHub

When a bot is called to action, it should receive some sort of game state data. Currently there are only random bots that don't require any knowledge of the game state.

It is probably preferable that the bots receive some copy and not direct access to the game data (numpy arrays in particular).

BaseBotAPI

Thinking about it, perhaps the Logic maintainer @MoralSiani can make a BaseBotAPI class similar to BaseLogicAPI. That way they can more easily add new features available to the bots without requiring simultaneous updates in both logic and bots packages?

As we stabilize the core of the codebase, we can begin to think of adding new in-game mechanics: new actions, or new map features (to add to walls, pits, and the ring of death).

This would be a change in logic.state.State and api.actions.

Need Hex type check,
Unable to identify bot tile type for actions, can't convert Hex to Hex or check type instance for Hex.
either is_hex() function or allow Hex init with hex object.

We should choose a version of python that is officially supported/required by the project. I suggest python 3.10. If we can get a consensus here that should be enough.

Missing visual indication for actions (move and push). Should be accessible to the logic via the logic-to-gui event queue.

Need to standardize grid, preferably (rows, columns) and (0,0) on top left.
ty

need an additional layer of sprites for each tile, behind player but Infront of hex,
this will allow to show items, traps and unique tiles in the gui,
they will follow the convetion of white images that allow for changing the color

The release candidate branch is available for testing and review.

Please feel free to check it out and give feedback here.

The bots have no valid way of checking if a action will work and further more they don't have any way of knowing what the result of there action would be

I'm proposing we make a check_valid_action(action: Action): -> bool and a simulate_action(action: Action): -> world_info

this will allow us to check and see outcomes of moves also will allow us to see if a move will win the game or not
(Would like the world_info to have a game_over_flag or something)

if a bot returns an idle action this is thrown

File "C:\coding\GitHub\Bot-Royale\gui\gui.py", line 88, in mainloop_hook
     self.next_turn()
   File "C:\coding\GitHub\Bot-Royale\logic\battle.py", line 96, in _check_legal_action
     raise TypeError(f'Unknown action: {action}')
 TypeError: Unknown action: <api.actions.Idle object at 0x000002A618E50DF0>

Make the bot a bit smaller, so it seems they are standing on the tile and not being the tile itself.
ty

There are currently several hurdles to trying to run a custom script in the project. In particular if a script is not in the root dir of the project, it will be difficult to access and import other parts of the project.

A folder should be made designed for custom scripts which should be recognizable from main.py, but also the contents of which should be ignored by .gitignore. This will require the user to specify the name of the custom script to run in settings or in an argument parser so that an import can be made.

Consider the following: https://www.redblobgames.com/grids/hexagons/

The Hexagon class from the hexagon utility is missing a rotation function (60 degree rotation), as well as a range function (find all tiles within X distance).

Hopefully the new docs and guides will help new bot developers, as we really need more bots that know how to play!

The word id is a builtin in python and can be confusing. I believe that agreeing to always call it uid (Unit ID) will be clearer.

Will probably need aliasing and a deprecation warning.

GUI should show what bot class each unit is - by using a color for each bot class.

It's possible for the bots to determine their own color, or for the GUI to determine the color for the bots. I personally lean toward bots determining their own color - requiring a definition in BaseBot. The GUI can put some limitations on color choice to avoid confusion with other map elements in the GUI.

The battle calls bot.poll_action() and at that point excecution is passed to the bot code. Unhandled exceptions in this execution will crash the program. I suggest we try..except the call to catch any exception and log the entire traceback.

If an exception is caught, I suggest the battle by default should use a (yet to be written) method in State State.kill_unit which will... Kill the unit.

A State object should be serializable; mostly for saving/loading replays from disk.

Ideally, it not only mimics State.copy but also shares with it a list of attributes that are required to recreate an identical state. This list of attributes would possibly also be used by a __hash__ method.

Bots should be identified by ID and name in the GUI state string. This can be accessed with the Bot.NAME attribute.

Unit #1 -> 1. RandomBot
Unit #2 -> 2. BaseBot

As the project begins to stabilize, it is worth reviewing and documenting (possibly also refactoring) the modules used by bot developers.

Some proper guides would also be helpful:

• "Step by step: write a simple bot"
• "Custom battles: how to run battles without the GUI"