Overview
It just occurred to me, rather belatedly, that the position changes when a player is eliminated during a tournament seem to differ between the poker game I’m developing and other poker apps. I somehow assumed that simply moving the BTN one position clockwise would suffice, but perhaps I’m wrong. No, I’m definitely wrong, so this article will summarize the process while correcting it.
Instead of the BTN, Move the BB Position One Space Clockwise.
The problem with moving the button one space clockwise is that if a player is eliminated, some players will end up skipping the big blind. For example, let’s assume that in:
| A | B | C | D |
| BTN | SB | BB | UTG/CO |
the SB player (Player B) is eliminated. At this point, if BTN is moved one space, it becomes
| A | B | C | D |
| BB | × | BTN | SB |
but player D will have the BB skipped and become SB. This means that the burden on the BB can be avoided once, which is therefore not an appropriate procedure. In this case, the assignment is:
| A | B | C | D |
| UTG | × | BTN | BB |
and the correct procedure seems to be that there is no SB (apparently this is called a Dead SB). Moving the BTN by one space would result in the same process as anything other than the SB being removed, so this case requires special handling.
Another way of thinking about it is to consider the priority order as BB > SB > BTN, and designate it as
| A | B | C | D |
| UTG (BTN) | × | SB | BB |
where the BTN does not exist (or the BTN does not move) instead of the SB (Dead BTN). Apparently, the old rules were like this, but recent rules tend to adopt the former method. This rule seems to be a result of prioritizing the assignment order in the order of BB > BTN > SB. In particular, the order of actions after the flop changes, so position assignments need to be handled appropriately. Well, in my game, it might be better to make this an selectable option in the game rules (though I’ll probably just use Dead SB and consider it as a future expansion).
If SB and BB Are Eliminated at the Same Time
If multiple players are eliminated simultaneously, they can be categorized into the following cases:
- If players other than SB are eliminated
- If players SB + other than BB are eliminated
- If players from SB and BB are eliminated
In case 1, the BTN moves as usual; in case 2, it is treated the same as a Dead SB in the previous section. The third case is the one that requires special handling.
Let’s consider the following cases.
| A | B | C | D | E |
| BTN | SB | BB | UTG | CO |
In this case, assume that B and C are eliminated simultaneously. However, since BB can only move one space, the answer in this case appears to be:
| A | B | C | D | E |
| SB | × | × | BB | BTN |
The assignment of the SB feels somewhat unfair, but it seems this arrangement is correct as a result of prioritizing the BB assignment. Since things get confusing when two or more players are eliminated, the BB is moved, and the SB and Button (BTN) are assigned to the player one and two positions before the BB, respectively. In this case, the Button appears to be rotating in reverse, making it a rather strange rule…
Another example is when multiple players are eliminated simultaneously, resulting in a heads-up situation. In this case, the BTN remains stationary, while only the BB position changes. In the example above, if SB, BB, and CO were to drop out simultaneously, the assignment would be:
| A | B | C | D | E |
| BTN/SB | × | × | BB | × |
For special handling, it seems that incorporating two possibilities—SB+BB and SB+BB—should solve the problem. The case where there is no SB will need to be specially implemented, and since SB+BB is essentially the same as reversing one button, incorporating a button reversal process should suffice for now. Those developing their own tournament (S&G, MTT) logic should be careful.
Comments