Winboard Alien documentation on making checkers variants

[Rein Halbersma]

[cross-posted from Winboard forum, as the traffic here is higher, and perhaps there are more peopel interested]

Is there any documentation on how to define new variants for Winboard Alien? I'd like to adapt my checkers/draughts library to Winboard. My library can play several rules variants on arbitrary rectangular board sizes (with exotic promotion and capture removal rules), so I think I have to override the Nebiyu versions of 8x8 and 10x10 checkers/draughts. Any help on getting started would be much appreciated!

[Ferdy]

Try here.
http://hgm.nubati.net/alien.html

Some wisdom and insights.
http://www.open-aurec.com/wbforum/viewt ... 19&t=52751

Here too, "Variant engines can setup the opening position"
http://hgm.nubati.net/news.4.5.0.html#tag-D4

[Rein Halbersma]

Thanks, those links I have read before. I am specifically looking for documentation on how to write .ini files for variants, configuring both the board size, piece mappings, and other stuff, and also where to put those .ini files etc. The forum documentation is rather scattered and it's hard to find everything in one place.

[hgm]

The user can configure WinBoard with command-line options, possibly collected in an ini file. These are not really different for the Alien Edition as for the regular edition, and described in the help file of the latter.

Options relevant for non-standard variants are

-variant
-boardWidth
-boardHeight
-holdingsSize
-loadPositionFile
-pieceToCharTable

Most of those have a pretty obvious meaning; only the pieceToCharTable is tricky. Basically it is the list of 2x22 letters to be used for WinBoard's 22 built-in piece types, where a period indicates the piece type is not participating. There are some special characters here (~ and +), but they are only relevant for Crazyhouse and Shogi variants.

The loadPositionFile must contain a FEN of the initial position, in terms of the defined pieceToCharTable. (It is a bit annoying that this has to be placed in a separate file, and that there is no option -fen, that you could use to give the FEN directly. Perhaps I will implement this one day.)

But the newer way to configure the GUI is to have the engine do it, rather than using an ini file. One advantage is that a multi-variant engine can change the configuration on a game-to-game basis, without restarting WinBoard or the engine. This is achieved through the 'setup' engine->GUI command, which provides board-size parameters, parent variant, pieceToCharTable and initial position. You just have the engine announce it supports xxx in its variants feature (where xxx can be any name you made up, not being one of the standard variants):

feature variants="xxx,..."

and WinBoard will allow you to select xxx as a variant. After having sent

variant xxx

to the engine, WinBoard will now expect a reply of the form

setup (pieceToCharTable) 10x10+0_checkers FEN

to specify the board and setup of xxx, where the example uses 'checkers' as the "parent variant" (from which all other rules are inherited). The parent variant must be a standard variant.

Note this mechanism was originally developed in the Alien Edition, but has since then be ported to the regular edition as well, just as the 'highlight protocol'. For Checkers you are probably still bependent on the Alien Edition, however, as the regular edition does not support general multi-capture, (although it does support the double-capture needed for Chu Shogi).

[Rein Halbersma]

Thanks, this is very helpful!

I noticed on your website that Winboard Alien is at version 4.5-beta: does this mean that the Alien modification are relative to the regular Winboard 4.5 branch? I am asking because the regular Winboard is now at 4.8.0, and your "aliennewer" branch in your git repo has its latest commit 19 months ago. So is it possible to merge your aliennewer branch into the master Winboard branch to get an "Winboard Alien 4.8"?

[hgm]

The problem is that there are so many conflicts that merging is not practical.

The Alien Edition was in many ways an experiment. It was successful in some way, but a failure in others. The idea of having the engine send board updates after every move worked in games, but completely broke WinBoard loading of PGN. Generation of SAN also remained an unsolved problem. The support for large Shogi variants was implemented entirely in the WinBoard front end, so that it doesn't work for XBoard.

Because of these problems I considered it a better long-term strategy to port the features that were successful to the regular edition, and solve those that caused problems in an alternative way that would avoid those problems.

This has been a slow process so far, as there was not very much demand for the Alien features other than by myself, and the Alien Edition already served most of my needs. The highlight protocol has been ported to the regular edition. A new method (the 'piece' commands) has been developed to solve the SAN generation problem, and in many cases it can remove the need for board updates. Where in the Alien Edition there had to be a seperate standard variant 'checkers' to make the GUI remove pieces that were jumped over, the 'piece' command can now define this property on a piece-by-piece basis, so that the need for such a variant basically disappears.

