This section will explain the communication between the program and the Holdem Manager database (figure 19). The first step was establishing a successful connection with the database, a SQL library, named PostgressSQL JDBC, was used to facilitate this procedure. With a successful connection established there was the need to understand the Holdem Manager Database table and column names so that specific statistics would be found. Eventually some information was found on the Holdem Manager forums [17] which contained some examples that where very helpful for the first queries:
Getting some statistics from players14;
Getting current active players15;
Getting some columns description16.
The most helpful information found was a text17 document containing various statistical definitions for Holdem Manager Database. The text document contained column names and evaluation formulas that helped in the construction of more elaborated queries.
14 http://forums.holdemmanager.com/manager-general/32307-using-stat-formulas-sql-query.html
15 http://forums.holdemmanager.com/manager-general/31032-query-get-current-active-players.html
16 http://forums.holdemmanager.com/manager-general/669-description-required-some-database-columns.html
Agent Implementation
4.4.1 SQL Queries
The first query made was obtaining the name of my hero at the poker room, a simple query where only the name was searched among all players. The real interesting queries and most difficult to obtain took a little while to construct and validate. They aim to obtain the name of the player currently active at a table, his total hands, vpip, pfr, his raise per every position on an unopened pot, and his fold per position facing a 3 bet. A portion of a query will be presented below which refers to the folding percentage facing 3 bet at the button position:
“…sum (case when positiontype_id = 5 and
phmisc.threebetresponsetype_id = 1 then 1 else 0 end) as FoldToThreeBet_Button, sum(case when positiontype_id = 5 and phmisc.threebetresponsetype_id > -1 then 1 else 0 end) as FacingThreeBet_Button…”
Fold to 3 bet from the button will be the evaluation of:
After the construction and validation of all queries18, all the information was stored as new players and added to an array of players. Every action, on every hand a player has played is now
Figure 19 - Agent’s Architecture
Agent Implementation
4.5 Conclusions
The most challenging aspect in the implementation was the reaction time of the agent, since there is a fixed time to play each hand. The combinatorial calculations where consuming the most time in the agent’s reactions, luckily with all the information available some situations did not need combinatorial calculations. For example having a hand like deuce three will result in a fold from the agent, without the need of any calculations since it is one of the worse hands on poker. So by eliminating hands not eligible to play, it boosted the agent’s speed and its ability to play more than one table at a time. To determine which hands are available and which aren’t, some sub lists where created from the hand strengths table where its value would be above a significant range percentage.
Experiments and Results
Chapter 5
Experiments and Results
Here it will be described the agent’s results and experiments performed in order to evaluate its accomplishments. The primary objective was to create an agent able to play online poker against human players. A secondary objective was to ensure the agent’s performance to be at least break even, since there is an amount of money that goes to the poker room called rake.
This amount is usually 3% of the total pot, and a player who neither wins nor loses at online poker games is actually winning by a little, since 3% of every pot played is lost to rake.
Both of these objectives have been fulfilled with success. The second objective deserves a special attention since the agent was able to make a profit against human players, being able to exploit some of the human players for the total number of hands played.
5.1 Experiments
The agent was put to play against human players at play money tables, for the purpose of validating the game state recognition relying only on the table chat console, without database communication. This turned out to prove that the functions for table recognition where working and the player’s actions, positions and the agent’s hand were being read successfully. Since the Holdem Manager Database doesn’t recognize play money tables, the only way to verify if the SQL.java was working properly was to play at a real money table and verify if the player’s statistical information was being read and processed by the agent.
Starting at No-Limit Texas Hold’em and blinds19 of 0.01/0.02€, the agent is configured to play at tables of 6 maximum players. It is necessary to enter tables with a minimum of 4 players plus the agent and configure the poker room to seat at each table with 10 big blinds. After the agent’s stack becomes larger than 20 big blinds, there is the need to switch to a new table.
Multiple tables can be played simultaneously as long as the time for each play doesn’t run out.
The experiment of playing poker with real money went as expected and the agent performed its tasks correctly. The results will be stated in the next section along with the
Experiments and Results