WinBoard-Alien highlight protocol

[hgm]

I created a new version of WinBoard, Alien Edition, which assigns new functions to the highlight protocol:

In previous versions, the only color with a special meaning for highlighting squares was red (indicating capture), and the special treatment consisted of emission of the 'hover' command when the mouse pointer entered a thus-marked square, to give the engine opportunity to highlight the capture victims (in case they are on another square), e.g. in green.

This new version treats two other colors as special as well:

- Magenta (M in the color-FEN) can be used to indicate promotion, and forces the GUI to popup a promotion dialog (or activate the sweep promotion, when the user has set up that mode of promotion choice) when the piece is moved to such a square, even if the GUI would normally think that square is outside the promotion zone (or think the piece could not promote). In variant chu I even use it to decide on the popup within the zone, as Chu Shogi has complex rules for whether you are allowed to promote or not, depending on move history. I am not sure if it would be a good idea to extend this to all variants, as it would break backward compatibility (engines that would not use the magenta markers would no longer allow promotion), and appearence of an unnecessary promotion popup, although silly, is not a disaster.

- Cyan (C in the color-FEN) can be used to encode the first leg of a multi-leg move. Releasing the piece on such a square would behave as if the user had Ctrl pressed, i.e. suppress turn change, and prompt the user for the second leg. (In WinBoard this would leave the moved piece selected, and send the 'lift' command for it to the engine, so the engine can highlight possible second-leg destinations, and the user can just click on one of those to make the second leg with the same piece, without any need to grab it again. But that is an implementation matter.) This presents a potential problem, when both a single-step move to (A-B) and a multi-step move over (A-B-C) the square exist, as after moving the piece to B (highlighted in cyan) you would always be prompted for a second leg. A static click on the moved piece would terminate the move at that point, and send A-B to the engine.

This works very natural and intuitive (while the need to press Ctrl was sort of a disaster, very hard to get used to). In fact, with this mechanism there is very little reason to have a separate catch-all variant 'multi' for multi-move games. Multi-leg moves could very well be allowed in any variant, if the engine requests them by cyan highlighting. (But the Ctrl key should be ignored, then.) In multi-moves with several pieces (e.g. non-standard castlings), the engine should still mark the target square of the picked-up piece that initiates it (e.g. b1 when you pick up Ke1). If the user moves the King there, the GUI would prompt for the second leg and send the 'lift b1' command, but the engine would ignore it as it knows the second leg must be performed with Ra1, and could send 'click a1' to change the selected piece in the GUI, and highlight the Rook destinations (say c1, d1 or e1 for 'free castling'), so the user could click on one of those to finish the unorthodox castling.

In fact I am so happy with this highlight protocol that I consider porting it to the standard edition of WinBoard / XBoard.

[Daniel Shawul]

It is high time you included some alien features in to the standard. I did not look carefully to what has changed since the last time, but if it is just interpretation of magenta/cyan then it will not be much work for me. Chu-shogi is a complex alien game, with multiple legs and other stuff, so you might still need to tweak things for smoother game experience. I will wait until you finalize the changes to implement.
Have you made the change with sending a list of alien variants so that winboard can display it in combo box? I did it in my java gui and don't see no problem with it so far.

[hgm]

Indeed. I would love to be able to include Chu Shogi as a variant in the standard version. It is a great game, played by many people world wide. But it relies on many features that only the Alien Edition currently has. Problems arise in the area of multi-moves, the quite large number of piece types, and the representation of the pieces.

Porting the highlight feature would be a good first step. It is generally useful for variants that have to be played with legality testing off, even apart from promotion or multi-move aspects. Using it to invoke the promotion popup is quite trivial, however.

The multi-move stuff is more tricky. I am not really happy with the way I implemented it in the Alien Edition; it is very kludgy, and still behaves a bit pathological when you start stepping through the game after having entered a move only partially. So I probably want to re-implement it from scratch in the standard version, and using the highlight mechanism to enable it seems a nice improvement over the original implementation.

I don't recall if I already did something on the lists of variants; it wasquite some time ago we discussed this. I am pretty sure I did not add an extra popup to WinBoard, nor did I make the current New Variant dialog dependent on what the engine says (other than the current enabling / disabling of the radio buttons for the predefined variants). I might have made engine-defined variants selectable through the -variant command-line option; I don't remember anymore...

