Blackjack

SEIS 635 Group ProjectChris Hansohn - Amir Muhawesh

Blackjack

Topic Description

Blackjack has been chosen as the program of choice for our semester project for several reasons. Blackjack is readily represented by domain objects such as card, deck, etc while also having clear relationships between objects (hand holds cards etc). Furthermore, Blackjack has clear and distinct rules and that can be translated directly into code without any ambiguity, the rules are concise and clear and do not allow for misinterpretation. This allows us to create the program without the need for a domain expert, as it would with something like accounting or tax software. Although this may seem like a fairly obvious factor, it is one that is important not to overlook.Blackjack also presents itself as a program that can easily be broken down into easily manageable iterations, which still maintaining its integrity if all of the iterations are not reached.For example, in Blackjack, we can breakdown the iterations as follows: Basic interaction and domain objects Expanded rules Adding betting and a bank Multiple players Adding a GUIWith these iterations, we would technically be able to stop after the second iteration and still have a program which follows the basic rules of the game. If we decide to shrink the scope, add or change members of the group, or pick back up on the project in the future, we will have clear and concise milestones to work with.

Breakdown and Requirements:

The goal of Blackjack is to get a hand of cards whose value is greater than the dealers hand without exceeding 21. Each card has a value from 1 to 11, and the ace is worth 1 or 11 depending on which gives you a better value. Number cards are worth their number value, and all picture cards are worth 10. (A cards suit has no effect on the cards value)Betting:

All players must place their bets before any dealing begins, with a cap, such as 50 or 100 dollars placed on each bet, per game.Dealing:

Once all bets have been placed, the dealer deals the cards. He starts with the first player, and deals a card up to each player, finishing with himself. The process is repeated, but the dealer's card is dealt face down, this is the hole card. Dealing is complete when the dealer has dealt each player two cards.Playing:

Actual play and vary depending on what the dealers card is. If the dealers facing up card is worth 10 (ten count) or is an ace (eleven), the dealer is required to check his hole card. If the hole card gives him a total of 21 play automatically ends and the game moves to settlement. If the hole card does not give him 21, gameplay moves on as normal. If the dealers up card is not a 10-count or an ace, play automatically moves to the first player. If the player has a blackjack, play skips to the next player. If the player doesn't have 21, the player has two choices: to hit or to stand:

Hit: If the player isnt happy with his hand, he can draw another card, which is known as a hit. The player can keep hitting until he goes over 21 (busts) or stands (stops needing cards).Stand: If the player is happy with his hand, he can choose to stand, and get no more cards. After the player busts or stands, gameplay moves on to the next player. This process repeats itself until each player has played. After each player plays, the dealer plays his own hand. The dealer usually has rules about when to hit and when to stand. This is so the casino doesnt have to worry about the dealer taking a risk and losing themselves money. The average choice the casino makes is if its less than 15 or 16 to hit and if its greater than to stand. These rules are based on statistics of when hitting will cause the dealer to bust. When the dealer completes his turn, the game moves into settlement where scoring and payout occur.

Settlement: After the dealer finishes his turn or gets a blackjack, play moves onto settlement. During settlement, each player who busted loses what he betted. Each player with a hand lessthan the dealers hand is considered as losing, and each player with a hand better than the dealer wins his bet, and each player with a count equal to the dealers has a standoff and no payout is made. Bets are paid out evenly among the players. If a player has a Blackjack and the dealer doesnt, the player is paid at 3:2 odds. For example, if the player bet 50 dollars he is paid 75 dollars.

ETC...:

The Deck: Blackjack is played with four 52-card decks which are combined into one large deck.

Players: Blackjack can contain up to seven players.

Doubling Down: After receiving his two cards, players can choose to double down, by doing this, he doubles his bet, receives another card, ending his turn.

Insurance: When the dealers face up card is an ace, the player can place an insurance bet. The insurance bet is equal to half of the original bet. If the dealers hole card gives the dealer a blackjack, the player breaks even. If the dealers hole card does not give the dealer blackjack, the player loses his insurance.

