Poker Simulator Design Log

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.

Original attempt

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.

Here is my latest version:

Ok so I realised my DealStyle strategy was bullocks and wasn't a proper Strategy pattern. 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 HandAnalyser 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.

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.

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.