WinBoard, exotic version

[Daniel Shawul]

This solves the problem of providing optical cues to theuser to help him pick his move. The equivalent of one-click moving is a different issue, though. If we want to make it possible for the engine to finish a move for the user, before the user is fully done entering it, perhaps we should add an engine->GUI command click SQUARE, that would cause the same event in the GUI as when the user clicked the mentioned square. (That is, up-click + down-click; the command should only be sent, and will only be accepted when the user does not have the mouse button pressed at the time.)

I think this can be done along with highlighting , atleast according to the current method I am using. Since I am looking at the legal move list at the root, I can answer legality when getting the put. Also if a piece is lifted and there is only one move, I can send f.i a "singlemove a3c5,c5a7" to tell winboard to make the move immediately.
Intermediate leg-moves can cause problems, but I am now heavily inclined towards dumping that completely, since the current scheme sounds much simpler.

EDIT Oh I get it. Click is equivalent to the "singlemove" I was talking about. I thought "click" is going to be sent by winboard
Well that is done then.

[Daniel Shawul]

I have improved WinBoard's handling of the click command. That command can now be given at any time. If the user happens to have the left button down, WinBoard will be aware of it, and first generates an up-click event on the same square as the user's down-click, before starting to process the click the engine sent (as another up+down). This means the engine can now safely issue a click command in response to the first lift, to implement one-click moving. I tested it in a Fairy-Max that was modified to answer click h4 to lift h2, and it plays h2h4 flawlessly when you down-click on h2. The stray upclick that occurs when the user releases the button afterwards is simply ignored.

Why click h4? wouldn't it be better to give the whole move click h2h4. In checkers, if there is one multiple leg capture, the first lift will identify it so
click a3c5,c5e7 f.i. We will resolve it through live talk tommorrow , the implementation is done anyway.

About the ILLEGALMOVE + go problem:

Is this really a problem? In user-engine games, when the machine has white, it is sent a go without first getting a move. And when it has black, it is already set to play black after new, and will not receive any go. Just a move.

I know it is a problem with multi-player games and 2 player games in human vs human which wouldn't have any legality testing anyway because of absence of engine. Which reminds me of an idea I had about loading a "referee engine". I seriously considered doing that for the multi-player games since I have to make sure the move is legal before sending it to an engine , which otherwise would reject the illegal move first and then go searching.

I will check how winboard behaves currently.

[Daniel Shawul]

I checked and winboard does not have problem since it doesn't send go after each move. But for multi player games I had to use a force-go combination at every move since the order is not fixed and could change if one of the players looses, or even when you want to play with regular 2 player chess engines taking turns for the same side. In that case the engine has to always be in force mode. Btw I actually did implement this using a java console tournament manager that can match humans vs engines vs IcsServer. Round robin pairings and even alternating colors is not trivial and infact becomes challenging to determine the Nth pairing without pre-calculating the whole game-set-match.
When IcsServer is included, it becomes the tourney manager, so the console tourney manager becomes a slave to it. It only switches engines between moves. 4 engiens can play a single game on FICS This is crazy I know, but I got carried away..

Do you have plans to support multi-player games? It seems very interesting and also more practical (non-zero sum multi-player games have applications in economics.). I want to implement atleast one game to satisfy my curosity, but it won't be a good player because the game theory is not that well developed. Existence of winning strategy (nash equilibrium) is only proven very recently i think.

[hgm]

Ok. The reason I asked about it was because to handle partial moves (legs) of a move, I have to first make that move on the root board which should be legal. If the leg move involves a capture , the piece is removed f.i

You are aware that in international Draughts ths is not a fail-safe procedure, because a multi-capture with a Queen is not allowed to pass a second time over a square where it already captured something?

You mean reserve one color to indicate legal destination square ? That should work. It might even be better to refuse the partial move when the first leg move made by user is illegal i.e Engine sends "Illegal leg move" on recieving a put command. Making an illegal move and generating highlight FEN could be difficult for the engine.