[Rein Halbersma]

A new method (the 'piece' commands) has been developed to solve the SAN generation problem, and in many cases it can remove the need for board updates. Where in the Alien Edition there had to be a seperate standard variant 'checkers' to make the GUI remove pieces that were jumped over, the 'piece' command can now define this property on a piece-by-piece basis, so that the need for such a variant basically disappears.

Ah, that seems quite close to what I want! But it seems there is a small snag, as the GNU documentation for 4.8.0 states (bold is mine):

The engine can use it to define board format and holdings size, participating pieces, initial position, and the 'parent variant'. The latter must be a variant that is known to XBoard, and it will switch to that (but using the redefined board and setup) for playing the game.

and checkers does not seem to be a supported variant in the official 4.8.0 release. So is it somehow possible to circumvent the use of parent variants or do I have to submit a feature request to you for adding the checkers variant to the main branch?

Just to illustrate what I ideally would like to support:

1) arbitrary rectangular boards (square 4x4 through 14x14, rectangular 8x10, 10x12). This seems possible with the setup command.
2) different move directions (diagonally and/or orthogonally) and range (either 1 or limited by board size). This seems possible with the Betza notation

There are some exotic draughts variations that do not seem to fit the Betza framework (but perhaps there are tricks)
a) promotion en-passant (pawn lands during jump on the promotion line, becomes king, and continues jumping as a king, Russian draughts)
b) capture-removal en-passant (each piece is removed as soon as it is jumped, this can open up further capture opportunities for kings, Thai draughts)
c) prohibition for men to jump kings (Italian draughts)
d) restrictions on intermediate landing squares

[hgm]

The problem is that the regular WinBoard 4.8 is not capable of handling arbitrary multi-captures, neither in its internal move representation and handling, nor in the Betza notation. And a single capture of checkers already counts as a 2-leg move, as capture here means 'replacement capture', and the second leg would then be stepping off the victim to the final square to implement a checkers capture. So a Checker in Betza notation would be fFfcafmF, but this would not account for double captures. The notation could handle that by adding fcafmacafmF for double captures, but WinBoard 4.8 cannot handle that, and it would still leave out triple captures. Only Betza 2.0 has a notation for arbitrary repetition of the pair of steps that make up a checkers capture, and the current Betza parser does not understand that yet.

Variant checkers is implemented in the Alien Edition as a special case of variant multi, which does allow arbitrarily many legs in a move. And most checkers variants really need that. This makes it impossible to port variant checkers to the regular edition, for now. I do plan to increase the multi-leg capability to allow more than two capture victims, though, for the benefit of Maka Dai Dai Shogi (for which HaChu will need a Linux GUI), where the Lion Dog piece can make up to 3 captures. I might as well make the number of capture victims arbitrary large. This would still not allow multiple moves with different pieces in one turn, as the Alien Edition does, but would be good enough to also implement variant checkers.

The whole business with the 'setup' command should work in the Alien Edition as well, though. And there you can already use checkers as a parent variant. The engine would have to guide the user through multiple-capture sequences, though, by highlighting the intermediate squares that need to be clicked to specify the move in cyan. If you want the piece to be promoted on the final destination, the engine should just add a promotion suffix to the final leg of the move that it prints, or highlight the final square in magenta for moves the user enters. This might not work correctly in the Alien Edition yet (I recently had to make some fixes there in the regular edition), but this I should be able to fix.

[Rein Halbersma]

Thanks for the detailed explanation. However, my multi-variant draughts engine only compiles under Linux due to C++14 features that are currently only available in Clang (and I cannot work around those dependencies). That just leaves me in a bit of a bind for now because it seems that I either have to use WinBoard Alien (exclusively Windows) or use Win/XBoard 4.8.0 under Windows/Linux (but that has not yet multi-capture support).

If and when I can get Clang for Windows to work under Visual Studio, and/or g++ 5.2 comes out with enough bugfixes to compile my program, I can use a Windows binary to connect to WinBoard Alien. Or can I somehow use your p2p program to connect to WinBoard Alien from within a Linux VirtualBox on a Windows host?

In any case, I'd really like to express my wish for full Betza 2.0 and multi-capture support for the next XBoard release! I think the draughts world could really use such an advanced GUI to lower the entry barrier for new engines.

[abulmo]

I either have to use WinBoard Alien (exclusively Windows).

XBoard alien works under Linux. Just get the latest (but old) snapshot and compile it yourself.