Experiments with drawless chess tiebreaks: cumulative progress, last progress, and reset mobility

[fenor94]

I have been experimenting with a simple drawless tiebreak rule: the player who makes more progress wins. Specifically,

- If the game ends by normal checkmate, checkmate decides as usual.
- If the game is classically drawn, the winner is the side with the higher tiebreak score, defined as the total number of plies where that side made a capture or moved a pawn.
- In my current version, if the tiebreak score is equal, Black wins.

All experiments below used Fairy-Stockfish-derived engines. The main tests used fixed node budgets rather than time controls. This cumulative-progress rule was tested more extensively, up to 10M nodes in the main comparison.

1. Results

I then tried a simple hand-written evaluation patch. The engine still uses the SF 18 NNUE evaluation, but in drawish positions it adds a bonus for being ahead in the tiebreak score. The policy roughly worked like this:

- Use normal NNUE evaluation in clearly winning/losing positions.
- If the NNUE score is near equal, add a bonus proportional to the tiebreak score difference.
- The bonus is larger in drawish, low-material, and high-rule-50 positions.

The baseline was the default SF18 NNUE. The tiebreak result itself was visible to both engines at terminal nodes, so the default engine could avoid a losing tiebreak if it searched far enough to see it.

The surprising result was that this very simple patch was already quite effective under the cumulative-progress rule. Some results:

Code: Select all

TB-aware engine vs official/default engine, cumulative-progress scoring

1M nodes vs 1M nodes:     71-29
1M nodes vs 2M nodes:     16-16
3M nodes vs 3M nodes:     72-28
5M nodes vs 5M nodes:     67-33
10M nodes vs 10M nodes:   75-25

From the results it seems that the TB-aware engine outperforms the default one by exploiting drawn cases. However, this advantage can be partially offset by giving the default engine more search, which suggests that the rule may not dramatically change the original dynamic. Also, I did not see a strong first-move advantage.

Interestingly, I also tested the same patched engine under ordinary classical scoring against official SF18, and it performed worse than the official/default engine (36-64). This suggests the patch was not simply a stronger chess engine. It was specifically exploiting the new tiebreak rule.


2. Last-progress / last-move tiebreak

For comparison, another widely discussed tiebreaking rule is simply that the player who made the last progress move wins the classical draw. I implemented it as a separate Fairy-Stockfish variant and made four simple last-progress-aware evaluation patches. The idea was to reward the current last-progress owner in drawish positions. The results were not very encouraging:

Code: Select all

LP-aware eval vs default, 1M nodes, 100 games

weak:    49-50
medium: 49-49
strong: 36-60
extreme:27-71

So a small bonus did almost nothing, while larger bonuses made the engine worse. The rule does not seem like pure coin-flipping, since search strength still affects who gets the last progress move, but compared with cumulative progress the signal was much less stable and much harder to exploit with a simple static evaluation term. My current view is that last-progress is probably fair, but too tactical/noisy to be a very satisfying strategic drawless rule.

3. Cumulative progress vs reset mobility

I also analyzed the games from my tiebreak engine with a simple reset-mobility-style metric, inspired by the R-mobility idea discussed in the TCEC context. The correlation between the two metrics was quite high: the Pearson correlation between TB diff and reset-mobility margin was 0.829. This suggests that both are measuring related notions of progress/control. However, the cumulative TB rule is simpler: it does not require calculating mobility after every move, which may make it more convenient for OTB use.