Course:CPSC312-2023-Texas-Holdem
What is the problem?
We will be implementing Texas Hold’em which is a variant of the card game poker. Two cards are dealt face down to each player, and then five cards are dealt face up in three stages. In the first stage 3 cards are dealt, the next stage an additional card and the last stage the final card. Each player seeks the best five card poker hand from any combination of the seven cards. Players have betting options to check, call, raise, or fold. Rounds of betting take place before the first stage and then after each subsequent deal. The player who has the best hand and has not folded by the end of all betting rounds wins all of the money bet for the hand, known as the pot.
What is the something extra?
We are planning to implement Texas Hold’em with a betting system. Our main thing is checking for each possible Poker Hand combination using the Player’s hand at the beginning combined with the River of cards, and the same for the AI Player. After that, checking which player has the better hand i.e. result. The different hands we check for are Royal Flush, Straight Flush, Four of a Kind, Full House, Flush, Straight, Three of a Kind, Two Pair, Pair, High Card.
What did we learn from doing this?
(This should be written after you have done the work.) What is the bottom-line? Is functional programming suitable for (part-of) the task? Make sure you include the evidence for your claims.
Through this project, we gained valuable insights into implementing custom data types in Haskell and using them to make things simpler for ourselves. Given the complex rules and logic of Texas Hold'em, we found that the functional nature of Haskell was particularly useful when writing concise functions to handle these complex rules. Specifically, we found it particularly useful when developing a method for how we were going to check for every possible hand combination that a player could have.
However, we recognise that implementing a graphical user interface (GUI) for Texas Hold'em might have been easier using a non-functional language such as Java. This is because implementing a GUI can be challenging in functional languages like Haskell, where mutable state and side effects are often avoided. A user interacts with the application by making changes to the interface and this would be easier with a mutable state which allows the state to be changed after the object has been made. Functional programming does not account for this. If one were to use Java it may have been easier to implement a more user-friendly interface.
Overall, for our implementation of Texas Hold’em Haskell was sufficient.