Course:CPSC312-2024/BlackJack
Authors: Jordan Sue, Matthew Lai
What is the problem?
Implement the card game Blackjack with the functionality of playing with money, splitting, and doubling.
The player should be able to bet money on each game and earn double if won. Total player money should persist between games.
Blackjack: https://en.wikipedia.org/wiki/Blackjack
What is the something extra?
We will be implementing an AI player to play against along with the dealer, which will have the ability to count cards allowing it to know the optimal strategy of hitting, splitting, doubling, or standing. The AI player will have its own money pool as well.
Card Counting: https://en.wikipedia.org/wiki/Card_counting
What did we learn from doing this?
During our time coding this project we learned that using functional programming works really well for blackjack
- Due to blackjack being a simple turn based game that doesn't have many updating states, it works really well with the game pattern discussed in class which passes the state and the result around. It has similar structure to the games discussed in class making it simple to develop as well.
- Using functional programming meant that the result is only dependent on the input of a function. This made the program simple to test and run test cases because we could give the set states and return non-changing results. This allowed us to test our tricky things such as the result if the player has busted but the computer hasn't and the computer has a better hand than the dealer who stood.
- Due to Haskell being able to not evaluate who list finding the the first card in a long list of cards was faster and more efficient as it would only need to evaluate the first card rather than the whole deck.
- One thing we found that was a problem in our implementation was that due to blackjack having many end game states, such as (player bust, computer stood, dealer stood, computer hand better than dealer), (player stood, computer stood, dealer bust) ...., it would have been better to at these as different Results instead of just having EndOfGame and ContinueGame. This would make the program much more clear and extendable as it could dealt by case due to Haskell allowing functions to have different results depending on the type of input.
- We also noticed that shuffling cannot properly happen. The random module we used for haskell works off a random number generator however we noticed that within the same load of the file it would keep the same number causing the shuffle in the deck to be the same everytime for each load of the file.
What was not finished?
- could not finish splitting, and doubling due to time
Work division
Don't want to disclose