Texas Hold-Em
an Evolutionary Approach, Part 2
By Richard Ten Dyke

In Part 1 of this series, I described the goal to build a computer program that will use object-oriented programming to learn how to play a decent game of Texas Hold-Em. In Part 2 we discuss the first of the programming efforts.

In Object-Oriented Programming, an “object” is a piece of code that operates like a small special purpose program. It holds its own data and methods that operate on the data. Objects send messages to and receive messages from each other, just like separate individuals might if they were working on a project together.

An object, also called a “class” contains the methods and holders for the data, but itself does nothing. An “instance” of a class will be created for a specific purpose. An “uninstantiated” class has no operational capability. Only instances can do anything. Unfortunately, the terms “object” and “class” are sometimes used interchangeably. The term “class” usually refers to the abstract description while “object” might be used to mean either the abstract “class” or an instance. An important part of the process of using object-oriented programming is the creation of instances when needed, and destruction when they are no longer needed. Instances should be destroyed when they are no longer needed to free up memory. A class can have more than one instance existing at any time, as we shall see.

When setting up a program using Real Basic, the development system immediately creates two classes and their instances. One is the Application class, which serves as the container for all classes in the application. The second is the Window class and a single instance. The window has built into it many of the tools needed for establishing a user interface, such as buttons, menus and displays. One of the values of object-oriented programming is the ability to re-use code. and this is a good example of that.

In creating a program to play Texas Hold-Em, I used the Window to display the cards being played and buttons to control the action. My first pass at the program is a simplified version of the game, created to get the feel of the game and of the programming techniques. The user, called Player1, plays the game against two opponents. There is no betting strategy to speak of, since the betting is preprogram-med. It costs Player1 one “dollar” to play, two dollars to see the flop, three to see the turn, four to see the river, and five to see the opponents’ cards and to win. If you, Player1, go all the way, you will have bet a total of $15, and if you win, you will receive $30. So the payoff is one-to-one, while the odds against your winning, are two-to one. If you play each deal to the end, you will soon lose all of your money. However, you have the advantage of being able to fold at any point along the way. This gives you an advantage that your two opponents do not have, and if you are smart or lucky enough, you should be able to win against them.

In order to build the logic of the game, I created two additional objects, the Deck object and the Hand object. The Deck object represents a deck of 52 cards. The data contained in the Deck object is a list of the cards that are remaining in the Deck after each card has been randomly “dealt.” The object contains a method for randomly selecting a card from the Deck. To get a card, another object can send a “pick” message to Deck and will receive, in return, a randomly selected number from 1 to 52. Deck will remember which card had been dealt, and will not return the same number again. Deck also contains a method that will shuffle the deck, and start dealing over again.

The second new object is Hand. Each instance of the Hand object contains a list of up to seven cards that have been selected by sending a pick message to Deck. Each card is represented by a number from 1 to 52. For each card Hand will place a “1” in a 4 column by 14 row grid indicating a particular value of that card and its suit. If the card is numbered 1, 14, 27, or 40, it is an Ace of one of the four suits, and a “1” will be placed in row 1 as well as row 14, because in analyzing the Hand, the ace is treated as both high and low.

Hand also contains a method for evaluating the hand itself. It can determine, by adding across a row, how many cards there might be of a single value: one card, a pair, three of a kind, or four of a kind. It can also add the number of cards in a column to determine how many cards are in a particular suit. Five cards in a suit would constitute a flush. It can look down the columns for all suits and determine if there are five entries with no empty gaps, indicating the presence of a straight. The evaluation method goes through these operations and places a value into a special memory location belonging to the Hand, called a “property” which can be retrieved by another object. The value is determined to be consistent with the ranking of Hands, so the value for a flush is greater than the value for a straight, for example.

The mechanism for playing the game is included in the Window object, and specific actions are triggered by mouse-clicking buttons on the Window interface. When Window opens, the program creates one instance of Deck and three instances of Hand, known as Player1, Player2, and Player3. When the “Deal” button is clicked Deck is asked to pick two cards for each Player and send them in Player1, Player2, and Player3. Pressing “Deal” also subtracts one dollar from Player1’s money. When the “Flop” button is clicked, Deck delivers three cards to the table, and places those same three cards to each of the Hands. Each Hand will now hold five cards, the two “hole” cards belonging to each player and the three “table” cards belonging to all. Pressing “Flop” subtracts two dollars from Player1’s money. Instead of pressing Flop, the user could press the “Deal” button again, only at this point the word “Deal” has been replaced by the word ‘Fold” At any future point in the play, the user can click “Fold” and start over with a new deal. Doing so, the user will lose all the money that has been subtracted from his account.

Window also contains place-holders for card images which are gathered from a separate file of 52 card images and a card back.
The user can also press “Turn”, “River” or “Show” in the proper order. Turn and River will each place an additional card on the table, and insert them into the Player’s Hands. They will also cause funds to be subtracted from Player1’s account. Finally, the user can click “Show.” Having done this, the Window will ask each of the Hands for the value that has been determined by Hand’s evaluation method. If the value of Player1’s Hand is the greatest, 30 dollars will be added to Player1’s funds.

The Window contains a progress bar to show a visual indication of the amount of funds remaining, as well as a printed dollar amount. Player1 starts with $100, and when the funds are gone, a message appears “You Have Lost Everything.” and the program terminates. Too bad. Winning enough so that the value of funds goes above $200 prompts a message “You are the big winner tonight, Congratulations!” But your reward is fleeting, because the program terminates this time as well. However, in either case you can always start over with another $100.

In playing around with the program, I personally find it sort of addicting. It is a real challenge to win, and luck plays a role as important as skill. I lose most of the time, but I am getting better.