The Hidden Complexities of Creating Three Card Poker
As my first significant project as a student at Flatiron School Denver, I chose to create the casino game three card poker as a command line application using the Ruby programming language with my partner fellow Flatiron Denver student, Jeremy Gray.
I thought of this game as a challenging, but accomplishable first module project. The game of three card poker consists of the dealing of two three card poker hands to the player and the dealer, and a payout based on the type of hand the player is dealt and whether the player’s hand beats the dealer’s hand. We found a public API that allowed for the extraction of the data simulating a shuffled deck and cards dealt from that deck. The purpose of this article is to highlight some of the hidden challenges that were discovered along the way in developing this game that seemed simple enough on paper into a realistic command line application.
One interesting challenge arised from refactoring. As one of the first steps to creating the program, we developed the user interface that printed out a welcome message, prompted the user for input, and gathered information. I discovered quickly that this would be better accomplished if the user environment were abstracted away into functions. This would allow the creation of a readable, succinct runner file to run the process of the game. We soon found out going through the creation of functions such as to print the welcome message, to ask the user if they would like to view rules, to get the ante bet, and to get the pair plus bet, and tying these functions together in the program that would run the game that there was a lot of complexity in getting a seemly simple game to work. It was from this perspective that we realized we were dealing with a Ruby application that would take several hundred of lines of code to implement.
A second interesting challenge I would like to highlight was the development of the function that would determine if the player beat the dealer. This presented many known challenges. First of all, we knew that we needed to create functions that determined what type of hand the player and the dealer had. So, we created these functions. We then could tell that a dealers straight beat a players pair. We then used the high card to determine if a player’s flush beat the dealer’s flush. This would also be the case for straight flushes, straights, and three of a kinds. The problem of comparison was difficult enough. But, then we ran into the unique challenge of what to do with the pairs. This was tricky since we had the value of the pairs to compare, but we also had to deal with the third card. It was indeed possible for the dealer and the player to have the same pair. So, we had to develop a function that determined the pair value and the value of the third card from sorted card values. This information would then be used to determine if the dealer or player wins in the circumstance that the dealer and the player both had the same value of pair.
Overall, this first project was a rewarding and challenging experience. I had a lot of fun playing with virtual cards ;). I would like to thank my partner, Jeremy Gray, and the Deck of Cards API. The project was enriched by the hours of pair programming we accomplished together. I would like to create a user interface using the next technologies I learn in my time at Flatiron School as a next step. Stay tuned.
