# Why don't chess engines take into account the time left by each player?

Firstly, I am not suggesting that there is anything wrong the way engines are implemented at the moment, by analyzing only the current position regardless of time left by the players. This is great and it gives us a nearly perfect estimation of the position.

To the best of my knowledge, current engines do not take into account the time left by the players in a game when analyzing a position.

When I am watching an online transmission of a chess championship match, when the players get low on time it is very common for commentators to state "Ohh, I don't think <player> will find this move with only 10 seconds on the clock!", when there's only one move in the position that it is really hard to find (hence would require more thinking time that they do not have). Maybe I am on the minority here, but I think it would be interesting to have a separate evaluation by an engine that takes into account the time left.

My questions are: Is there such an evaluation out there? Are there any downsides when taking into account time or something that makes this calculation impossible to do?

• The question is unclear: How would time left on the clock influence the evaluation? Commented Nov 14, 2022 at 14:07
• I think it's pretty clear as per my example in the third paragraph. An engine that follows my suggestion would not give a big winning score if the player is low on time and the winning patern is hard to find. On the other hand, a "regular" engine would just show a score of +10 (for example) disregarding these conditions I talked about previously. Commented Nov 14, 2022 at 17:09
• One could calculate a probability for 1-0, ½-½ and 0-1. But the evaluation of the position would stay the same anyway because it's simply independent of the clock situation. Commented Nov 14, 2022 at 17:27
• In my question I'm playing a "what if" game, what if engines (or an on-off parameter of it) take clock into consideration. I know an evaluation of a chess position is independent of the time left. We have seen players screw up a winning position when low on time so it is obvious time left plays a huge part in a game between humans. I was wondering about an engine that would consider that. Commented Nov 14, 2022 at 17:32
• @ihavenoidea Engines generally have no idea how hard a move is for a human to find. You could imagine some metric looking at the distribution of evaluation changes for all possible moves (naively if there's only one good move, you might guess it's harder to spot), but you can probably think of a lot of counterexamples to that pretty easily (obvious mates in 1 for example). Commented Nov 14, 2022 at 19:49

I imagine someone could go through a bunch of GM games that have time information included and do some sort of statistical analysis to correlate time with win probability for a given evaluation. It could never be perfect, but neither are traditional engine evaluations or ratings or anything else you'd use to predict the outcome of a game.

But to make it reasonably accurate you'd also have to account for things like player strengths and material left on the board and known-drawn positions (a 0.0 evaluation coming out of a nonstandard opening and a 0.0 evaluation in an opposite-colored-bishops endgame with one pawn on each side are very different when it comes to win probability.) You'd probably want to check whether there's one narrow path to victory or multiple moves which could all do the job. You might also have to account for things like whether it's OTB or online; 10 seconds left to convert a won position when you have to physically hit a clock is way different from when you can use a mouse and can premove.

It's mostly a question of whether someone is willing to put forth the effort to do all of this. Exactly how badly do we want to know the odds of one imperfect human beating another in a given situation?

• I'd suggestthat it could make a useful study tool. If I'm in a won position with 5 seconds left, it may be that stockfish finds a really nice mate in 4 that is hard to find, but I would pre-move the very simple and obvious mate in 18 ladder. I'd argue that I made the correct choice, but if I had 1 minute left I'd spend 30 seconds finding the mate in 4 Commented Nov 14, 2022 at 11:15
• This is the type of discussion I was looking for :) Commented Nov 14, 2022 at 17:19
• This is what I was thinking about when I wrote this question. In earlier versions of Alphazero where the learning was supervised (learning from a dataset), since the clock is generally an information we have stored, I thought that feeding the network with the clock information would then inherently have what I had in mind in my original question (take time into consideration). However, since mostly all strong engines today use a selfplay approach for learning, I'm afraid it is impossible to use clock time since engines play moves infinitely faster than humans (continued) Commented Nov 14, 2022 at 17:25
• ...since engines play moves infinitely faster than human, using them to evaluate positions played by humans wouldn't make sense. Commented Nov 14, 2022 at 17:26
• Yeah, selfplay doesn't seem like it would be useful if you're trying to determine "how will the humans play" rather than "what's the best move".
– D M
Commented Nov 14, 2022 at 23:29

Why don't chess engines take into account the time left by each player?

For the simple reason that there is no way of knowing how to do that.

A few years ago a clubmate rated about 1800 playing in the British Universities blitz (3+2) championships reached a KNB v K endgame. He knew the endgame and so blitzed out the win. I have other clubmates rated 2100+ who don't know that endgame and would not be able to checkmate in such period of time. Give them 20 minutes on the clock and they still might not succeed. There have been cases of IMs failing to do this at regular time controls.

In short it is an impossible task.