[Daniel Shawul]

Ok so highlight will be used to bring up promotion pop ups as well. Currently I think that was implemented with 'ask user' but coloring is ok too. We already use it for legality checking in alien mode so it is a little extension.
I am surprised chu-shogi is popular given its scary board size. Are you participating in a tournament with it? I like mini-shogi variants btw they are so tactical and fun.

The multi-move stuff is more tricky. I am not really happy with the way I implemented it in the Alien Edition; it is very kludgy, and still behaves a bit pathological when you start stepping through the game after having entered a move only partially. So I probably want to re-implement it from scratch in the standard version, and using the highlight mechanism to enable it seems a nice improvement over the original implementation.

Personally I like the method that uses 'clicking on critical squares' and then finishing automatically when there is one alternative. If you think highlight is a better way, lets try it. A doubt i have is that when the user hovers over a square and the engine sends highlights, should winboard automatically accept a leg-move? I don't understand the mechanism well. Anyway it is long time since we added stuff alien branch and i am becoming forgetful too. We can discuss and incorporate things when you have time for it.

[hgm]

The highlight commands sent by the engine should never lead to any action by the GUI other than marking the squares accordingly. For entering moves the GUI should wait for the user to click the to-square, in the normal way, except that it can now use the markers to decide what action to take (e.g. reject moves to non-highlighted squares, or show a promotion popup first, or ask for another leg before considering the move finished). Mere hovering should also never trigger anything irreversible.

For having the engine finish move once it is unambiguously determined, we introduced the click command, with which it can emulate user mouse clicks. (But it could not do anything the user could not have done himself.)

The hovering is purely intended for visual effects to provide additional information on non-obvious capture victims, such as in ultima. This to solve the problem that a piece that you 'pick up' can have several capture moves, each capturing victims in a different spot, and you don't want to highlight all possible victims of all captures together, but want to provide per-move info. So initially you highlight all to-squares of moves that would capture something in red, and when the user hovers over one of the red squares, the engine can point out the victims of that specific capture with a new highlight command.

I am not sure how one should treat moves that optionally capture something. But fortunately have never seen a game where this is possible. With replacement capture this is obviously never possible, but with other capture forms it could be a choice. I guess the best way would be to assume non-capture, and force the user to move via the squares of the optional victims to do replacement capture of those if he wants to capture them. Come to think of it, with this method multi-moving could basically make variant alien unnecessary, at the expense of a somewhat more cumbersome notation. If side effects of a move consist only of disappearence of pieces on other squares, the move coud always be written as a multi-leg move stepping on all the victims. E.g. in checkers you could write a3xb4,c5. The victim b4 could be highlighted in cyan as a first-leg click, and c5 in 'non-sensitive' red (i.e. a lower-case r in the highlight color-FEN). Clicking on b4 could have the engine finish the move by sending click c5. Automatic side effects, like the Rook move in a non-standard castling, could always be performed by click commands sent by the engine, if the identifying move (say Ke1-b1) would be marked as a partial move (i.e. in cyan), so that the GUI would wait for those clicks (and the move would be notated as Kb1,Rc1, rather than O-O-O, which might be just as well, especially if the user had a choice between Rc1 and Rd1, as in some variants he would have). No need to send any board updates, really. Even pieces growing out of nothing as side effect of some move could be emulated by additional drop-move legs. (Hmm, growing opponent pieces could be a problem, as drop moves imply your own color, but a new syntax could be invented for such enemy drops. And I have never seen that anyway. Long-algebraic can just as easily move opponent pieces, the GUI should just not be squeemish about that, in case you want to implement push-and-shove games like Arimaa.)

Would this be a better way to do it? Variant alien never completely worked in WinBoard, with respect to reading PGN from file, as the engine's board updates would lag behind the PGN parsing. Having all information explicitly mentioned in the move notation would make that problem go away completely. And to specify a multi-capture in checkers, you would click on the victimes (in the right order), rather than on the hypothetical corner points of the trajectory. Which also does not sound too bad.

