WinBoard, exotic version

[hgm]

It depends on if you want WinBoard to help the user play the game. But normally this is not the task of a GUI. I admit that I have added a mode that indicates the legal moves of the picked-up piece (the /showTargetsquares option). Most ICS already consider this cheating, so I have switched it off in ICS mode to prevent ICS operators from blacklisting WB as client. But it goes in the direction of what you propose.



Existing WB protocol is well capable to ensure that only legal moves are played, though. Just let the engine send "Illegal move" in reply to any move that is not legal, and WB will refuse it.

I think it can be required from a user to know what moves are legal. To prepare for a situation where he first enters a few legs of the move, and then is at a loss how to continue, and needs the engine's help for it, seems pretty far-fetched. There are not that many multi-leg games in the first place.

It would be feasible to have WB send some info message to the engine when the display state changes (by the user picking up or putting down a piece). This should then be optional, though; the opponent can be an engine, which does not operate the display at all, and which does not need the feedback.

Say there were commands lift and put, sent to the engine with a square. The engine can then feed any text info it wants (including move lists) to the user through the Engine-Output window in response to such events. We could furthermore add an engine->GUI command highlight, which sends a FEN of color codes for squares the engine wants marked (and stay marked until the next lift or put event), so it can implement its own /showTargetSquares option when legality checking is off. E.g in response to lift i1 in the position shown above, the engine would send

highlight 9/9/9/8r/8y/8y/8y/8y/1ryy1yyy1/8y

to cause the display of the red and yellow markers.

[Daniel Shawul]

It depends on if you want WinBoard to help the user play the game. But normally this is not the task of a GUI. I admit that I have added a mode that indicates the legal moves of the picked-up piece (the /showTargetsquares option). Most ICS already consider this cheating, so I have switched it off in ICS mode to prevent ICS operators from blacklisting WB as client. But it goes in the direction of what you propose.

Yes alien mode works exactly like ICS. While trying to write a bot on ics, at first I did not realized fics rejects illegal moves and then gives me a chance to make a legal move. So for a human, I was thinking of loading a "referee" engine when being in alien mode. The referee engine sends the "setup ...." after every move.

Code: Select all

setup (PNBRQ................Kpnbrq................k) 8x8+0 rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0

So we can attach the movelist or other additional information the engine wants to send following that. All we are doing is leaving the door open for future extension without adding a new command. Pretty much like "style 12" on fics.

