Here's a suggestion (from Bob):
Let's get HGM into this discussion, and anyone else interested, and let's fix this once and for all. I still like the idea of extending the current:
protocol version 2:
move Rh7+
to
protocol version 3:
move Rh7+ draw
The GUI can interpret that in two ways.
(1) if, after the move Rh7+, the rules of chess allow this game to be terminated as a draw, then the GUI does so instantly and the game ends.
(2) if, after the move Rh7+, the rules of chess do not allow this game to be terminated as a draw due to rule, then the GUI forwards this as a draw offer to the opponent which he can accept or decline as he sees fit.
There is more to it, in that it would be nice to have well-defined rules for offering a draw / claiming a draw, as well as accepting a draw or declining same. I'm not hung up on any particular implementation, as I should be able to deal with anything we all agree to. And finally closing this loophole would certainly be a good thing.
Another interesting idea would be to add the "hit clock" to the protocol. Then, until the program sends "hit clock" the opponent is not told anything at all, and now the GUI can see both the draw command and the move that supposedly produces the draw, without any fear of the opponent slipping in a move since he can't move until the other side "hits the clock button".
This extra message is a bit messy for fast games, but it would be most like real chess. The GUI temporarily has both clocks stopped while evaluating the draw claim, then starts the opponent's clock after shipping the move over.
I agree with Bob's suggestions.
Now tell us your opinion.
Here's a suggestion (from Bob):
Let's get HGM into this discussion, and anyone else interested, and let's fix this once and for all. I still like the idea of extending the current:
protocol version 2:
move Rh7+
to
protocol version 3:
move Rh7+ draw
The GUI can interpret that in two ways.
(1) if, after the move Rh7+, the rules of chess allow this game to be terminated as a draw, then the GUI does so instantly and the game ends.
(2) if, after the move Rh7+, the rules of chess do not allow this game to be terminated as a draw due to rule, then the GUI forwards this as a draw offer to the opponent which he can accept or decline as he sees fit.
There is more to it, in that it would be nice to have well-defined rules for offering a draw / claiming a draw, as well as accepting a draw or declining same. I'm not hung up on any particular implementation, as I should be able to deal with anything we all agree to. And finally closing this loophole would certainly be a good thing.
Another interesting idea would be to add the "hit clock" to the protocol. Then, until the program sends "hit clock" the opponent is not told anything at all, and now the GUI can see both the draw command and the move that supposedly produces the draw, without any fear of the opponent slipping in a move since he can't move until the other side "hits the clock button".
This extra message is a bit messy for fast games, but it would be most like real chess. The GUI temporarily has both clocks stopped while evaluating the draw claim, then starts the opponent's clock after shipping the move over.
I agree with Bob's suggestions.
Now tell us your opinion.
Matthias.
Another suggestion that was made and which might be better for backward compatibility is to change the above to something else such as
drawclaim move
this means that I want to either claim that the position is a draw by 50 move or whatever after my move, or claim that the position is a draw before my move. We might debate how that should be done in a more concrete form, but perhaps as Miguel said, doing a new command is better for backward compatibility than overloading an old one. This way we don't even need to discuss a protocol version 3, since the program is responsible for generating this stuff anyway. If it uses the new command, the GUI will know what to do, if not, then nothing changes and everyone should be happy.
CThinker wrote:The current xboard protocol already has the "offer draw" command that can be sent from the engine to the UI. Is this not enough?
I think that the distinction is a claim for "forced draw" rather than an offer of a draw.
E.g. what if the opponent says "No." and you have passed 50 full moves or repeated the position 3 times.
I think this command is sufficient. The UI just has to "interpret" this command as a draw "claim" (and not just an "offer") if the 50-move rule or the threefold repetition has been reached.
CThinker wrote:The current xboard protocol already has the "offer draw" command that can be sent from the engine to the UI. Is this not enough?
I think that the distinction is a claim for "forced draw" rather than an offer of a draw.
E.g. what if the opponent says "No." and you have passed 50 full moves or repeated the position 3 times.
I think this command is sufficient. The UI just has to "interpret" this command as a draw "claim" (and not just an "offer") if the 50-move rule or the threefold repetition has been reached.
And btw, even with the ICS protocol, there is only one command for a draw offer and a draw claim. Its interpretation is just based on the state of the game. If the there is a 3-fold rep or 50-move, then its a draw claim, else its a draw offer.
I> ***** DRAW *****
I> Command : draw
I> Examples: "draw" -- offers or claims a draw in your current game
I> "draw Joe" -- offers a draw in your adjourned game with Joe
I> This command ends the game in a draw if any of the following conditions
I> are true:
I> * Your opponent offered you a draw and you have not moved since then.
I> * The current position has occurred at least twice before. Everything
I> must be EXACTLY the same, including the person to move, castling
I> privileges, en passant possibilites, etc.
I> * The last 50 moves (50 moves for each person) do not contain any
I> captures or pawn moves.
I> If none of these conditions hold, then the command offers a draw to the
I> opponent.
CThinker wrote:The current xboard protocol already has the "offer draw" command that can be sent from the engine to the UI. Is this not enough?
I think that the distinction is a claim for "forced draw" rather than an offer of a draw.
E.g. what if the opponent says "No." and you have passed 50 full moves or repeated the position 3 times.
I think this command is sufficient. The UI just has to "interpret" this command as a draw "claim" (and not just an "offer") if the 50-move rule or the threefold repetition has been reached.
The fact is that it is not documented properly and everybody does things differently. So, trying to convince everybody to set a new interpretation of a command it is not going to work.
This was ill conceived from the beginning. It is not a good idea to have one command that does two different things. Claiming a draw and offering one are two different operations. In addition, one is addressing the arbiter and the other the opponent. splitting a claim and an offer into two different commands would make things clear for everybody and even easier to execute for GUI writers.
CThinker wrote:The current xboard protocol already has the "offer draw" command that can be sent from the engine to the UI. Is this not enough?
I think that the distinction is a claim for "forced draw" rather than an offer of a draw.
E.g. what if the opponent says "No." and you have passed 50 full moves or repeated the position 3 times.
I think this command is sufficient. The UI just has to "interpret" this command as a draw "claim" (and not just an "offer") if the 50-move rule or the threefold repetition has been reached.
And btw, even with the ICS protocol, there is only one command for a draw offer and a draw claim. Its interpretation is just based on the state of the game. If the there is a 3-fold rep or 50-move, then its a draw claim, else its a draw offer.
I> ***** DRAW *****
I> Command : draw
I> Examples: "draw" -- offers or claims a draw in your current game
I> "draw Joe" -- offers a draw in your adjourned game with Joe
I> This command ends the game in a draw if any of the following conditions
I> are true:
I> * Your opponent offered you a draw and you have not moved since then.
I> * The current position has occurred at least twice before. Everything
I> must be EXACTLY the same, including the person to move, castling
I> privileges, en passant possibilites, etc.
I> * The last 50 moves (50 moves for each person) do not contain any
I> captures or pawn moves.
I> If none of these conditions hold, then the command offers a draw to the
I> opponent.
I think everyone's aware of that. The problem is in the xboard/winboard protocol, where you offer/claim a draw independently of the move. You can claim a draw before you move, or after you move. If you claim it after you move, then there is a problem with the race condition I mentioned. It would be better to directly address this rather than depending on the GUI.
