Engines playing Musketeer Chess, good price

[Ferdy]

KingSlayer-Aramis 0.3 does not recognize queen promotion.



It played as black and after white queen promotion it did not bother evading from check and played Rxd1 which was illegal.

[Ferdy]

Winboard cannot replay correctly the saved game. The game was generated with two machine mode and after the piece selection and gating preparation.



The game record:

Code: Select all

[Event "Computer Chess Game"]
[Site "?"]
[Date "2020.01.31"]
[Round "-"]
[White "KingSlayer-Aramis 0.3"]
[Black "KingSlayer-Aramis 0.3"]
[Result "1/2-1/2"]
[TimeControl "60+1"]
[Variant "musketeer"]
[VariantMen "F:B3DvN;S:B2ND;K:KisO2"]
[FEN "*s****f*/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/**F***S* w KQkq - 0 1"]
[SetUp "1"]

{--------------
. s . . . . f .
r n b q k b n r
p p p p p p p p
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
P P P P P P P P
R N B Q K B N R
. . F . . . S .
white to play
--------------}
1. d4 {-0.01/10} Nf6/F {+0.01/9 0.9} 2. Nc3 {+0.13/10 1.0} d5 {+0.00/9 1.0}
3. Bf4/F {+0.05/9 1.3} Nh5 {-0.09/10 1.6} 4. Be3 {+0.02/10 2.1} Nc6/S
{-0.03/9 1.0} 5. Fb3 {+0.05/10 2.1} Nf6 {-0.06/9 1.7} 6. Nf3/S
{+0.05/9 2.2} Bf5 {-0.05/8 1.9} 7. a3 {+0.04/8 1.3} Sb6 {-0.07/7 2.0} 8.
Sg3 {+0.06/6 2.5} e6 {-0.13/6 1.0} 9. Fa4 {-0.02/5 3} Sc8 {-0.02/7 1.8} 10.
Ne5 {+0.02/6 0.9} Ne7 {-0.17/7 1.9} 11. h4 {+0.17/6 1.1} h5 {-0.13/6 0.9}
12. Fb3 {+0.10/4 0.9} Ng6 {-0.02/6 1.7} 13. Sg5 {+0.13/3 1.5} Ng4
{+0.00/2 1.0} 14. Nxg4 {-0.43/6 1.2} hxg4 {+0.50/7 1.2} 15. h5
{-0.33/7 1.4} Qxg5 {+0.45/7 1.2} 16. Bxg5 {-0.47/7 6} c6 {+0.37/6 1.4} 17.
g3 {-0.33/6 2.3} f6 {+0.30/6 1.4} 18. Bd2 {-0.33/6 0.7} e5 {+0.24/7 1.4}
19. Bg2 {-0.25/6 1.1} exd4 {+0.00/7 1.1} 20. Nxd5 {+0.00/6 0.9} Bd6
{+0.00/6 1.2} 21. hxg6 {+0.00/5 1.0} Rxh1+ {-0.43/8 1.1} 22. Bxh1
{+0.43/8 0.8} Be6 {-0.36/9 1.9} 23. Bb4 {+0.36/8 1.0} a5 {-0.40/9 2.3} 24.
Bxa5 {+0.40/8 1.4} Bxd5 {-0.47/8 0.8} 25. Bxd5 {-0.10/9 1.1} Fxd5
{-0.11/10 1.0} 26. Fxd5 {+0.27/10 0.7} cxd5 {+0.06/10 0.9} 27. Bb4
{+0.00/10 1.5} Bxb4+ {+0.00/11 1.2} 28. axb4 {+0.00/12 1.1} Rxa1
{-0.23/12 1.1} 29. Qxa1 {+0.23/11 0.9} Ke7 {-0.13/12 1.4} 30. Qa5
{+0.13/11 1.3} Se6 {-0.45/11 0.9} 31. Qb5 {+0.23/10 1.1} Se4 {+0.00/11 2.1}
32. Qxb7+ {+0.00/10 0.8} Ke6 {+0.00/11 1.1} 33. Qc8+ {+0.00/10 1.5} Ke7
{+0.00/12 1.1} 34. Qc6 {+0.00/11 1.3} Sg2+ {+0.00/13 0.8} 35. Kd1
{+0.00/15 1.0} Sf1+ {+0.00/15 1.2} 36. Ke1 {+0.00/16 1.5} Sg2+
{+0.00/17 1.4} 37. Kd1 {+0.00/17 1.6} Sf1+ {+0.00/17 0.9} 38. Ke1
{+0.00/17 1.9} Sg2+ {+0.00/18 1.7}
{XBoard adjudication: repetition draw} 1/2-1/2

The game was loaded via File->load game.

[hgm]

Ughh, this turns out to be problematic. When loading a game WinBoard tries to parse its moves before it has sent the initial position to the engine. And before that KingSlayer is using WinBoard for conducting the piece-type negociation, and has set it to 'variant prelude' for the purpose. Only after receiving a setboard KingSlayer would respond with another 'setup' command that switched the variant to seirawan. So when WinBoard is parsing the game, it is not aware that it is dealing with holdingless seirawan, and as a consequence not only ignores the gating suffixes, but cannot even do automatic gating.

