Hello this is my blackjack game. Since english is not my first language some stuff may be in spanish, but I think I translated all text. BTW when it asks if you want to play again S means yes and N means no.
As I read through the examples.. I see something that strikes me as an interesting thought. I really need to work on learning spanish. It would allow me to really name my variables what I want to, without worrying about conflicting with a reserved name. LOL.
There are certain things I see in both code that I think I would do differently.. And if I can get decent at drawing a GUI for a game like this, I would consider making a trainer. It's a thought that has crossed my mind before.
Along with normal BlkJck play, it would have to have a training option where it would display 2 cards, ask me what the total is, then ask me how much I need to make 21, and time both of the answers, and show my average speed at identifying my total as well as what the maximum card I could get without busting would be.
And it would also have to recognize the difference between a hard and a soft hand. (and test me on my ability to recognize the difference.)
ah well.. eventually.. Nice code though, both of you.
Argh. I don't gamble so I know nothing about it other than what I have learned by programming it, and programming this thing has made me realize that blackjack is an obnoxiously complicated game for being so simple.
I'm a little confused about how to properly calculate winnings if the dealer blackjacks. This is what I've got:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
if (hands[ Dealer ].blackjack())
display_all_hands( hands, ShowHoleCard );
cout << "Dealer has blackjack!\n";
for (int player = PlayerOne; player < num_players -1 +PlayerOne; player++)
if (!hands[ player ].empty())
if (hands[ player ].blackjack())
winnings[ player ] += insurance[ player ] *Money( 2 );
winnings[ player ] -= bets[ player ];
display_player_winnings( hands, winnings );
If a player's hand is empty it is because he bought even money and already ended his game. All the monetary items are vectors of a Money class. The player could have bought less than optimal insurance, so I just wonder about the calculation here...
well, being an avid Blackjack player (it's all I ever play when I go to the casino, as seldom as that may be) Insurance is always a sucker bet.. I never take it.
However, the best way to look at it for calculations.. Consider it a side bet, and not related to the regular bet at all, except that it can be no more than half of the normal bet.
If the dealer has a blackjack, it pays 2 to 1. So If the player bet 10 bucks on his normal game, then took insurance for the ful 5 dollars (half of his normal bet) and the dealer has a blackjack, the player wins 10 bucks on the insurance.
Now if the player also has a blackjack, he pushes (ties) the dealer on the main hand, but still wins that insurance bet and makes 10 bucks in the process. If he doesn't, he loses the 10 bucks from the normal bet, but still makes the 10 bucks from the insurance. (which is why it's called insurance, cause his normal bet pays off the insurance bet.)
So.. what if he bets less than half? let's say he bets 2 bucks on insurance. And the dealer has a blackjack. He wins 4 bucks on the insurance, and loses his original 10 bucks from the normal bet. (unless the player also has a blackjack which means he pushes on the normal bet, but still wins 4 bucks from the insurance)
So basically, insurance is a side bet, where the player is betting that the dealer has a blackjack. Nothing more.
Edit: I just read your post in the Beginner's about how you dealt the cards. I wanted to mention that while the idea of randomly dealing the cards at the time of deal is probably the easiest way, I was considering setting up a vector to act as the shoe.. or as the deck, and randomly placing the cards (up to 50 just to be safe?) into it before the deal, so that I know the cards would come out the same way weather or not I chose to stand or hit.
This would also give me the option of re-playing a hand if I chose to.
Then I would just randomly insert new cards into the shoe every hand.
In the case where the player has a blackjack. and the dealer has an ace showing, lets say player bets 10 bucks, normally he'd expect to recieve 15 bucks from the blackjack.
Now, let's say he takes 5 bucks insurance.
If the dealer has the blackjack, the blackjack pushes (or ties) but you get 10 bucks from the insurance
If the dealer doesn't have blackjack, you get 15 bucks from the blackjack but lose 5 from the insurance. Net gain is still 10 bucks.
Even money simply eliminates the step of insurance and just collect 10 bucks (not 15) for the blackjack.
Another thing to consider is Surrender. (Late and early surrender) That's also mentioned on the page.
Wow, nice link! I've been working off of just the Wikipedia article, which is a little fuzzy on some details.
Yes, my game correctly considers even money. If offered and accepted, the player gets an immediate payout and ends his game. (His hand is cleared.)
I didn't know that you can only surrender as a first action. I'll have to modify my code for that. I also couldn't figure out early vs late surrender, but it looks like I'm using late surrender.
I'm considering letting players name themselves... (so that they can come and go without loosing their winnings data) but for a stupid computer game it might be overkill... Currently I have it as "Player One".."Player Six" and requiring a complete reset to change the number of players.
The part that I'm kinda stumbing over.. is how to implement the hand object.
What I am thinking of doing is having one hand object, with a vector to hold the cards, a function to return the cards, and an function to return the value of the hand.
From this, i'll derive player hand (phand) and dealer hand (dhand). with slightly different functions foreach.
Now.. here's where I'm trying to come up with a conclusion. A couple different things actually.
First, when returning the hand, for printing, do I build the string inside the object and return the string, or return the vector and build the string outside the object.
Also, when returning the value, I need to also include wether the hand is hard or soft. (soft means there is at least 1 ace in the hand, and that the ace is being counted as 11) Now, I don't want to store the value or the soft/hard bool in the object itself. I want to come up with these on the fly.
So do I make a struct to pass back with the value and a bool Soft? or do I make a struct that passes back a hard value and a soft value (even if they are the same)? or is there another method I should be considering?
constchar* Suits = ...;
constchar* Faces = ...;
enum Suit ...;
enum Face ...;
Card( int index = 0 ):
face( (Face)(index /13) ),
suit( (Suit)(index %13) )
ostream& operator << ( ostream&, const Card& );
struct Hand: public vector <Card>
int value() const;
bool blackjack() const;
bool hard() const;
if (cards.empty()) reset(); // just a safeguard. main() resets the deck if < 50 cards remain
int index = rand() %cards.size();
int value = cards[ index ];
cards.erase( cards.begin() +index );
return Card( value );
unsigned size() const;
vector <int> cards;
const vector <Hand> & hands,
There's of course more, but those are the basics.
I have a separate display_all_hands() function because I show the hands in a tabular format to optimize on screen space.
Dealer Player One Player Two Player Three Hole Card Three of Clubs Ace of Diamonds Seven of Diamonds Queen of Hearts Seven of Hearts Nine of Spades Four of Clubs
Player Four Player Five Two of Hearts King of Spades Eight of Hearts Seven of Clubs
As far as hard or soft hands are concerned, I haven't been bothering to ask. I just make it assume whatever is most advantageous to the player (whether dealer or not). Is the player supposed to choose one before hitting any additional cards? (In other words, is it possible to bust based on a predetermined choice between hard and soft?)
the program should handle both accounts, it should be possible for a hand to start off soft then turn hard. (ok.. um.. changing subject)
Basically, what I was going to do was. When the hand is called for it's value, have it loop through each card, adding to value. If it comes across an ace, and value is <= 10, have it add 11 and set soft bool to true (or hard bool to false if you perfer). Then any other aces would only count as 1 (since two aces at 11 each is automatic bust). Then if the value goes over 21, and soft is equal to true, subtract 10 and set soft to false.
Then It needs to return along with value, weather hand is soft or hard (for displaying to the player, can keep that info secret if you wish).
OR the other option would be, return a struct that had two ints, hard and soft. If the added value is soft, store it into soft, subtract 10 and store that to hard. If added value is hard, store as is in both soft and hard.
Then the main can check, if soft is higher than 21, use hard instead. And of course, if hard is higher than 21.. it's a bust
Phew. I'm glad that's how it works... that is how I am doing it.
When I calculate the value I just loop through each card and add aces as 1.
Once done that, I check to see if I can bump one of those aces up to an 11 without busting. Since I never actually display the calculated value to the user, I don't consider this a problem -- as future cards added to the hand can bump that ace back down.
I do also have a little class flag that gets set by value() to indicate whether or not the hand is hard or if it was made soft. (That way the dealer can choose whether to hit or stand -- I'm playing H17.)
Now I have two ways to check the hardness of the hand, depending on whether or not I have already called value(). [But actually, the cost of adding a hand is so little I never use the is_hard field directly.]
That's not the only way to do it, of course, but it works and is simple. If you can live with an explicit side-effect like that. :-)
Eh, you're right. I shouldn't do it that way. I think I originally had it because I was using some STL algorithm on the class and wanted to be lazy, but I'm still dinking around a little. Get rid of the const and mutable keywords. I suspect I've still a little tweaking to do to the design before I'm done. (That side-effect is really irking me.)