April 2009

BEATING BLACKJACKCARD COUNTING FEASIBILITY ANALYSIS THROUGH SIMULATION

Outline

The Hype: Why I Chose This Project Project Objective Background

The Game of Blackjack The Basic Strategy Card Counting Strategy

Simulation Questions My Model

Assumptions Development Screen Shots

Findings Verification / Validation Limitations & Future Work

Background: The Hype

® All rights reserved to the original authors and producers

Project Objective

Simulate the game of blackjack and the proposed card counting strategy to determine if it is possible to actually make money doing this and if so, how much.

Determine how different degrees of human error effect monetary outcome.

Background: Blackjack

Player gets two cards (to start, both face up) Dealer gets two cards (only one is face up) Player decides whether take another card or not Objective is to have cards total as close to 21 as possible

without going over Aces are worth 1 or 11 J, Q, K are worth 10 Whoever is closer to 21 (player or dealer) at the end wins

No money moves on ties (“push”) Dealer goes last

If player goes over (“busts”) he/she automatically looses Two card Blackjack (Ace, Ten) pays the player 3:2

Background: Basic Strategy

1962 (revised 1966): Thorp exposes simulation derived strategy Millions of hands simulated

(not so impressive anymore) This strategy, deemed “The Basic

Strategy,” setup a set of rules explaining what the best move for every given scenario is.

Basic strategy was later revised to account for the 6 and 8 deck “shoes” instead of 1 deck games.

Puts player at 0.57% disadvantage Less than one percent… slow loss rate

Background: Basic Strategy

blackjackscience.com

DEALER UP CARD: TENPLAYER CARD TOTAL: 16

CORRECT MOVE: HIT

Background: Card Counting

Blackjack: A game with memory With a finite number of cards per “shoe” each card that

comes out during play, tells you a little more about what’s left for next hand. IE: If twenty four 5’s come out with a 6-deck shoe, we know no

more 5’s can come out until a re-shuffle happens. 6 Deck Shoe: Memorize 312 Cards? Not Exactly.

High / Low Counting System 2,3,4,5,6 Add 1 to Count 10,J,Q,K,A Subtract 1 from Count

Use count to determine next bet. [Bet a lot when probability is high for player. Bet minimum when probability is low for player.] Weigh count’s meaning based on number of decks left High count = higher probability of player win

(because blackjack pays 3:2)

Questions To Answer

The model should answer the following questions: What is the rate of loss playing perfect

basic strategy? What is the rate of gain (if any) playing

perfect basic strategy and deploying the high/low card counting system flawlessly

Is it possible to make millions using these methods?

How does human error affect the outcome?

Model Assumptions

One player vs. One dealer Simplification of varying number of players

at the table depending on day, time, & location

Time to play 1 million hands IE. counting with a team of people playing

over the course of several months Assumes no casino detection

Shuffling truly is a random process

Model Development

C# Development Load cards into a deck array Load decks into a shoe array Shuffle entire shoe randomly Deal cards to player and dealer Player plays by basic strategy to determine next move Dealer plays by blackjack standard rules to determine

next move Winner gets paid Player bets based on deck adjusted count (“true count”) When end of shoe marker (“cut card”) comes out, shoe is

reshuffled Win, Loss, Push, Blackjack and Bankroll stats are

recorded

Screen Shots: Before Run

Screen Shots: After Run

Findings: ROI

Findings: ROI

?

Verification

Careful code revision and testing in parts Tested card counting, basic strategy, and betting

modules separately before integrating. Printed details of 500 hands and manually

reviewed each to ensure that the program was applying the appropriate rules and performing proper accounting.

Sent code out to a few friends for peer review Verified against published basic strategy statistics

v1.0 was producing results that were 0.02% off from documented values (when running basic strategy simulations only) Discovered a minor logic error in basic strategy code

Limitations & Future Work

Limitations: One player per table Lots of hands played Truly random shuffles Team play not

accounted for No bankruptcy (lowest

bankroll can be negative)

Error rates only account for miscounts not for basic strategy errors.

Surprising result when including error.

Future Work: Simulate team play Incorporate hide

bets and “cover plays”

Model how people come and go from tables

Calculate total time for a team to play x hands.

Questions / Ending Remarks

Code is checked into SourceForge for anyone who wants to check it out.

http://sourceforget.net/projects/cardcounting