Well, I guess that after getting an illegal leg, the engine should simply refrain from sending any hghlights. Just wait for the total move,and reply with "Ilegal move" to that.

Aborting partially entered moves is still not implemented in WinBoard. I guess if there would be a mechanism to do this (like typing <Esc>), it would raise the ptoblem how to communicate that to the engine, so that it knows the next 'lift' will be for the first leg from the original position, rather than for the next leg. It seems we would need a new GUI->engine command for that. Or use a 'put' without square as a way to finish a move-entry in an invalid way.

I haven't yet understood the click command but it seems the move legality and fast move making is handled there ,right ?

No, the click command has nothing to do with legality checking. It just allows the engine to finish moves on behalf of the user.

[hgm]

Why click h4? wouldn't it be better to give the whole move click h2h4. In checkers, if there is one multiple leg capture, the first lift will identify it so
click a3c5,c5e7 f.i. We will resolve it through live talk tommorrow , the implementation is done anyway.

Well, why not

GUI: lift a3
engine: click c5
engine: click e7

? It seems equivalent to me, and the latter was easier to parse.

I know it is a problem with multi-player games and 2 player games in human vs human which wouldn't have any legality testing anyway because of absence of engine. Which reminds me of an idea I had about loading a "referee engine".

But this is exactly how WinBoard works already: homan-vs-human is called Edit Game, and the first engine plays the role of reference engine in that mode.

I seriously considered doing that for the multi-player games since I have to make sure the move is legal before sending it to an engine , which otherwise would reject the illegal move first and then go searching.

I will check how winboard behaves currently.

I don't get is. In Human-Human there is no one to send 'go' to. I agree that in a three-player game, when the engine is set by default to play blue, and when you want it to play green, you would have to send it move + go after red has made its (possibly illegal) move. I still think this is for the GUI to solve. Using 'playother'+ move in stead of move + 'go' would solve it. For multi-player games 'playother' could be generalized to mean 'playnext'.

[hgm]

But for multi player games I had to use a force-go combination at every move since the order is not fixed and could change if one of the players looses, or even when you want to play with regular 2 player chess engines taking turns for the same side. In that case the engine has to always be in force mode.

I also don't get this. If it is not clear who's turn it is next, how can a GUI that has no knowledge of the game rules now it? It cannot possibly know which of the players to send the 'go' to. If anyone knows who is to move next, it must be the engine. So the engines might as well move spontaneously when its turn comes up.

[Daniel Shawul]

I also don't get this. If it is not clear who's turn it is next, how can a GUI that has no knowledge of the game rules now it? It cannot possibly know which of the players to send the 'go' to. If anyone knows who is to move next, it must be the engine. So the engines might as well move spontaneously when its turn comes up.

I am sorry HG but you are being deliberately difficult. Answer me this then.

Scorpio (an old engine) which knows about the colors white and black only wants to play in 4-player
player game. It gets to move only once in four moves. If I don't put it in force mode it will move
immediately after every second move. But it needs to be updated what moves are being made even when it is
not its turn.

eg. Scorpio & Nebiyu vs fairymax & spartacus

1.Scorpio
2.fairy
3.Nebiyu
4.Spartacus

Now you can assign 4 colors to each engine, and tell it to move when its color comes up.

But winboard has only white and black, so what I did is to force all of them in force mode
and tell them to GO when it is its turn.
If for some reason (e.g disconnection) one of the players do not want to participate, his partner can be told to make
the moves on his behalf.

In a real three player chess game f.i
1.Scorpi0
2. fairy
3. oberon

If Scorpio resigns on the 50th move, fairy and oberon can continue playing to determine the winner.
Ok you can let them know of the colors have changed once scorpio is out, and tell them to readjust
when they are going to move. This is awkward for the engine. The GUI is better at handling this.

It is fine if you don't think so , but surely Winboard can't handle it at its _current_ state period.
You have to add more colors first and then also inform engines when their color changes. That is one way
of doing it , I agree.
But i find the force mode more efficient since it works with _old_ engines. I can play with all engiens using the force mode method.