Splitting pairs: A player has a pair if the first two cards dealt have the same value. If the player is dealt a pair, he can split the hand into two new hands. If the player splits the pair, the dealer deals each new hand another card, and the player must place an equal bet on the new hand. A player can split any pair that results from another split (except for a pair of aces). A 21 resulting from a split is not treated as a blackjack. After splitting, the hands treated as a normal hand would be.

Actors:

There will be two actors in this system, the Dealer and the Player. The Player is the primary actor in our system.

Analysis:

Use Cases:

Fully Dressed Use cases:

Use Case Name: Deal CardsStarting with the first player, the dealer deals a card face up to each player ending with himself. The dealer then repeats the process, but deals his own card face down. Dealing finishes and play continues when the dealer has dealt every player, including himself, two cards.Actors:Primary Actor: DealerMain Success Scenario:1. Dealer deals one card face up to every player including himself.

2. Dealer deals a second card face up to all non-dealer players.

3. Dealer deals a card face down to himself.

Preconditions:

A new game has already started

Post conditions:

All players and the dealer have been dealt a hand with two cards

The turn of the first player who does not have blackjack starts

Play continues for each player who does not have blackjack

3A. Alternative Flow: Dealer has blackjack

If the dealer has a natural 21 or blackjack, the game ends. ThePlayers do not get to take a turn

Use Case Name: Player hitsThe player decides he is not happy with his hand, the player has not busted, and decides to hit again. If the player doesnt bust, he can either hit again or stand. If the player ends up busting, play moves to the next player.Actors:Primary Actor: PlayerMain Success Scenario:1. Player decides he is not satisfied with his hand.

2. The player requests another card from the dealer.

3. The player can decide to hit again, or stand if his hand totals less than orequal to 21.

Preconditions:

Players hand is valued at less than or equal to 21 Player doesnt have blackjack Dealer doesnt have blackjack

Post conditions:

A new card is added to the players hand

Alternative Flow 3A: Player busts:

New card causes players hand to exceed 21. Player busts (loses). Nextplayers/dealers turn begins.

Alternative Flow 3A - B The players hand is greater than 21, but player has an ace

The new card causes player to bust, but the player has an ace. The value of the ace changes from eleven to one, which bringing the players hand to less than or equal to 21. The player can decide to hit again or stand.

Use Case Name: Player standsThe player is happy with the hand he is dealt and stands.Actors:Primary Actor: PlayerMain Success Scenario:Player stands:The player is happy with the hand he is dealt and stands.Preconditions: Player has a hand whose value is less than or equal to 21 Player doesnt have blackjack Dealer doesnt have blackjack Post conditions:Players turn is complete

Use Case Name: Dealer Hits

The dealer must hit if his hands total is less than 17 (as decided as a business rule not a rule of the game). If the dealer does not bust after the hit and his hands total is still less than 17, he must hit again. The dealer must stand on any total greater than or equal to 17. When the dealer busts or stands play terminates.

Actors:

Primary Actor: Dealer

Main Success Scenario:

1. The dealer hits if his hand is less than 17

2. New card added to dealers hand

3. If the total is less than 17, dealer must hit again

Preconditions:

Dealer has a hand whose total is less than 17

There has to be a player currently standing

Post conditions:

New card in dealers hand

Play ends

Alternative Flow: 3A Dealer busts:

New card causes dealers hand to be greater than 21. Dealer busts.

Alternative Flow: 3A Dealer stands:

New card causes dealers hand to be greater than or equal to 17. Dealer stands.

Alternative Flow: 3A Dealer has ace, stands

The new card causes the dealers hand to be greater than or equal to 21, but includes anace. The value of the ace changes from 11 to 1 bringing the dealers total to 17;dealer stands.

Alternative Flow: 3A Dealer has ace, hits

New card causes dealers hand to be greater than or equal to 21, but includes anace. The value of the ace changes from 11 to 1 bringing the dealers total to lessthan 17; dealer hits.

Use Case Name: Dealer Stands

The dealers hand is greater than or equal to 17, and stands.

Actors:

Primary Actor: Dealer

Main Success Scenario:

1. The dealers hand is greater than or equal to 17, and stands.

Preconditions:

Dealers hand greater than or equal to 17

Must be a player in the standing state

Post conditions:

Play is complete

Alternative Flow: 1A No standing players

