SebLague
commented
1 year ago Hi, thanks for the suggestion and clear explanation of the issue. I have added IncrementMilliseconds to the Timer class in the latest version. The first tournament with all the engines will still be played with 0 increment, but I plan to add a small increment for the playoff games between the top engines.
Every significant computer chess event is run with some kind of increment, whether that's something like CCRL's 40/15 (15 minutes for 40 moves, resetting on move 40) or TCEC's more familiar 30+3 (30 minutes plus 3 seconds each move).
The purpose of this is to avoid timeouts; since it is trivial to program an engine to never use all of the time it has remaining, the only way to time out is due to factors outside its control e.g. C# deciding to run a big GC pass right in the middle of a search.
In games without adjudication this is more common than one might think. Engines tend to play quite conservatively, happily trading down into a theoretically drawn endgame if the position looks equal. The resulting endgames are not trivial material draws however, and commonly the engines will still evaluate a small advantage for one side or other, meaning they will avoid repetition and play out until they hit the 50-move rule. Without increment, if a game enters this phase and both engines are short on time, the game will essentially come down to a coin flip of who happens to time out first, which isn't an accurate indication of the engines' strengths anymore.
Even looking at Stockfish's test queue one can see that all of these super-fast games are run with increment, the rule of thumb in the chess engine community being that the time control should be
X+X/100seconds, e.g.60s+0.6.Adding increment will make the tournament fairer across the board, even if done completely opaquely (the time that the engine is given includes the increment added on).
I have heard arguments that changing the format like this will be unfair to those that have already submitted, however at the time of writing the backend code is on version 1.16, which includes bug fixes and new API functions for both the board and the timer, which already puts early submissions at a significant disadvantage. Multiple submissions could also be permitted, with only the latest submission used in the final event. This would allow everyone to take full advantage of any further updates to the codebase.
Given that a lack of increment could seriously affect the tournament integrity (if single games or very small matches are played between engines), especially as all engines are beholden to the unpredictable .NET runtime, there is a good case for the inclusion of increment in the tournament as a whole.