• "no way of knowing how to do that" Umm, In games between engines, the evaluation tend to zero. But between engine and persons, I believe that the engine's best play is the move that demands more precision to support the position or gain an advantage. Its the style, "introduce complications". This style of game will be more effective when the person lacks enough time to think. Commented Nov 16, 2022 at 6:09
• @djnavas Engines aren't always good at dealing with complications, either. Commented Nov 16, 2022 at 22:57

Because engines find the best move by assuming best play, not by hoping their opponent makes an inferior move.

If you constructed an engine whose sole purpose was to beat a specific person/engine, then "likelihood to play a given bad move" could make sense as an evaluation parameter. But otherwise it's a waste of time to calculate something that would ultimately lead to the engine playing weaker moves.

• One might conceivably come up with a metric how hard it is to find that best move in a given time. One simple way to do that is to let the engine itself compare e.g. a static evaluation vs. the result of a regular n-ply search, while taking into account the number of moves retaining most of the equity ("OK moves", including the correct one) vs. "wrong" moves. I think there is a consensus that positions that have only one correct move are hard, especially if that move isn't obvious (e.g. detected by a static eval). Finding it may take time or genius. Commented Nov 14, 2022 at 11:00
• +1 correct answer. Commented Nov 14, 2022 at 11:38
• This is not 100% percent true, actually there is something called "contempt factor" which allows a bias toward assumed weaker players. See chessprogramming.org/Contempt_Factor Commented Nov 14, 2022 at 15:24
• @CaptainCodeman: Contempt is more about whether the engine should avoid (early) draws in an even position, not about whether the opponent will see the only good move. No reasonable engine should accept a draw when the evaluation is +5 in its favor, regardless of the contempt factor (within reason... I imagine there's some way of misconfiguring an engine so that it will behave in such a way, but that's not a "reasonable engine" anymore). Commented Nov 15, 2022 at 0:07
• When I played competitively, we analyzed the games of my upcoming opponents, in order to find out which play styles they are good in and and in which ones are they more likely to make weaker moves. Tailoring gameplay for a specific opponent is not unheard of.
– vsz
Commented Nov 15, 2022 at 5:11

This is an exposition of BlueRaja - Danny Pflughoeft's answer, which is correct. Given the option between making 1) the objectively strongest move and 2) the one against which the best move is "really hard to find", would you really rather an engine make move #2?

Let's say you make move #2. If opponent doesn't find it, congrats, you win. If opponent does - then what? Did you just throw away your winning chances? Did you just go from losing to lost? If the answer to either of the above is "yes", not only should an engine not make that move, a human should not make that move either!

Example:

``````[FEN "3r2k1/2pqnpp1/1p5p/p2P4/P2p1rP1/2P1N3/1PQ2PP1/3RR1K1 w - - 0 1"]

1. g3 dxe3 2. gxf4 Qxg4+
``````

This position is from Nepomniatchi-Carlsen, World Chess Championship 2021. It is dead equal - 0.00 eval according to Stockfish. Stockfish's main line begins with 1. Rxd4 and leads to a draw. However, Nepo played 1. g3. Now when a piece comes under attack, the first inclination is to move it. Accordingly, the first move Carlsen is likely to look at is 1...Rf6. Look a bit further though, and Black will notice that 1...dxe3 wins (since 2. gxf4? Qxg4+ followed by a rook lift is a decisive attack).

Would you really rather an engine play 1. g3 instead of 1. Rxd4? Phrased alternatively, would you rather get a sure draw, or a "maybe" win that is a guaranteed loss if opponent sees the key move? Think about it. Nobody - engine or human - should prefer the latter.

That said: engines do have a measure of how complex the current position is. If the engine believes it is stronger than its opponent, then it will try to steer the game towards more complex positions. Inferior opposition is more likely to blunder in those positions. That's how engines exploit their opponents.