If there are no standing players, the dealer will automatically stand

Domain Model Diagram

Our domain diagram turned out to be fairly straightforward, as the objects in the program are fairly easily represented by classes in our diagram. We will have a deck shuffler, which shuffles four decks of cards upon request of the dealer. The dealer then calls two cards from the deck pile, which pulls two cards from the deck. The dealer will deal a hand to himself and the player, then proceed to play against the player, while checking the rules against the Blackjack rules list. Play terminates when all conditions are met.

Domain Model:

System Sequence Diagram - High Level Game Flow

Design Diagram Initial Class Diagram

Design Diagram Final Class Diagram

Design Diagram Object Interaction Diagram

Team Organization:

Whenever more than one mind is at work on a project, collaboration and communication are crucial for everything to stay on track, from inception to implementation. From inception, our primary method of communication was email and text. Most of the development for our project happened outside of class time and was a result of pre-agreed milestones. This proved to be necessary, as our schedules tended to overlap and commute times to middle ground made meeting in person regularly unrealistic.All development was done using Eclipse pulling from a Google Code repository using Mercurial. Eclipse was chosen due to the familiarity of both team members with the IDE. Google code was chosen for several reasons:

Free Both team members are regular Google users Support for both Mercurial and Git Simple and scalable as the project grows Google Reliability

Using version control for the project was a no-brainer, it is difficult to imagine what large scale development was like before cloud storage and repositories existed. Comparing and merging code seemed like it would have been a nightmare. One issue that was raised during development with Google Code is its awkward handling of non-code artifacts such as documents and images. Although it allows for uploading of these items, it seems to only allow users to download them as raw data, and there is no on-line viewer for these items, it acts as a repository only, which is nice, but forced us to use Google Drive in addition Google Code.Mercurial was chosen as the version control system of choice for similar reasons as Eclipse was chosen familiarity of the team members with the system. Although it is worth noting a project of this scale, which simply involved pulling, pushing and committing code offered no real differences between Git and Mercurial on this level.An area that proved to be fairly problematic was the use of Magic Draw. For our code, we had a remote repository to share, for our project paper and presentation, we had Google Docs which kept us in sync, with Magic Draw, we had no such convenience however. This problem was compounded by our reliance on Magic Draw to agree on designs for our program as well as generating the initial code. We found ourselves having to append the date onto the filename in order to keep track of what the most recent revision of the diagrams was. Still, with this naming convention, there was no promise that a team member would not modify and save a file, forgetting to rename it or send the update to the other team member, causing an unwanted and unknown branch to occur.

Conclusion and Hindsight:

Although this project was similar in description to the final project of 610 (create a working program), there was little similarity beyond that. This project focused and emphasized the analysis and design of the program as crucial to the development process, highlighted it as not only helpful but compulsory. A majority of our time was spent coming up with and agreeing upon the domain model, class diagram, and use cases before any line of code was written. When the time came to begin writing code, the transition seemed natural and appropriate, as we both had a solid idea of how program was going to flow and fit together. The project in 610 involved simply picking an idea and jumping head first into the coding without requiring any kind of analysis or design, resulting in a kind of code and pray style of programming. This project connected the dots between simply knowing syntax and understanding how objects should interact and being able to implement both together to come up with a functioning program.One issue that popped up unexpectedly was scope creep and feature creep. Although this was discussed in the Project management class, we found it difficult to keep under control. It is extremely difficult to estimate needed to complete certain tasks with any kind of accuracy, and overestimating doesnt seem to work. Initially, it was the project managers hope to complete four iterations, banking on the fact that each iteration was fairly small and well segmented from the rest of the project. Basic interaction and domain objects Expanded rules Adding betting and a bank Adding a GUI We found that although the project was well broken up into each iteration, the initial iteration took much longer than anticipated, causing us to fall short our initial goal of completing all four iterations. (we completed only the first one). This was not an issue of needing to start earlier, but needing to be able to better estimate needed for development and planning. Conversely however, using iterations allowed us to identify the fact that we were coming up short on time, and focus on hitting the wall of iteration one solidly instead of leaking into iteration two and having code that was not complete. Focusing on accurate estimation of development time would be our primary focus if we were to repeat this project.