One solution would be to not hide from WinBoard what the parent variant will eventually be during the negotiation phase, but has the engine sent it in the very first 'setup' command already. That means there should be defined another way then saying parent = 'prelude' for the engine to communicate to WinBoard that this setup command isn't the final one, but more are to follow. E.g. a parent name starting with an exclamation point could indicate this (and then strip the exclamation point).

Perhaps a better solution would be to have the PGN provide this information. Now the Variant tag only says "musketeer", and WinBoard has no idea what that means without first completing a dialog with the engine. Perhaps there should also be a ParentVariant tag, to make the PGN self-explanatory. There already is a VariantMen tag, which provides the info on the participating pieces and their moves, while the board sizes and presence of a holdings are implied by the FEN tag (which of course also defines the initial position). So the parent variant is the only information that the 'setup' & 'piece' commands provide that is not already in the PGN. If it were, the PGN could be interpreted without the help of any engine...

One thing I don't like is that it is sort-of implementation-dependent what is considered a standard variant and what not; different GUIs might have different ideas about that. For this reason it seems to be bad to have a ParentVariant tag. An alternative would be to make gating suffixes of the form "/pieceID" a universal part of SAN, so that they would be recognized in any variant, and have as meaning that the mentioned piece would be left on the from-square, (and be deleted from the holdings, if there are holdings).

[hgm]

OK, I updated the WinBoard-AA package.

* The pieces on the fake ranks will now disappear when the piece in front of them gets captured. This should preclude spurious gatings by non-virgin pieces.
* KingSlayer-Aramis had indeed a promotion bug: because more than one new piece type had been added, the range of piece encodings was such that promotion to a Musketeer piece would match the input move no matter what promotion suffix the latter had, because it was mistaken for another special move (e.p. capture / double-push / castling). So that a7a8q was recognized as promotion to Elephant (or whatever piece was participating) rather than Queen. In any case a promotion piece that did not check. This is now fixed.
* I changed the protocol for game preludes; KingSlayer now specifies parent variant '!seirawan' instead of 'prelude' for the non-final setup commands it uses to conduct the gating negociations in human-engine games, and WinBoard recognizes this as a signal that more setup commands are to follow later. In this way WinBoard will know from the beginning it is dealing with holdingless seirawan, and will correctly interpret the 0th and 9th rank as holdings from which gatings should take place when it parses a PGN.

The latter solution means that an engine is still required for loading Musketeer games (or games of other engine-defined variants). WinBoard uses an internal move representation of (fromSqr, toSqr, promoChar), and I overloaded the promoChar to also be used for indicating gatings in variant seirawan, when applied to moves of non-Pawns. But this kludge cannot be extended to all variants, as there are many variants where non-Pawns indeed do promote. The difference between gatings and promotions, which in SAN can still be seen by the use of '/' vs '=' in front of the piece ID, disappears in the internal representation, which basically is the coordinate notation used in the protocol. To change the internal move representation to one that allows independent specification of gating and promotion would require a massive overhaul of the code.

Apart from using a ParentVariant tag, I suppose it would be possible to look for clues in the game itself to decide if promotion suffixes in the internal representation should be interpreted 'seirawan-like' or different. E.g. whether some of the moves in it do have a "/ID" suffix. This would only work if the game does contain gatings, though, and not if a partial game without gatings was e.g. used as opening line. One problem is that the currently used FEN does not contain any clue that the 0th and 9th ranks are holdings, rather than this just being a game on an irregularly shaped board. This would be an argument to switch to an 8x8 FEN with notation for stacked pieces, and adoption of the general convention that a move of a stack with a gating suffix means splitting up the stack in a way that leaves the indicates piece as top-most piece on the from-square, and only moves all pieces that were mentioned in front of it. I.e. if the FEN specifies that on g1 we have "(NC)", the move Nf3/C would move the Knight and leave behind (= gate) the Cannon. Presence of stacked pieces in the FEN tag of the PGN would then be the clue that this is a game with gating, so that "/ID" suffixes should be recognized as belonging to the move, and be used to provide the promoChar (i.e. seirawan-like interpretation of the promoChar).

[musketeerchess]

OK, I updated the WinBoard-AA package.

* The pieces on the fake ranks will now disappear when the piece in front of them gets captured. This should preclude spurious gatings by non-virgin pieces.
* KingSlayer-Aramis had indeed a promotion bug: because more than one new piece type had been added, the range of piece encodings was such that promotion to a Musketeer piece would match the input move no matter what promotion suffix the latter had, because it was mistaken for another special move (e.p. capture / double-push / castling). So that a7a8q was recognized as promotion to Elephant (or whatever piece was participating) rather than Queen. In any case a promotion piece that did not check. This is now fixed.
* I changed the protocol for game preludes; KingSlayer now specifies parent variant '!seirawan' instead of 'prelude' for the non-final setup commands it uses to conduct the gating negociations in human-engine games, and WinBoard recognizes this as a signal that more setup commands are to follow later. In this way WinBoard will know from the beginning it is dealing with holdingless seirawan, and will correctly interpret the 0th and 9th rank as holdings from which gatings should take place when it parses a PGN.

The latter solution means that an engine is still required for loading Musketeer games (or games of other engine-defined variants). WinBoard uses an internal move representation of (fromSqr, toSqr, promoChar), and I overloaded the promoChar to also be used for indicating gatings in variant seirawan, when applied to moves of non-Pawns. But this kludge cannot be extended to all variants, as there are many variants where non-Pawns indeed do promote. The difference between gatings and promotions, which in SAN can still be seen by the use of '/' vs '=' in front of the piece ID, disappears in the internal representation, which basically is the coordinate notation used in the protocol. To change the internal move representation to one that allows independent specification of gating and promotion would require a massive overhaul of the code.

Apart from using a ParentVariant tag, I suppose it would be possible to look for clues in the game itself to decide if promotion suffixes in the internal representation should be interpreted 'seirawan-like' or different. E.g. whether some of the moves in it do have a "/ID" suffix. This would only work if the game does contain gatings, though, and not if a partial game without gatings was e.g. used as opening line. One problem is that the currently used FEN does not contain any clue that the 0th and 9th ranks are holdings, rather than this just being a game on an irregularly shaped board. This would be an argument to switch to an 8x8 FEN with notation for stacked pieces, and adoption of the general convention that a move of a stack with a gating suffix means splitting up the stack in a way that leaves the indicates piece as top-most piece on the from-square, and only moves all pieces that were mentioned in front of it. I.e. if the FEN specifies that on g1 we have "(NC)", the move Nf3/C would move the Knight and leave behind (= gate) the Cannon. Presence of stacked pieces in the FEN tag of the PGN would then be the clue that this is a game with gating, so that "/ID" suffixes should be recognized as belonging to the move, and be used to provide the promoChar (i.e. seirawan-like interpretation of the promoChar).

Hi HG

Thanks for the work done so far. Musketeer Chess is clearly a family of new games. The ancestor is Seirawan Chess. Musketeer Chess is a variant of Seirawan Chess itself a variant of Chess. The ideas behind Musketeer Chess (various fairy pieces, Piece Selection and Gating) are for the moment a unique concept. The drop mechanism of the pieces in Seirawan Chess is a particular way concerning piece selection and gating.

Having a GUI that can understand these features is probably the best way for a bigger expansion of these variants.
So the GUI will recognise the difference between seirawan and musketeer when setting up PS qnd Gating Selection (gating by dropping in Seirawan and Gating by pre selection of gating square in Musketeer).

THIS WILL ALSO OPEN debate and programming FOR ANOTHER VARIANT IDEA I HAVE: MuSeirawan Chess = a Seirawan Chess Variant with piece selection like in Musketeer Chess and Drop mechanism (or classic GS in musketeer chess). Choice of the gating mechanism by agreement between players. Or in tournaments 4 round robin alternate colours and gating mechanisms.

[Ferdy]

OK, I updated the WinBoard-AA package.

There seems to be an issue on graphics. There are situations where after a move (example here is Bxd3), square D2 is blackened.
This is on windows 10.

[hgm]

Oops, this is more than just graphics! Seems I was a bit over-enthousiastic when removing gateable pieces after capture of the piece in front of them. I uploaded the fixed version now.

[Ferdy]

Oops, this is more than just graphics! Seems I was a bit over-enthousiastic when removing gateable pieces after capture of the piece in front of them. I uploaded the fixed version now.

Looking great, no more unnecessary darkened squares, saved games can now be replayed and KingSlayer-Aramis 0.4 can now recognize queen promotion.

[musketeerchess]

Oops, this is more than just graphics! Seems I was a bit over-enthousiastic when removing gateable pieces after capture of the piece in front of them. I uploaded the fixed version now.

Looking great, no more unnecessary darkened squares, saved games can now be replayed and KingSlayer-Aramis 0.4 can now recognize queen promotion.

Hi Guys
I'm back after a few very busy days at work.

Nice to see all this work.

What i'd like next is to see Nebiyu capable of playing tournaments. Would like also to see the monster Stockfish under winboard. I'm going to compile it and try it. Unless this was already done by one of you share with me on PM.
Zied

[Ferdy]

Specific rule when the king is in check and this king has a musketeer piece behind it for gating. Rules at site will be updated soon.

Code: Select all

****c*l*/r3kBnr/1pp1pB1p/p1np2p1/P5qb/4P3/3P1P2/1PP3PP/RN1QK1NR/*C****L* b KQkq - 0 1

Black to move its king is under attack.
* Black can only gate (the cannon, see image above) if the king can capture its attacker (White bishop at F7 square).

It seems like winboard 4.20200207 misses the rule on gating when king is under attack. If black plays Kxf8 or e8f8, it should not gate the cannon. The only move that can gate the cannon is by the move Kxf7 or e8f7 (a move where the king itself captures its attacker).