Please look at what I wrote above carefully before posting mutliple disagreements on the same topic.

[Daniel Shawul]

Well, why not

GUI: lift a3
engine: click c5
engine: click e7

? It seems equivalent to me, and the latter was easier to parse.

Ok. It is just a question?! I thought maybe it was handled leg by leg, so that I will send the second click when I get a second lift. If the two consecutive clicks are equivalent to click c5e7, then it is poteto potato

[hgm]

Scorpio (an old engine) which knows about the colors white and black only wants to play in 4-player
player game.

Ah, OK, I see what you want now. Come to think of it, it is actually not so different from WinBoard using GUI book. There you also force in moves for the side the engine is playing. This is a bit like the engines are alternating as each other's book.

But of course engines are not very likely to do illegal moves. And Chess is not a problem, because WinBoard knows the rules of that. So we are really talking only about 'old' engines for games that WinBoard has no clue of the rules. Those cannot be very abundant...

I still think the logical solution is to let the GUI undo also any 'go' commands it has sent. But considering how cumbersome this is, I don't think it very unreasonable to require from engines that play games that WinBoard does not understand enough to check legality of their moves to implement 'playother'. The move+go protocol is basicaly flawed. The playother+move protocol does not suffer from the same problems,and should be considered superior. So when engines do support playother, WinBoard should really use that,and avoid move+go.

Btw, I just uploaded a version that uses the highlight command for legality checking. (Don't throw away your old winboard.exe, though, as I hardly tested is, for lack of an engine that does such highighting.) The way it worksis like this:
1) When a 'lift' command is sent, WinBoard marks all squares of the board as legal to-squares.
2) When a 'highlight' command is reiceved, Winboard overwrites these markers, only leaving the squares indicated in the 'highlight' command as legal to-squares, and marking all others as illegal.
3) When a to-square event occurs (which would normally trigger a 'put'), it is checked if that to-square was marked as legal. If not, the event is ignored (so you can click another to-square), and a message displayed above the board.

Please tell me if this works satisfactorily.

[Daniel Shawul]

Ah, OK, I see what you want now. Come to think of it, it is actually not so different from WinBoard using GUI book. There you also force in moves for the side the engine is playing. This is a bit like the engines are alternating as each other's book.

But of course engines are not very likely to do illegal moves. And Chess is not a problem, because WinBoard knows the rules of that. So we are really talking only about 'old' engines for games that WinBoard has no clue of the rules. Those cannot be very abundant...

I still think the logical solution is to let the GUI undo also any 'go' commands it has sent. But considering how cumbersome this is, I don't think it very unreasonable to require from engines that play games that WinBoard does not understand enough to check legality of their moves to implement 'playother'. The move+go protocol is basicaly flawed. The playother+move protocol does not suffer from the same problems,and should be considered superior. So when engines do support playother, WinBoard should really use that,and avoid move+go.

Yes I agree. The multi player situation was a casual suggestion and it is not necessary.

Btw, I just uploaded a version that uses the highlight command for legality checking. (Don't throw away your old winboard.exe, though, as I hardly tested is, for lack of an engine that does such highighting.) The way it worksis like this:
1) When a 'lift' command is sent, WinBoard marks all squares of the board as legal to-squares.
2) When a 'highlight' command is reiceved, Winboard overwrites these markers, only leaving the squares indicated in the 'highlight' command as legal to-squares, and marking all others as illegal.
3) When a to-square event occurs (which would normally trigger a 'put'), it is checked if that to-square was marked as legal. If not, the event is ignored (so you can click another to-square), and a message displayed above the board.

Please tell me if this works satisfactorily.

Ok let me implement it and see if I get problems. I still haven't decided how to handle highlighting of multiple leg moves. Currently for checker-captures I just highlight all "to squares" with red.
It is there that I expect to see some problems if any.