Open SirRender00 opened 2 years ago
Hello, I'd like to potentially work on this.
If you could give me a high level pointer to where the Table
abstraction fits amongst the others I can take it from there.
Cheers!
Hey @logicdotpy! Yeah that would be great if you could take a look at this! Here's my thoughts:
The main idea I think is that the Table
class can wrap around the TexasHoldEm
class and provide "thread-safe" access to the methods and attributes. For instance, we can call Table.unregister(player_id)
at any time but the Table
class will handle that smartly by first, making the next action of the player to be FOLD
and then remove the player from the game (I think it suffices to just remove their chips at the end of the round). Similarly, for Table.register
.
I put "thread-safe" in quotes here first because it's a lot like a locking mechanism but also second we should be able to pass in a time limit in the constructor. If there's a time-limit, there's probably a need for threading, but otherwise we should not be making new threads.
We can also keep a players dictionary that maps agents
to player_id
s so that the actions are taken automatically when it's a player's turn.
Let me know what you think! We can worry about integrating with the History
and the TextGUI
later and I can share more about the testing setup if you have questions.
In fact, I think we can split off the timeout option as a second phase for this. That probably makes this a bit better to work with
Let me ask actually... do you think it makes sense to have the register
/ unregister
functionality in the TexasHoldEm
class or this new Table
class? I can see the point where we have a flag in the constructor cash_game=True
which enables that functionality.
The Table
abstraction makes perfect sense when we start talking about timeouts though.
Idea is to have a cash game option where:
Idea: Have a
Table
Class in furtherance of this abstraction