We should have a bot that demonstrates how one can switch roles mid-game while still keeping the state dict useful. Fixed roles are good for a quick demo but are obviously nothing you’d want to have in a proper game.
This does complicate things however and has been a problem with the students’ understanding of how to use the state properly: The one and one bot has two sub-dicts that are exclusive to each role (and bot) but why shouldn’t the attacking mode be able to add state that the defending mode can then read?
This is a problem that the students are going to face on the second day when they try to merge their strategies, with a solution being that they’ll have to pass the whole dict instead of the sub-dicts to the respective strategy functions.
This means they’ll either have to merge the sub-dicts and face the problem of unrelated attributes having the same name in both strategies, or they keep the sub-dicts but then have to rewrite all dict access from state['my_attr'] to state['attacker']['my_attr'], which defeats the purpose of having easily pluggable state.
Once we have decided on how a more complex bot should work, we should revise all previous demos so that they work the same way (or at least don’t contradict the more complex behaviour).
Debilski
commented
3 years ago
We should have a bot that demonstrates how one can switch roles mid-game while still keeping the state dict useful. Fixed roles are good for a quick demo but are obviously nothing you’d want to have in a proper game.
This does complicate things however and has been a problem with the students’ understanding of how to use the state properly: The one and one bot has two sub-dicts that are exclusive to each role (and bot) but why shouldn’t the attacking mode be able to add state that the defending mode can then read?
This is a problem that the students are going to face on the second day when they try to merge their strategies, with a solution being that they’ll have to pass the whole dict instead of the sub-dicts to the respective strategy functions. This means they’ll either have to merge the sub-dicts and face the problem of unrelated attributes having the same name in both strategies, or they keep the sub-dicts but then have to rewrite all dict access from
state['my_attr']tostate['attacker']['my_attr'], which defeats the purpose of having easily pluggable state.Once we have decided on how a more complex bot should work, we should revise all previous demos so that they work the same way (or at least don’t contradict the more complex behaviour).