If I understand your 'essential squares' method correctly, is a bit complex, as it could lead to out-of-order entry of the squares. That means the GUI will not be able to deduce move notation without help from the engine. With the click command the engine merely finishes the move, so the clicks (be it user mouse clicks or engine commands) will always be in the normal order. If you would (say) in checkers indicate a double capture that (after a shared first leg) could go in two directions, and you want to enter it by only clicking from and final to-square, the engine could draw the conclusion on the intermediate square, but it would be too late to click it. So if the mention of the intermediate square was mandatory in the move notation, the GUI would now lack essential information. The only way I see to solve this would be to never let the GUI accept moves from mouse clicks, but only send the clicks to the engine as lift and put commands without any interpretation, and then receive the complete move from the engine. It would be kind of difficult to do this without visual glitches. E.g. when you drag a piece to a certain square, and release it, should the GUI now assume you want to move it there, or should it jump back to the from-square and wait for the engine to move it somewhere entirely different (because this was just the first leg of a more elaborate move)?

[Daniel Shawul]

Would this be a better way to do it? Variant alien never completely worked in WinBoard, with respect to reading PGN from file, as the engine's board updates would lag behind the PGN parsing. Having all information explicitly mentioned in the move notation would make that problem go away completely. And to specify a multi-capture in checkers, you would click on the victimes (in the right order), rather than on the hypothetical corner points of the trajectory. Which also does not sound too bad.

You do realize what you are asking is to completely dump several months of work? Well maybe it will work to just send everything in a move as you said but I thought Alien is for games that one never thought of before. Clicking on every capturable square solves the checkers problems but how about when the move has a different effect, or that it is tiresome to click on every square, or new pieces popup after a move etc... I think you should try it first with your engines and see
if it is workable.

If I understand your 'essential squares' method correctly, is a bit complex, as it could lead to out-of-order entry of the squares. That means the GUI will not be able to deduce move notation without help from the engine. With the click command the engine merely finishes the move, so the clicks (be it user mouse clicks or engine commands) will always be in the normal order. If you would (say) in checkers indicate a double capture that (after a shared first leg) could go in two directions, and you want to enter it by only clicking from and final to-square, the engine could draw the conclusion on the intermediate square, but it would be too late to click it. So if the mention of the intermediate square was mandatory in the move notation, the GUI would now lack essential information. The only way I see to solve this would be to never let the GUI accept moves from mouse clicks, but only send the clicks to the engine as lift and put commands without any interpretation, and then receive the complete move from the engine. It would be kind of difficult to do this without visual glitches. E.g. when you drag a piece to a certain square, and release it, should the GUI now assume you want to move it there, or should it jump back to the from-square and wait for the engine to move it somewhere entirely different (because this was just the first leg of a more elaborate move)?

Nope, I assumed that the engine sends list of moves which I use for many things including multi-leg moves and promotion pop ups. I realize now that winboard doesn't have those. I recall those are the things we failed to agree up on but i will comply with the protocol when you wrap it up the way you think is better. I just think that thinking of all the possible effects a move could have and standardizing it is difficult.

[hgm]

It is not the idea to throw away any work. The Alien Edition will remain what it is, and continue to support variant alien. It is just that variant alien is a bit heavy for most applications. It would be nice if there was a 'lighter' method for variants that are perfectly normal except for a strange castling rule, a single piece that does two moves per turn, or unexpected promotions (e.g. promotion on capture).

E.g. 'free castling', where the King can move any number of squares in the direction of the Rook, and the Rook can then go to any square on the other side of the King, upto and including the original King square, simply cannot imply the Rook move from the King move, or vice versa. So variant alien does not help there: after entering the King move there still are multiple positions possible after the move, and extra information is needed to choose between them. Listing both King and Rook move as separate legs, like Kb1,Re1 , would be the logical thing to do, and it would be logical to do entering in the same way.

In cases where the Rook move would unambiguously follow from the King move, but in a way different from what the GUI would assume (WinBoard would assume the corner piece moves next to the King on the other side by default), the engine could finish the move for the user, using click commands on the Rook. It would be cumbersome to have to send complete board updates on every move just because occasionally it would be a castling.