search

ichabod801 / t_games

A collection of command-line interface games written in Python.
GNU General Public License v3.0
20 stars 4 forks source link

Redo Prisoner's Dilemma Bots #568

Closed ichabod801 closed 4 years ago

ichabod801 commented 4 years ago

I'm seeing a common problem: bots with strategies are not tracking responses per bot, but overall. Then if they are dealing with multiple bots, the strategies leak across bot, and foe A is getting punished for the actions of foe B.

I want to redo the bots from the base up. Have a data attribute, keyed by foe name, with a dictionary as a value. That sub-dictionary automatically tracks their moves and your moves. And before doing the get_move method, it put's the current foe's data into foe_data. Now the bot doesn't need to know who the foe is, they just have the data ready. Furthermore, since the data is a mutable, they can easily store their own tracking data to foe_data, and have it automatically stored correctly for each opponent.

ichabod801 commented 4 years ago

Okay, the problem was way more widespread than I thought. This was a good idea.

ichabod801 commented 4 years ago

The bots are recoded, but doing so made me realize that PrisonerMethodBot is stupid. All of it's children could easily just override get_move, and are rather confusing under the PrisonerMethodBot paradigm. What might be better is just PrisonerBot with some helper methods like get_last_pair and get_last_foe, which can handle first turn issues.

Or maybe something like a PrisonerQueueBot, where you queue moves, it makes a move if any are queued, otherwise makes a default move.

ichabod801 commented 4 years ago

The key with the general bot designs is: what make it easy to code more bots.

ichabod801 commented 4 years ago

Whoops, Pavlov needs work.

ichabod801 commented 4 years ago

I need to update the documentation based on the last commit, as well as PrisonersDilemma.bot_classes.

ichabod801 commented 4 years ago

Did a full test of all of the bots. They all worked fine.