Introduction
In a previous post, I briefly considered table rebalancing methods, but when I started implementing it, I felt like it wouldn’t work well. In this post, I will ignore the following factors and consider an algorithm that can balance the number of people. In the next post, I will consider an algorithm that takes these factors into account.
- Keep the number of positions (BTN, BB, etc.) as equal as possible (move to a position close to your current position).
- Reduce stack imbalance.
- Players who have moved recently or have moved many times will be given lower priority for movement.
Startup Process
The table configuration is represented as \(\small n_1,\cdots,n_T, n = \sum_{t=1}^T n_i\).The minimum number of people constraint is represented as \(\small \underline{n}\) and the maximum number of people constraint is represented as \(\small \bar{n}\). Since there is no difference between players at the start, it is best to keep the number of tables as small as possible and arrange them so that there is as little difference in the number of players at each table as possible. Since the minimum number of tables that satisfies the maximum number of people constraint is \(\small T^{\ast}=[n/\bar{n}]+1\) (where \(\small [x]\) is the Gaussian symbol), all that remains is to place one person at each table in order so that the difference in numbers is minimized. For example, if \(\small n=100\) and \(\small \bar{n}=9\), the minimum number of tables is 12, consisting of 4 tables with nine people each and 8 tables with 8 people each.
Processing at the End of the Game at Each Table
Since table rebalancing cannot be performed during a game, a decision is made as to whether to disband a player or table to be moved at the end of the game, and the move process is then carried out at the end of the game at the table to which the player is to be moved. Since there are late registrations (participants midway) and re-entries, the placement of these players must also be done at the same time. According to ChatGPT, the method commonly used in practice is a procedure called the Greedy method.
Roughly speaking, it consists of the following three steps:
- Disbanding tables with few people (table break)
- Moving players from tables with more players to tables with fewer players (Greedy method)
- Adding more tables (if the number of players increases)
If the table falls below the minimum number of players \(\small \underline{n}\), the table is dismissed and the players are moved to the waiting list (a list of players who have not yet been assigned a table due to late registration or re-entry). It seems that it is common for players who move due to table breaks to have their seats assigned randomly, just like new entrants.
The algorithm that goes by the name “Greedy Method” is process 2. If there is a difference of two or more players between the table with the largest number of players and the table with the smallest number of players, players are moved from the table with the largest number of players to the table with the smallest number of players. In this case, players who have moved seats less frequently or who are in a position close to the seat they are moving to will be the ones to move (so they can play in roughly the same position after the move). This allows the game to proceed with roughly the same number of players overall.
As a note, it is recommended to set the minimum number constraint \(\small \underline{n}\) and the maximum number constraint \(\small \bar{n}\) to approximately \(\small \bar{n}\approx \underline{n}/2\). This is because if \(\small \underline{n}\) is made too small, there will be many tables with few participants. If the max is 9, then \(\small \underline{n}=5\) (break the table when there are 4 or fewer players), and if the max is 6, then \(\small \underline{n}=4\) (break the table when there are 3 or fewer players) would be fine. This is to prevent the possibility of joining two tables together (if the max is 9, it is better to join to a table with 8 people than to have two tables with 4 people each).
Naturally, if the number of remaining players falls below the minimum constraint, a branching process must be performed to prevent the table from breaking. At the end of each game, each table will be able to break tables and decide whether to move using the Greedy method, which will automatically maintain a balance in the number of players between tables.
Waiting List Processing
If the number of players increases due to table breaks or late registrations, new tables will need to be added. In this case, if the number of players on the waiting list exceeds the minimum constraint \(\small \underline{n}\), you can simply create a table with the players on the waiting list. The number of players will be adjusted using a greedy method as the game progresses. If multiple tables are created, the same algorithm can be used at the start of the game.
What can get tricky is when the number of players on the waiting list falls below the minimum constraint \(\small \underline{n}\). In this case, the only option is to have them wait, but you might think that it would be better to assign them to an empty seat each time a game at an existing table ends. However, there are cases where the following problems occur. For example, suppose there are three existing tables, each with 9, 8, and 8 players seated (assuming the maximum number of players per table is 9). In this case, if there are three players on the waiting list, assigning them one by one to the empty seats will leave one player unassigned, and that player will not be able to participate in the game for a while.
To avoid this, you need to know the number of tables you need.In the example above, there are 25 people + 3 people = 28 people, so you will need \(\small [28/9]+1=4\) tables. This means that new tables will have to be added and players will have to move around. Therefore, in this situation, we must handle the situation by adding more tables with players on the waiting list, then greedily moving players from tables with more players, and starting the game when the number of players exceeds the minimum constraint \(\small \underline{n}\). The number of players moved must be limited to “number of players/number of tables” (in the example, \(\small 28/4=7\), so when a 9-player table is finished, 2 players are moved). It is important to note that you will need to check each time whether the required number of tables exists and branch the processing accordingly.
Conclusion
For now, it is believed that implementing the processing described in this article will provide sufficient functionality for MTT table rebalancing, and it is likely that the algorithms used in m Hold’em and Poker Chase are similar. However, according to ChatGPT, there seems to be a more sophisticated approach, which is a mathematical problem (although I’m starting to forget that this is a math blog…), so I’ll introduce it next time.
Comments