Poker Simulator Design Log
| Line 22: | Line 22: | ||
* Players of HoldEm poker only get 2 cards of their own, which they have to keep. | * Players of HoldEm poker only get 2 cards of their own, which they have to keep. | ||
* HoldEm poker has community cards which are dealt face up onto the table (5 in total), and players have to make the best poker hand possible out of any 5 card combination of the community cards and their own cards. Players can use 0 - 2 of their own cards in making a hand, but the combination that gives the highest ranked hand has to be used. | * HoldEm poker has community cards which are dealt face up onto the table (5 in total), and players have to make the best poker hand possible out of any 5 card combination of the community cards and their own cards. Players can use 0 - 2 of their own cards in making a hand, but the combination that gives the highest ranked hand has to be used. | ||
| − | * I thought about how the "suit" attribute of a Card might break the [[Beware value switches]] heuristic, in that when checking for a flush hand, the suit value will be used in case analysis. However I thought it was a bit extreme to decompose Card into an inheritance hierarchy of different Suits, | + | * I thought about how the "suit" attribute of a Card might break the [[Beware value switches]] heuristic, in that when checking for a flush hand, the suit value will be used in case analysis. However I thought it was a bit extreme to decompose Card into an inheritance hierarchy of different Suits, because there will only ever be 4 suits to test. (ie no further extension is possible) |
* The CardAnalyser class is not implemented in the design yet, but it is a class that is necessary so I have included it in the diagram. | * The CardAnalyser class is not implemented in the design yet, but it is a class that is necessary so I have included it in the diagram. | ||
* I'm not sure if the DrawTable and HoldEmPlayer classes are [[Eliminate irrelevant classes|irrelevant classes]] yet. | * I'm not sure if the DrawTable and HoldEmPlayer classes are [[Eliminate irrelevant classes|irrelevant classes]] yet. | ||
| Line 28: | Line 28: | ||
Random idea that I needed to note: Have a HandHistory class that deals with storing history/information about each hand much like online poker software. | Random idea that I needed to note: Have a HandHistory class that deals with storing history/information about each hand much like online poker software. | ||
| − | Another random idea: Draw Table probably doesn't need to be there, Table should be concrete and | + | Another random idea: Draw Table probably doesn't need to be there, Table should be concrete and HoldEmTable a specific type of Table that has community cards. This goes against "Avoid concrete base classes", but as discussed in class recently this is an acceptable compromise. |
| + | Problem: how to ensure that, for example, a DrawPlayer cannot play at a HoldEmTable? | ||
| + | |||
| + | Another idea: Factory method, in that a player is created when they are added to a table. The type of table specifies the type of Player to create. This would involve re-adding separate classes for HoldEmTable and DrawTable, which creates [[Parallel hierarchies problem||parallel hierarchies]] which I am not happy about, as there seem to be a bunch of them in this design... hmmm. | ||
| + | |||
| + | Flyweight could be used for cards if there are going to be many Tables each with a CardDeck. | ||
Revision as of 05:11, 16 September 2008
Poker Simulator Design
For my design study I have chosen to create a poker simulator. Cards are dealt to a number of players around a table, and the winner of the hand determined. The game can continue for an arbitrary number of hands. Initially there will be no player input or AI, but I will leave the design open for extending it to a full blown poker game. The two variants of poker I am initially implementing are Texas Hold'em and 5 Card Draw, but I am leaving the design open for other variants, eg Omaha, 5 Card Stud etc.
There are also different bet limits in poker, I am not sure how this might effect my design if they are to be implemented in the future. The most common is No Limit where you can bet however much you like at any time, even your entire chip stack. There are also Limit games where bets and raises are limited to a fixed amount, and Pot Limit where bets are limited to the size of the pot.
Here is my initial (incomplete) class diagram. Right now it seems to be a mess of compositions. I'm wondering if this idea will be any good for showing design patterns, hmmm.
I have greatly improved on the original design, here is take 2:
I'm hoping this design will allow me to utilize more design patterns. I have a Strategy pattern for the different DealStyles - for a HoldEm game the dealPlayers() methods deals each player only 2 cards, one at a time, and for a Draw game each player is dealt 5 cards one at a time. The dealPlayers() method can be overridden by any future implementations of other poker styles that may be dealt in a different way.
Design notes
- A poker game can either be a Tournament or a Cash game.
- Tournaments can consist of multiple tables (but are allowed to be only one table), and the tables are gradually removed as players are knocked out and get moved to balance the tables. Players cannot be added after the tournament starts.
- Cash games consist of only one table. Players can be added or removed at any time.
- Players of Draw poker can choose to discard 0 - 5 cards of their hand after the first betting round, and draw new cards from the deck to make up 5 cards.
- Players of HoldEm poker only get 2 cards of their own, which they have to keep.
- HoldEm poker has community cards which are dealt face up onto the table (5 in total), and players have to make the best poker hand possible out of any 5 card combination of the community cards and their own cards. Players can use 0 - 2 of their own cards in making a hand, but the combination that gives the highest ranked hand has to be used.
- I thought about how the "suit" attribute of a Card might break the Beware value switches heuristic, in that when checking for a flush hand, the suit value will be used in case analysis. However I thought it was a bit extreme to decompose Card into an inheritance hierarchy of different Suits, because there will only ever be 4 suits to test. (ie no further extension is possible)
- The CardAnalyser class is not implemented in the design yet, but it is a class that is necessary so I have included it in the diagram.
- I'm not sure if the DrawTable and HoldEmPlayer classes are irrelevant classes yet.
Random idea that I needed to note: Have a HandHistory class that deals with storing history/information about each hand much like online poker software.
Another random idea: Draw Table probably doesn't need to be there, Table should be concrete and HoldEmTable a specific type of Table that has community cards. This goes against "Avoid concrete base classes", but as discussed in class recently this is an acceptable compromise.
Problem: how to ensure that, for example, a DrawPlayer cannot play at a HoldEmTable?
Another idea: Factory method, in that a player is created when they are added to a table. The type of table specifies the type of Player to create. This would involve re-adding separate classes for HoldEmTable and DrawTable, which creates |parallel hierarchies which I am not happy about, as there seem to be a bunch of them in this design... hmmm.
Flyweight could be used for cards if there are going to be many Tables each with a CardDeck.
