You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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
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
bot_eaten
flag should be forwarded to the teams in the immediately following step.Integration with network players
API Integration with team.py
Team
methods, now that we have an explicitbot_eaten
method and don’t need to do guess work.Network format
We now have a method
prepare_bot
that takes agame_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’sgame_state
. The layout can just be added to the state in theset_initial
step and we do not need to include theis_noisy
properties for our own bots or thebot_eaten
flag for the enemy bots.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
The text was updated successfully, but these errors were encountered: