Poker Simulator Design Log
| Line 4: | Line 4: | ||
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. | 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. | ||
| + | |||
| + | == Initial attempt == | ||
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. | 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. | ||
| Line 10: | Line 12: | ||
I have greatly improved on the original design, here is take 2: | I have greatly improved on the original design, here is take 2: | ||
| + | |||
| + | == Take two == | ||
[[Image: Poker Class Diagram 2.png|thumb|200px|centre|'''Take two''']] | [[Image: Poker Class Diagram 2.png|thumb|200px|centre|'''Take two''']] | ||
| Line 15: | Line 19: | ||
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. I'm not sure if the DrawTable and HoldEmPlayer classes are [[Eliminate irrelevant classes|irrelevant classes]] yet. | 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. I'm not sure if the DrawTable and HoldEmPlayer classes are [[Eliminate irrelevant classes|irrelevant classes]] yet. | ||
| + | |||
| + | == Take three == | ||
Here is my latest version: | Here is my latest version: | ||
| Line 22: | Line 28: | ||
Ok so I realised my DealStyle strategy was bullocks and wasn't a proper Strategy pattern, because the abstract Dealer shouldn't have a method for adding community cards as this is only for HoldEm. I have used inheritance to solve this problem instead. I have made CardDeck and PlayerHand store a Set of cards because each Card is unique. Using a TreeSet to store Cards can come in handy for my CardAnalyser class for ordering the cards to determine a "straight" hand. I have also fixed it so that a HoldEmDealer can only be at a HoldEmTable. I'm unsure about all the parallel hierarchies at the moment. I think next I will have a look at the bigger picture and see if there is a better way to model the interaction between different types of Dealers, Tables, and Players. | Ok so I realised my DealStyle strategy was bullocks and wasn't a proper Strategy pattern, because the abstract Dealer shouldn't have a method for adding community cards as this is only for HoldEm. I have used inheritance to solve this problem instead. I have made CardDeck and PlayerHand store a Set of cards because each Card is unique. Using a TreeSet to store Cards can come in handy for my CardAnalyser class for ordering the cards to determine a "straight" hand. I have also fixed it so that a HoldEmDealer can only be at a HoldEmTable. I'm unsure about all the parallel hierarchies at the moment. I think next I will have a look at the bigger picture and see if there is a better way to model the interaction between different types of Dealers, Tables, and Players. | ||
| + | == Take four == | ||
I have done a huge redesign and I think it is finally approaching a finished form. There is still a bit of functionality I need to implement however. | I have done a huge redesign and I think it is finally approaching a finished form. There is still a bit of functionality I need to implement however. | ||
Revision as of 03:09, 23 September 2008
Contents |
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.
Initial attempt
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:
Take two
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. I'm not sure if the DrawTable and HoldEmPlayer classes are irrelevant classes yet.
Take three
Here is my latest version:
Ok so I realised my DealStyle strategy was bullocks and wasn't a proper Strategy pattern, because the abstract Dealer shouldn't have a method for adding community cards as this is only for HoldEm. I have used inheritance to solve this problem instead. I have made CardDeck and PlayerHand store a Set of cards because each Card is unique. Using a TreeSet to store Cards can come in handy for my CardAnalyser class for ordering the cards to determine a "straight" hand. I have also fixed it so that a HoldEmDealer can only be at a HoldEmTable. I'm unsure about all the parallel hierarchies at the moment. I think next I will have a look at the bigger picture and see if there is a better way to model the interaction between different types of Dealers, Tables, and Players.
Take four
I have done a huge redesign and I think it is finally approaching a finished form. There is still a bit of functionality I need to implement however.
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)
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. Flyweight could be used for cards if there are going to be many Tables each with a CardDeck.