• It doesn't have to be about what the engine plays but what it communicates to us humans. Personally I would think it would be pretty cool if an engine could rate the best line not just in centipawns but also provide some rating how hard this is to find for a human. There could be a lot of educational use in that. Commented Nov 14, 2022 at 13:31
• If one is using a computer as a sparring partner, having it occasionally make sub-optimal moves may be a useful form of practice. At rapid time controls, even games between top-tier players will often feature multiple mistakes which could have changed the result by a half point if exploited, but which weren't noticed until post-game analysis. Thus, an ability to exploit mistakes may be an extremely valuable skill, but one which couldn't be practiced very well if one only took on "perfect" opponents. Commented Nov 14, 2022 at 21:01
• So "Don't set traps" and "Don't play 'hope chess'", then? Commented Nov 15, 2022 at 7:45
• @RosieF I think that's a nice way of putting it. If you make an objectively inferior move hoping that the opponent will not spot it because of their time situation, then it's hope chess and it's something chess trainers try to dissuade their students from. It doesn't mean you shouldn't set traps, but it does mean that you should assume your opponent will see the trap and avoid it, in which case your move is still good. Commented Nov 15, 2022 at 7:51
• If a move is good (even if it isn't the best option), I'd say that it doesn't count as setting a trap. If your opponent then plays a move which enables you to get a position akin to your springing a trap, then what you did wasn't a trap, but punishing your opponent's blunder. Commented Nov 15, 2022 at 7:59

Stockfish has 'wtime' and 'btime' options, that get it to calculate as if white and black only have such and such time left. However, in cases you're mentioning where human players only have a few seconds to find a move, even here Stockfish would most likely find the move under these wtime & btime constraints.

Position evaluation by an engine is completely objective. Put any 2 players in a given position and the eval is the same. Once you add the clock into the equation the evaluation becomes different depending on who the player is. The objective evaluation becomes a subjective evaluation which no longer has any concrete meaning.

Let me chime in too. The OP's question is really two in one, which were conflated a bit in the discussion.

a) HOW can you implement it?

b) WHY should you implement it?

I see no reason why a) should be impossible. For example, the reknowned game-theory primer "Winning Ways..." gives a clear mathematical notion how "hot" a game is. You can come up with more metrics - the depth and with of the decision tree, how "easy" a winning move is etc. This will get very tricky and as always is probably easier done quick-and-dirty, but why not?

But I see a problem with b). What is the "use case" of doing all the work? Computer vs Computer? Surely not. Computer vs Human? Aw cmon, they annihilate you anyway :-) This leaves: training. I'm just reading the "Complete Chess Swindler", many games have been blundered in time trouble and someone like me who plays lightning fast will use it against you! Surely it can't hurt if you train finding the best move under time strain. But even in this case, I think pre-chosen positions are much more effective in training than random played games.

Thus my verdict is: Nice-to-have feature, but lousy ROI to make one doing the programming work.

• Perhaps b) as a complementary eval bar (in addition to the normal one) in live transmissions of events where an endgame is often 0.0 until it at some move mysteriously becomes won by one side, but that 0.0 was almost impossible to find even many moves before. Commented Nov 15, 2022 at 13:58
• For (b), imagine a platform that displays chess matches and allows spectators to bet on the match. The platform must automatically determine the odds. If a spectator bets before the match starts, the odds can be determined using the players' ELO ratings. But if a spectator bets once the match has already started, the odds should be computed by taking into account the ELO ratings, the position on the board, and the times on the clock.
– Stef
Commented Nov 15, 2022 at 14:59
• The other use case for (b) would be to find moves with good practical chances of turning a losing game around. If you're at the point where the best move is just the one that prolongs loss the longest, then a move that loses quicker but gives more opportunity for the opponent to make a critical mistake is the better option. A simple metric would be to look for moves where the second best move is much worse than the best move. This would only apply to human vs human of course, as engines will never blunder like that. Commented Nov 16, 2022 at 13:06
• Time trouble is often a factor in computer-versus-computer matches. If a computer which has more time per move, but is unlikely to win, has a choice between lines that involve simple positions where the opponent would have a slight advantage, or lines that involve much more complicated positions where the opponent would have a larger positional advantage, but having less time on the clock could be an offsetting disadvantage, exploiting the time difference would seem like it could realistically improve a computer's chances of winning or at least avoiding losing. Commented Nov 16, 2022 at 15:52

because it adds another variable which exponentially increases the number of calculations needed, so it wouldn't be able to calculate to as much of a depth as without it.

• Chess moves are already an exponential variable and there are various ways to cut the number of calculations down. So, I believe a constant calculation of time variable would not change the overall complexity, while it might give some information. Can you elaborate on what you claimed? Why do you think it would be a significant increase? Please edit and explain your answer as it looks more like a comment than an answer currently. Commented Nov 16, 2022 at 6:58
• @Minot except it's not a constant calculation, you would have to consider the time left in each position, for it to be worthwhile you would have to search to a deeper depth to check if the move might actually be bad and then consider that they don't have "enough time" (a variable which changes based on so many things and would be extremely hard to calculate) and then after all that you'd be making your move based on the lower depth. which just doesn't make sense, so given the extra calculation time, just spend it on searching to deeper depth and just make the more 'correct' move. Commented Nov 22, 2022 at 23:09
• maybe at most you could do it in the very late game as it's conceivable that given your opponent moving in the minimum time (usually 0.1 seconds?) there may be lines that are impossible to win from due to the time taken. Also at the late game with less pieces there's far less complexity so it's easier to incorporate. Commented Nov 22, 2022 at 23:11