Playing human vs engine (without ics's illegal move rejection help), I had some difficulties regarding the "time otim move go" are sent in one bundle. So the engine will send an "Illegal move" first but then it will go on searching ... Infact it actually searches for the oppoent and makes a move! To prevent this the GUI has to _wait_ before sending "go" just incase the engine rejects the move. In alien mode, the GUI is supposed to be completely dumb about the game being played (not checkers btw since that has become known variant). So it relays moves from the user to then engine, and tells the engine to go searching. When an ICS is used, the ICS knows the rules so that is different. Does winboard always wait before sending go ?

Say there were commands lift and put, sent to the engine with a square. The engine can then feed any text info it wants (including move lists) to the user through the Engine-Output window in response to such events. We could furthermore add an engine->GUI command highlight, which sends a FEN of color codes for squares the engine wants marked (and stay marked until the next lift or put event), so it can implement its own /showTargetSquares option when legality checking is off. E.g in response to lift i1 in the position shown above, the engine would send

highlight 9/9/9/8r/8y/8y/8y/8y/1ryy1yyy1/8y

to cause the display of the red and yellow markers.

I think we can achieve this without adding new features just by extending the setup command the engine already sends. Say we agree to append the setup command after the FEN by.

Code: Select all

[total number of moves] [the move list separated by white space] [EOL]

then it can do the the move list processing I mentioned above. I am sure we can devise to send the highlight scheme similarily. Asking the engine to send information could be a little awkward as it could be in ponder mode searching. I think using the "setup " of alien mode of winboard as the "style 12" of ics to cramp as many info as we could is a good way.

[hgm]

Playing human vs engine (without ics's illegal move rejection help), I had some difficulties regarding the "time otim move go" are sent in one bundle. So the engine will send an "Illegal move" first but then it will go on searching ... Infact it actually searches for the oppoent and makes a move! To prevent this the GUI has to _wait_ before sending "go" just incase the engine rejects the move. In alien mode, the GUI is supposed to be completely dumb about the game being played (not checkers btw since that has become known variant). So it relays moves from the user to then engine, and tells the engine to go searching. When an ICS is used, the ICS knows the rules so that is different. Does winboard always wait before sending go ?

Hmm, you might have put your finger on a sore spot in WB protocol. I guess it is necessary to precede a go with a ping, so you can be sure that all moves have been accepted. (Or stil better: use playother before the move.)

I think we can achieve this without adding new features just by extending the setup command the engine already sends. Say we agree to append the setup command after the FEN by.

Code: Select all

[total number of moves] [the move list separated by white space] [EOL]

then it can do the the move list processing I mentioned above. I am sure we can devise to send the highlight scheme similarily. Asking the engine to send information could be a little awkward as it could be in ponder mode searching. I think using the "setup " of alien mode of winboard as the "style 12" of ics to cramp as many info as we could is a good way.

I still don't like that idea very much. Move lists can be arbitrary long (e.g. Amazons, Arimaa). When the opponent is an engine, sending them would serve no purpose. So the engine would have to know the nature of its opponent, and adapt the protocol to it. It is also not clear how you would use a move list to generate board markers (e.g. look at the different behavior of /showTargetSquares in suicide w.r.t. other variants). In Checkers you could for instance let it put a red dot on every opponent disk that has to be taken. WinBoard would never be able to get that idea (to mark d5 and b3) from e6c4,c4a2 being present in any move list.

[Daniel Shawul]

Hmm, you might have put your finger on a sore spot in WB protocol. I guess it is necessary to precede a go with a ping, so you can be sure that all moves have been accepted. (Or stil better: use playother before the move.)

Yes that should work fine for engines supporting version 2 of the protocol. But currently I have none of those ,well time to go to work. And you should also make ping/playother the definite way of communication when in alien mode. The go text protocol forces you to send a "=" after every command you recive, which is sort of like a pong to the GUI. Now I know why..

I still don't like that idea very much. Move lists can be arbitrary long (e.g. Amazons, Arimaa). When the opponent is an engine, sending them would serve no purpose. So the engine would have to know the nature of its opponent, and adapt the protocol to it. It is also not clear how you would use a move list to generate board markers (e.g. look at the different behavior of /showTargetSquares in suicide w.r.t. other variants). In Checkers you could for instance let it put a red dot on every opponent disk that has to be taken. WinBoard would never be able to get that idea (to mark d5 and b3) from e6c4,c4a2 being present in any move list.

Ok for markers, we can send f.i for chess, maximum 16 fens of color codes along with the setup. This could really be short if we represent them with bitboards. Two attack maps for captures and non-captures separate therefore 32 bitboards (64 ints) total. That is only a bit larger than most FENs
However if we think of other alien games, there may not be such attack map. All you can be sure is that there is going to be some action (move) for the game to progress, so sending that plain information seems natural. Take Arimaa for instance, 4 simple legs of four different pieces can make one single move of the human. And that acompained by pushing pulling and trapping of pieces. There is no way attack maps help here but if I have the list of moves , it can greatly help the human making a move. I agree the move list could be too long sometimes, but there is no _common_ theme for all alien games other than this action. Attack maps don't cover all.

[Rein Halbersma]

I think it can be required from a user to know what moves are legal. To prepare for a situation where he first enters a few legs of the move, and then is at a loss how to continue, and needs the engine's help for it, seems pretty far-fetched. There are not that many multi-leg games in the first place.

In draughts/checkers, there can be multiple captures (with 6 or more pieces being taken in a single move) that are quite complicated to see even for experienced players. In any case, it would be nice if multi-leg moves could be entered by clicking on the intermediate squares only once. So for a e4c6, c6a4 capture, it would be nice just to click on e4c6a4. Or better yet, just to click e4a4, and let the engine decide whether this is the only unique move. Or is this at odds with what is to be expected from an engine?

[hgm]

In draughts/checkers, there can be multiple captures (with 6 or more pieces being taken in a single move) that are quite complicated to see even for experienced players.

This is why I proposed to have something similar to the /showTargetSquares option that WinBoard offers when legality checking is on. In normal Chess variants I let it indicate non-capture target squares of the lifted piece by a yellow dot, and capture target squares (which in Chess of course coincide with the captured piece) with red dots. But in suicide variants, where (like in draughts) capturing is mandatory, this distinction is not useful, as you will either have no captures, or, when you do have captures, no non-captures. So in the latter case I used the yellow dots not for indicating non-captures, but for indicating target squares of captures by other pieces than the lifted one. So that when you accidentally overlook a capture, and lift a piece that can only perform non-captures, the computer points out the capture.

I figure for Draughts you would need something similar to the latter, like indicating the pieces that can be played when you lift one that cannot be played, and indicating the squares you have to visit, or the pieces you can capture, or both, when you do lift a piece that you can legally move. Perhaps the first square you have to visit in red, and the square you have to end on in yellow. Anyway, something quite complex and game specific. But in a GUI that does no know the game rules, the only agent that can decide about this is the engine. Hence my proposal for the lift / put / highlight protocol, to make this generally possible for engines.

In any case, it would be nice if multi-leg moves could be entered by clicking on the intermediate squares only once. So for a e4c6, c6a4 capture, it would be nice just to click on e4c6a4.

I agree this would be nice, but it is also a bit of a problem. Because how is the GUI to know that the next leg will necessarily start with the same piece as the previous one? In Arimaa, for instance, this will not be the case. (And neither in Chess variants for non-standard castlings.)

I guess a good general solution would be to leave the piece that moved in the first leg selected (if Ctrl was pressed to indicate there will be a follow-up leg). Then a click on an empty square or enemy piece will be interpreted as the to-square of the second leg. A click on a new own piece, OTOH, would deselect the piece of the previous leg, and select the new one (possibly allowing you to drag it). So you could perform a Draughts multi-capture by pressing Ctrl, performing the first leg (by click-click or drag-drop, as you please), and then the remaining legs by clicking the other squares to visit. That sounds like a good general solution.

Or better yet, just to click e4a4, and let the engine decide whether this is the only unique move. Or is this at odds with what is to be expected from an engine?

Well, this is a problem that led us to the complex multi-leg move entry in the first place. In general from- and to-square are not enough information to fully specify the move, in Draughts. There could be different paths between the same squares. Basically, what you ask is the equivalent of the /oneClickMove option in Chess, where a move is already done based on partial entry (either the from or the to square, if there is only a single legal move from or to it). In a general GUI completely devoid of game knowledge this might be asking a bit too much. Even in the very simpletwo-square case of Chess the usefulness of one-click moving is a controversial topic.

[hgm]

Yes that should work fine for engines supporting version 2 of the protocol. But currently I have none of those ,well time to go to work. And you should also make ping/playother the definite way of communication when in alien mode. The go text protocol forces you to send a "=" after every command you recive, which is sort of like a pong to the GUI. Now I know why..

Well, I guess there is a more general problem than just the 'go' command. If you load the engine with a game, in force mode, and the engine responds with 'Illegal move', you would actually have to figure out to which move this pertains. This should be possible, because WB protocol prescribes that the engine has to specify the offending move. (There could be ambiguity there, however; it would have been better if the engine had specified the move number.) I am not sure if WinBoard currently looks at this, though.

After identifying the offending move, the GUI might have to undo a lot. I guess that if this happens during loading of a game, the best course of action would be to let it refuse the entire game (reset the engine + GUI for a new game). If it happened after MOVE + go, the GUI can know that it has to 'undo' the go as well as the move. (I.e. send ? + force + undo to the engine to undo the move it will cough up in response to go, as well as take back the user move in the GUI.

So I guess existing protocol can handle it, but it does require careful implementation in the GUI.

[Daniel Shawul]

Ok if you prefer the lift/put/highlight method , we can test that first. I will implement sending list of squares to be highlighted, when I recieve the command. My worry with that method is that it could affect pondering badly. The human can just lift pieces and put them back here and there to interrupt the pondering. Infact IIRC Nebiyu will stop pondering if it gets a command other than "." while pondering, and probably other engines too. But I can fix that for this test, so that the engine processes lift command on the fly while pondering. This is easy for me because the search is done on a copy of the board at the root. It will not be easy for the GUI too as it has to synchronize quickly. At least for a remote engine it is difficult to work this way. Anyway I am willing to test this on Nebiyu if you have a specification ready to be implemented.

With the movelist method I was thinking of using regex to match pattern on the movelist string for each square user clicks. User can click the destination square first , and if there is only one move with that destination it is done automatically.

[Daniel Shawul]

After identifying the offending move, the GUI might have to undo a lot. I guess that if this happens during loading of a game, the best course of action would be to let it refuse the entire game (reset the engine + GUI for a new game). If it happened after MOVE + go, the GUI can know that it has to 'undo' the go as well as the move. (I.e. send ? + force + undo to the engine to undo the move it will cough up in response to go, as well as take back the user move in the GUI.

I like this one better since it works for older engines too. They should have ? and undo implemented. Another thing I observed while testing a multi-player (3 or more) game was that sending a move alone should not trigger the engine to play the other side automatically. Ofcourse now I know there is a new command "playother" in protocol 2 that fixes this problem. So to play in multi player mode the engine should always be in force mode when it gets a move, then explicitly told to 'go' afterwards after legality testing is done. I managed to play a 2 player chess using 3 or more engiens that way. But I know multi player games are not in the design of winboard and probably will complicates things unnecessarily.

[hgm]

Well, if the user wants to hinder pondering there are plenty of other ways to do it (the most effective of which would be to select "Ponder off" ). My engines also interrupt the ponder search on input, and then, if the input turns out not to be a move, try to pick it up again. This is not entirely satisfactory with a small hash table, as I noticed when I also tried to implement analysis that way, and the "." commands were interrupting the search all the time. It just did not get beyond a certain depth anymore. Too many hash entries for direct daughters of the PV were lost.

It should not be that difficult to put an input filter inside the search, that reads input without aborting it, and then filters out some commands for immediate processing (like "."), and put the rest in a buffer, so they will be processed after the search returns. Some of the commands, like "?" or a move that is a ponder miss, should trigger an abort, and then be processed after the return. I am still planning to adapt the example WinBoard driver I presented at WinBoard forum that way.

Engines that want to support the highlight feature would indeed be forced to make a copy of the board to work from. But that is the easy part.