Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Planning for Core-2.0 #570

Open
12 of 16 tasks
Debilski opened this issue Mar 10, 2019 · 0 comments
Open
12 of 16 tasks

[Discussion] Planning for Core-2.0 #570

Debilski opened this issue Mar 10, 2019 · 0 comments

Comments

@Debilski
Copy link
Member

Debilski commented Mar 10, 2019

Pelita Core-2.0 TODO list (preliminary)

Specify call structure / possible call situations

  • Define the different situations how a game will be set up. Game-internal and from a user perspective. Add checks to the functions that they can only be called with a game_state in the correct state to prevent using them in the wrong order.

  • Rename the functions in game.py such that they are less confusing.

  • Rename the functions in the internal API (set_initial/get_move)

Assign exceptions and error dicts

  • Assign the proper exceptions to FatalException and NonFatalExcpetion and use them properly inside the move functions.

Check that game logic is correct

  • Add (re-import) more tests for different layout/bot situations.

  • Add mini test framework to test specific situations without having to handle the setup of layout/run_game functions manually. Ideally, one would specify an input layout, a list of moves for the bot(s) (and whose turn it is) and then a list of properties (score, bot positions) that one wants to check after the game has been run. This makes it easy to add more tests.

Add further attributes

  • Add flag that tells us that a bot has been killed. This bot_eaten flag should be forwarded to the teams in the immediately following step.

Integration with network players

  • Add integration for network players. Move the server setup to the new API and properly port the proxy players.

API Integration with team.py

  • Simplify the code in the Team methods, now that we have an explicit bot_eaten method and don’t need to do guess work.

Network format

We now have a method prepare_bot that takes a game_state and transforms it into a new dict with noise applied and keys deleted that is then handed over to the team. We can therefore try to get rid of redundant and superfluous information in the team’s game_state. The layout can just be added to the state in the set_initial step and we do not need to include the is_noisy properties for our own bots or the bot_eaten flag for the enemy bots.

  • Restructure network format.

API changes in team.py

Currently, we use the same Bot class for our own bots and for the enemy bots, even though, not all of the properties make sense on all bots.

Ie. for our own bots, we may care about legal_pos, whereas it does not make much sense to call the same method on a noisy enemy. Similarly, we don’t have information on whether an enemy has been killed and do not include this information in the network data.
Likewise, the is_noisy property is not really useful on our own bots.

A solution could be to have two separate classes for the Bots (probably inheriting from a common GenericBot to avoid duplication).

  • Investigate, if this is useful or if we should stick to a one class API (and just raise exceptions when the wrong argument is accessed).

  • Re-use the layout loading code for the user-side layouts (with EE for enemies).

  • Bonus: Move old AbstractPlayer API to new package and try to make it work against the new style API.

Integration with the viewers

Network format

Similarly to the network format for the teams, the viewers will have their own prepare_for_viewer method, that gets rid of the unnecessary (and unserialisable) detail for the viewers.

  • Add prepare_for_viewer function, that provides information for the viewer.

  • Add noised_positions list to viewer, which allows us to add a debug mode in Tk and show where the enemys appear to a bot.

Cleanup

  • Clean up old, unneeded files and classes (test should be converted before deletion).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant