WB protocol and variant names

[hgm]

I am now developing a patch for WinBoard that would allow an engine to announce arbitrary variant names in its feature variants="..." command. The way WinBoard handles this is that it displays unrecognized variant names in the New Variant dialog with otherwise unassigned and disabled radio buttons for variant selection. (For now there are 9 buttons reserved for this purpose.) When the user selects one of these buttons, WinBoard is switched to VariantUnknown, but the name string assigned to that variant is changed to the name on the button. So that when the engine is initialized for a new game and gets the 'variant' command, it gets the non-standard name with it.

The engine of course should know what this name means (or it should not have listed it in its variants feature). It should obligatory respond to the variant command for it with a setup command to specify what the variant means. (On standard variants this is optional.) This setup command can now have the complete syntax as defined for the Alien Edition protocol:

setup (pieceToCharTable) WxH+S_VARNAME FEN

where W, H and S are integers specifying board format and holdings size, respectively, VARNAME is the name of a standard variant (the 'parent variant') and FEN is the FEN of the initial position. The pieceToCharTable in parentheses is optional, and will be interpreted in the same way as the -pieceToCharTable command-line option. It will define the mapping of WinBoard piece types to letters of the alphabet used for them in FEN and SAN. The FEN in the command will be interpreted in the context of this pieceToCharTable.

The effect is that WinBoard will play the non-standard variant as the mentioned standard variant with (possibly) modified board size and holdings size, and a possible re-definition of the pieces that participate in it, and the initial setup.

Example: an engine for Los Alamos Chess can send (in response to protover 2):

feature variants="losalamos"

and in response to variant losalamos then send

setup (PN.RQKpn.rqk) 6x6+0_normal rnqknr/pppppp/6/6/PPPPPP/RNQKNR w - - 0 1

(The only purpose of the pieceToCharTable here is to inform WinBoard that the Bishop does not participate in this game, and should not be offered as a promotion choice, as otherwise the assigned ID letters would be standard for the parent variant 'normal' anyway.) This should allow the user of the engine to play Los Alamos Chess by selecting it from the New Variant menu just like any standard variant.

It seems wise to require engine-defined variant names to consist of letters only.

[Daniel Shawul]

This is a good move because it centralizes variant selection and gives the GUI or Referee Engine to coordinate variant selection. I have done this in my android app and it works pretty well. The internal combo boxes for the participant engines are gone now.

Code: Select all

feature variants="9x9+7_shogi,5x6+7_shogi,5x5+5_shogi,6x6+6_shogi,8x8+5_crazyhou
se,8x8+0_atomic,8x8+0_ultima,8x8+0_normal,6x6+0_losalamos,16x16+0_bigchess,12x8+
0_courier,10x8+0_capablanca,10x8+0_gothic,10x10+7_grand,8x8+0_makruk,8x8+0_shatr
anj,8x8+0_knightmate,8x8+0_berolina,8x8+0_spartan,10x8+0_coordinatorchess,10x8+0
_immobilizerchess,10x8+0_withdrawerchess,10x8+0_longleaperchess,10x8+0_advancerc
hess,10x8+0_pushmepullyuschess,12x12+0_omegachess,14x14+0_quadruplechess,14x11+0
_triplechess"

If the GUI sends 'variant shogi', the Nebiyu selects the first of the 4 shogi variants. To select the second or other variants, GUI should send 'variant 5x6+7_shogi' etc. The parent variant is specified during the 'setup' command. This is not needed for my android app that is totally alien (uses referee engine), but is needed by Winboard that has support for some variants. I am not sure if using the variant from the 'setup' will cause conflicts when using a referee, but I guess ignoring it will not cause a problem. Losalamos with the parent variant normal
Edit: I had the bishop in pieceToChar that have now fixed. I forgot that is how Winboard figures out possible promotion pieces.

Code: Select all

variant losalamos normal 2
6 6 0
.*PpKkQqRrNn
rnqknr/pppppp/6/6/PPPPPP/RNQKNR w - - 0 1
#PNBRQFEACWMOHIJGDVLSUKpnbrqfeacwmohijgdvlsuk
 PN.RQ................Kpn.rq................k
P  100  wbaidaq
p  100  bbaidaq
K 1000  king
k 1000  king
Q  900  queen
q  900  queen
R  500  rook
r  500  rook
N  300  knight
n  300  knight
2 8 8
44 2

And the first setup sends the parent i.e. normal

Code: Select all

setup (PN.RQ................Kpn.rq................k) 6x6+0_normal rnqknr/pppppp/6/6/PPPPPP/RNQKNR w - - 0 1

Second setup

Code: Select all

e2e3
setup rnqknr/pppppp/6/4P1/PPPP1P/RNQKNR b - - 0 1

[hgm]

I even have this working in XBoard now, with NebiyuAlien running under wine (xboard -fcp "wine ./NebiyuAlien.exe" -fd Nebiyu):


New Variant dialog. For no real reason the number of engine-defined variants is currently limited to 6.

Just one question: why do you prefix the engine-defined names with the board size? In the end only the board size specified in the setup command from the engine matters. The engine should know the board size from the game definition, without any need to derive it from the name. Only for standard variants, where the name implies a size other than the one you want, does the prefix supply essential information. For engine-defined names there doesn't seem any need to use the same name for different board sizes. And when the names are unique, there is no need for prefixes.

Not that they present a problem. But it just looks a bit ugly on the buttons.

[Daniel Shawul]

How do you then identify the four shogi variants I have. Should I just send one 'feature variant=shogi' for all the variants? In that case winboard would not know whether a specific variant with different board size is supported or not? So it is for Winboard's benefit that the engine should send it because the engine knows which board sizes it can play.

You can simply truncate the board specification and put a button 'shogi' instead, and let the dimensions be specified from edit box. In but winboard can send different board size variants that the engine does not support.

Btw instead of buttons, you can try one list box which is compact.

[Daniel Shawul]

I should ask if there are standard variants that can be played with different dimensions. Does winboard rely on the engine to reject the variant so that it can display 'Engine 1 does not support variant x', or does it do it by itself looking at the list of variants it has for the specific engine? The way I did it was to filter variants supported by both engines so that 'engine x doesn't support' this don't happen. In any case I think this will be a great addition to winboard.

[hgm]

How do you then identify the four shogi variants I have. Should I just send one 'feature variant=shogi' for all the variants?

Well, that is exactly the idea of engine-defined variant names. You could sens anything. E.g. feature variants="MiniShogi,JudkinsShogi,shogi,DobutsuShogi,ToriShogi,MicroShogi". As far as WinBoard is concerned any variant names it does not recognize are arbitrary strings, and there is no need for any effort to interpret them. They are only used to echo back to the engine, and on the buttons.

The prefixes are only needed in the old system, where the user had to completely configure the GUI, and the GUI then had to send all that info (board format and parent variant) to the engine.

In that case winboard would not know whether a specific variant with different board size is supported or not? So it is for Winboard's benefit that the engine should send it because the engine knows which board sizes it can play.

Well, the only merit I see of giving the GUI a preview of the board size in the variant name is that it could be able to block variants in advance that have a board size so large that the GUI itself would not support it. But I wonder if this is a good design. The user would then never know the engine could play those variants, and would not know why. It would be better to put them on the menu, allow the user to select them, and then when the GUI receives the specs in the setup command inform the user that the GUI needs to be recompiled. (Of course ideally there would not be a fixed limit to the board size at all, and the GUI would allocate the space for the board(s) dynamically.)

You can simply truncate the board specification and put a button 'shogi' instead, and let the dimensions be specified from edit box. In but winboard can send different board size variants that the engine does not support.

Yes, that was the old system, and the button 'shogi' is already there, because it is a standard variant. And without an engine, in game-viewer mode, you still would have to do that. (But then there is also no engine you need to send a variant command to.) And I don't want to strip off the board specs if they are the only distinguishing part of the name, to get 4 buttons labeled 'shogi' and let the user guess which button is for which board size. So I am kind of forced to put 5x5+5_shogi, 6x6+6_shogi on the buttons, where the user would probably rather see MiniShogi, JudkinsShogi on the buttons. (Or perhaps MiniShogi(5x5), judkinsShogi(6x6). There is no compelling reason to forbid any character in a variant name other than comma and double quote.)

The implementation I just made would only create buttons for variants with a base name that is not a standard variant. So all the shogi variants with different board sizes now indeed rely on the single standard Shogi button, and the board-size overrules.

Btw instead of buttons, you can try one list box which is compact.

Indeed, this might be better. But the New Variant dialog predates the use of listboxes in the generic popup, and in WinBoard the dialog is not even generated by GenericPopup, but by a dedicated dialog (which uses radiobuttons). There are things I can do with the buttons (like colorization) that would be hard in a listbox, however, so I might keep it the way it is, for now.

[hgm]

I should ask if there are standard variants that can be played with different dimensions. Does winboard rely on the engine to reject the variant so that it can display 'Engine 1 does not support variant x', or does it do it by itself looking at the list of variants it has for the specific engine? The way I did it was to filter variants supported by both engines so that 'engine x doesn't support' this don't happen. In any case I think this will be a great addition to winboard.

WinBoard does not rely on the engine for this, other than that it uses the list supplied by the engine in the variants feature to check if the requested variant is there. So normally an engine should never receive a variant command for a variant it did not claim to play. The protocol does therefore not have a specific way to reject a variant. (I suppose you could use 'Unknown Command', however, but WinBoard ignores this. Or you might try to switch any variant you do not know back to normal Chess, or a variant you do know, through a setup command.)

There is one loophole in the protocol, however: variant normal is default after 'new', and does not need a variant command. Not every engine supports variant normal, however. But they cannot refuse the 'new' command, which should preced any variant command. And the variant command then might never come. It would not become clear to the engine there is an error before it receives a go command or move. without the proper variant command.

[hgm]

One thing I overlooked is that the 5x5+5_shogi in the variants feature is still useful for backward compatibility. If you want to play two engines against each other, it is imperative they both use the same name for the variant. Which might not be the case if they independently defined their own names for this variant. Like 'mini-Shogi' for one, and 'MiniShogi' for the other.

So as convenient as the engine-defined names are for human-engine games, as problematic they can be in engine-engine tourneys. Therefore it would be nice if each engine would also list the 'parentage notation' 5x5+5_shogi in the variants feature, next to the engine-defined name 'minishogi'. Then WinBoard would be prepared to send either of those to the engine.

Note that in the current implementation WinBoard/XBoard would never make a separate button for the 5x5+5_shogi entry, as it already has the standard shogi button. So you would not get duplicate buttons in the New Variant menu. But for setting up a tourney you could use the options -variant shogi -boardWidth 5 -boardHeight 5 -holdingsSize 5 -pieceToCharTable "..." -loadPositionFile "mini.fen" to make sure that every engine will understand it. (Also engines from before the engine-defined variant names era.)

[Daniel Shawul]

One thing I overlooked is that the 5x5+5_shogi in the variants feature is still useful for backward compatibility. If you want to play two engines against each other, it is imperative they both use the same name for the variant. Which might not be the case if they independently defined their own names for this variant. Like 'mini-Shogi' for one, and 'MiniShogi' for the other.

So is it better to send 'minishogi' instead of '5x5+5_shogi'? I guess what you are saying is that nebiyu conforms to standard naming that is easier for humans such as 'feature variants=minishogi, judkins, bigchess'. Even though winboard will not know the board size until the first setup, two engines can play the variant it as long as they have the same variant name 'bigchess' for instance. Ok I get it now so consider it done that all nebiyu variants would have standard names without board dimensions. I think it will work in referee mode too so I will do that and post back.

[hgm]

Btw, there seems to be something wrong in Los Alamos Chess with black promotions. Look at the game below, they both act like promoting is a dirty word. In another game (which was on Linux under wine), black actually did promote (to Queen), and the opponent rejected it as an illegal move. But I have no debug file of that, and it could very well be that the promoting side did not intend to promote, and gave a move without promotion suffix, and that WinBoard then changed this to the default promotion piece (Q), before passing it on to the opponent (who then thought it illegal).

Code: Select all

[Event "Computer Chess Game"]
[Site "ONTWIKKELLAPTOP"]
[Date "2013.09.01"]
[Round "-"]
[White "NebiyuAlien_1.45"]
[Black "NebiyuAlien_1.45"]
[Result "1/2-1/2"]
[TimeControl "40/60"]
[FEN "rnqknr/pppppp/6/6/PPPPPP/RNQKNR w - - 0 1"]
[SetUp "1"]

{--------------
r n q k n r
p p p p p p
. . . . . .
. . . . . .
P P P P P P
R N Q K N R
white to play
--------------}
1. d3 {+0.00/12} d4 {-0.06/12 1.4} 2. c3 {+0.06/14 1.3} c4 {-0.14/14 1.4}
3. Qc2 {+0.04/13 1.4} Nd5 {+0.06/13 1.1} 4. dxc4 {+0.00/14 1.1} bxc4
{+0.00/19 1.4} 5. Nd2 {+0.00/19 1.3} dxc3 {+0.12/20 1.5} 6. bxc3
{+0.00/18 1.4} e4 {+0.12/19 1.1} 7. Qb2 {+0.02/17 1.2} Qa4+ {+0.16/18 1.4}
8. Nc2 {-0.52/18 1.5} e3 {+0.62/19 1.2} 9. Qa3+ {-0.54/19 1.3} Nc5
{+0.56/21 1.1} 10. Nb1 {-0.56/21 1.2} exf2 {+0.44/22 1.5} 11. Kc1
{-0.56/22 1.4} Qxa3+ {+0.44/21 1.2} 12. Ncxa3 {-0.54/23 1.5} Ne4
{+0.66/22 1.3} 13. Nxc4+ {-0.66/22 1.3} Kc5 {+0.66/20 1.5} 14. Ne5
{-0.56/21 1.3} Rfe6 {+1.16/19 2.2} 15. Nd3+ {-1.20/18 1.3} Kc6
{+0.74/18 1.3} 16. Na3 {-1.02/16 1.1} Ndxc3 {+1.42/17 1.2} 17. Nxf2
{-1.34/18 1.5} Nxe2+ {+1.52/17 1.2} 18. Kd1 {-1.46/18 1.2} Nc5
{+1.50/18 1.5} 19. Re1 {-1.34/20 1.4} Nc3+ {+1.34/19 1.1} 20. Kd2
{-1.28/20 1.2} Rxe1 {+1.28/18 1.2} 21. Rxe1 {-1.40/21 1.6} Nxa2
{+1.48/20 1.2} 22. Re5 {-1.48/21 1.4} Rb6 {+1.42/20 1.5} 23. Rxf5
{-1.38/21 1.6} Rb2+ {+1.40/20 1.5} 24. Ke1 {-1.32/22 1.5} Nc1
{+1.38/20 1.6} 25. Nc4 {-1.32/22 1.5} Ra2 {+1.32/19 1.3} 26. Ne5+
{-1.32/21 1.4} Kb5 {+1.32/24 1.4} 27. Ned3 {-1.32/25 1.4} Nxd3+
{+1.14/26 1.6} 28. Nxd3 {-1.04/29 1.2} Rc2 {+1.04/30 1.4} 29. Rxc5+
{-0.40/29 1.4} Rxc5 {+0.00/42 1.2} 30. Nxc5 {+0.00/44 1.3} Kxc5
{+0.00/50 1.3} 31. Kd1 {+0.00/53 1.4} a4 {+0.00/63 1.3} 32. Kd2
{+0.00/64 1.3} Kc4 {+0.00/75 1.4} 33. Kc2 {+0.00/71 1.4} a3 {+0.00/82 1.3}
34. Kd2 {+0.00/85 1.4} Kb3 {+0.00/94 1.5} 35. Ke3 {+0.00/97 1.5} Kc3
{+0.00/105 1.5} 36. Ke2 {+0.00/108 1.6} Kd4 {+0.00/112 1.6} 37. Kd2
{+0.00/121 1.7} Kd5 {+0.00/117 1.7} 38. Kd3 {+0.00/136 1.9} Kc5
{+0.00/129 1.8} 39. Ke2 {+0.00/146 2.1} Kb4 {+0.00/142 2.1} 40. Kd1
{+0.00/145 2.7} a2 {+0.00/144 2.8} 41. Kc2 {+0.00/144 1.1} Kc4
{+0.00/142 1.2} 42. Kb2 {+0.00/146 1.1} Kd4 {+0.00/144 1.2} 43. Kxa2
{+0.00/147 1.3} Kc3 {+0.00/147 1.1} 44. Kb1 {+0.00/149 1.1} Kb3
{+0.00/148 1.3} 45. Kc1 {+0.00/150 1.3} Kc3 {+0.00/148 1.2} 46. Kd1
{+0.00/150 1.5} Kd3 {+0.00/148 1.3} 47. Kc1 {+0.00/150 1.5} Kc3
{+0.00/149 1.5} 48. Kb1 {+0.00/151 1.5} Kc4 {+0.00/149 1.2} 49. Kb2
{+0.00/150 1.3} Kd3 {+0.00/149 1.2} 50. Kb3 {+0.00/150 1.2} Kd4
{+0.00/150 1.3} 51. Kc2 {+0.00/151 1.4} Kc4 {+0.00/149 1.3} 52. Kd2
{+0.00/151 1.5} Kd4 {+0.00/150 1.5} 53. Kc2 {+0.00/151 1.4} Kc4
{+0.00/150 1.6} 54. Kd2 {+0.00/151 1.2} Kd4 {+0.00/150 1.6} 55. Kc2
{+0.00/151 1.3}
{XBoard adjudication: repetition draw} 1/2-1/2