Engines playing Musketeer Chess, good price

[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). This move is e8f7c see perft below.

Perft divide 1

Code: Select all

   e8d7 : 1
  e8f7c : 1
   e8d8 : 1
   e8f8 : 1
 LeafNodes : 4

[hgm]

The WinBoard-AA package now contains a WinBoard version that no longer needs a gating suffix to the move in holdingless Seirawan. WinBoard already had code that made it resistant to missing promotion characters, supplying a default in that case (usually Q). So I just had to make the legality test recognizing first-rank moves with something behind it as a promotion. The promotion character was not as insignificant as I thought, so I now set it to the piece behind it, in a bit of a kludgy way. (It would not work with an odd number of ranks.) But for now that should do.

It will still add a gating suffix in the moves it sends to the engine.

Thanks for the update.

I have not implemented yet the PS and GP phases, what I do is trying to support pasting of fen after PS and GP phases.
On winboard/engine communication, upon receiving the position via setboard,

Code: Select all

10565 >first : setboard f******l/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/F******L w KQkq - 0 1

I just sent back the full piece_to_char and the fen that I received, followed by the piece id's.

Code: Select all

10684 <first : setup (PNBRQ.E....C.AF.MH.SU........D............LKpnbrq.e....c.af.mh.su........d............lk) 8x10+0_seirawan f******l/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/F******L w KQkq - 0 1

Code: Select all

10685 <first : piece L& NB2
10685 <first : piece C& llNrrNDK
10685 <first : piece E& KDA
10685 <first : piece U& CN
10685 <first : piece S& B2DN
10686 <first : piece D& QN
10686 <first : piece F& B3DfNbN
10686 <first : piece M& NR
10686 <first : piece A& NB
10686 <first : piece H& DHAG
10686 <first : piece K& KisO2

I detect the musketeer pieces selected thru the fen (in all ranks) that I received. It should work after PS and GP.

Perhaps I will not send the piece id definitions because when I receive

Code: Select all

10563 >first : variant musketeer

before setboard, I send setup and piece id's

Code: Select all

setup (PNBRQ.E....C.AF.MH.SU........D............LKpnbrq.e....c.af.mh.su........d............lk) 8x10+0_seirawan *c****l*/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/*C****L* w KQBCDFGkqbcdfg - 0 1

Code: Select all

10658 <first : piece L& NB2
10658 <first : piece C& llNrrNDK
10658 <first : piece E& KDA
10659 <first : piece U& CN
10659 <first : piece S& B2DN
10659 <first : piece D& QN
10659 <first : piece F& B3DfNbN
10659 <first : piece M& NR
10659 <first : piece A& NB
10659 <first : piece H& DHAG
10659 <first : piece K& KisO2

That fen is my default.

Code: Select all

*c****l*/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/*C****L* w KQBCDFGkqbcdfg - 0 1

In any case it is working so far.

The way KingSlayer does it is first send a setup with all pieces in the PTC, and parent 'prelude', in response to 'variant musketeer', to fulfill its obligation of a setup in an engine-defined variant, without losing the possibility to send more setup commands later. In response to a setboard it can echo the FEN in a setup, restrict the pieces to those in the FEN, (so WinBoard would not allow the user to pick non-participating ones on promotion), and set the final parent to seirawan. It doesn't hurt to send piece commands for pieces that later turn out not to participate, but it would be bad form to sent them for a pice with an ID that is not in the PTC at the time. (Although I think the current WB implementation is resistent to it.)

[hgm]

The WinBoard-AA package now contains a WinBoard version that no longer needs a gating suffix to the move in holdingless Seirawan. WinBoard already had code that made it resistant to missing promotion characters, supplying a default in that case (usually Q). So I just had to make the legality test recognizing first-rank moves with something behind it as a promotion. The promotion character was not as insignificant as I thought, so I now set it to the piece behind it, in a bit of a kludgy way. (It would not work with an odd number of ranks.) But for now that should do.

It will still add a gating suffix in the moves it sends to the engine.

There is an issue in sending a move to the engine. Gating suffix is not required but winboard sent a move with suffix.

KingSlayer(first) - aiM(second)

White to play and played,

Code: Select all

131764 <first : move c1c3

Then winboad sent

Code: Select all

131764 >second: c1c3f

and was correctly rejected as illegal.

Code: Select all

131873 <second: Error (Illegal move): c1c3f

Well, this is what I wrote. WinBoard will still add gating suffixes. I want the SAN for such moves to contain suffixes, for clarity. E.g. Rc3/F. Stripping them off the move in coordinate notation would then be a bit inconsistent. On input WB considers suffixes optional.

[Daniel Shawul]

Does xboard (not winboard) have alien mode incorporated correctly? I was trying to play musketeer in alien mode but
it only updates the initial position correctly even if nebiyu sends a setup command after each move.
I installed xboard a while ago though.

Also, I remember xboard does not recognize a variant if I added a prefix of board size and holdings in the variant name, so what I did to fix this is make the first variant (or a chosen one) of list of variants with the same "parent variant" to be without a prefix when sending the list of supported variants. But in alien mode, I send with prefixes anyway. Is the parent for all alien variants "alien" or I can group them how I like. In any case, I think this parent variant mode complicates things more and it would be good if xboard recognizes a variant even if it is sent without board size/holdings prefix.

[Ferdy]

The WinBoard-AA package now contains a WinBoard version that no longer needs a gating suffix to the move in holdingless Seirawan. WinBoard already had code that made it resistant to missing promotion characters, supplying a default in that case (usually Q). So I just had to make the legality test recognizing first-rank moves with something behind it as a promotion. The promotion character was not as insignificant as I thought, so I now set it to the piece behind it, in a bit of a kludgy way. (It would not work with an odd number of ranks.) But for now that should do.

It will still add a gating suffix in the moves it sends to the engine.

There is an issue in sending a move to the engine. Gating suffix is not required but winboard sent a move with suffix.

KingSlayer(first) - aiM(second)

White to play and played,

Code: Select all

131764 <first : move c1c3

Then winboad sent

Code: Select all

131764 >second: c1c3f

and was correctly rejected as illegal.

Code: Select all

131873 <second: Error (Illegal move): c1c3f

Well, this is what I wrote. WinBoard will still add gating suffixes. I want the SAN for such moves to contain suffixes, for clarity. E.g. Rc3/F. Stripping them off the move in coordinate notation would then be a bit inconsistent. On input WB considers suffixes optional.

The fortress piece on square C0 can no longer be gated. The correct move here is only c1c3 or normal move Rc3. The first engine is correct in sending the move c1c3. Winboard should just send c1c3 to the second engine. If you are not interested in fixing this, I will just let the engine ignore such move format.

[Ferdy]

Created a musketeer chess page trying to describe the game and there are also perft 4 result data after PS and GP phases on some 2-musketeer piece type combo, like cannon/leopard, dragon/leopard and others.

https://github.com/fsmosca/musketeer-chess

Perft data in csv file are at https://github.com/fsmosca/musketeer-ch ... ster/Perft

[Daniel Shawul]

Nice, that is very helpful for those interested in writing an engine for it!

My musketeer engine is now available in NebiyuAlien and I was able to play a full game with it in my GUI.

https://sites.google.com/site/dshawul/nebiyu160.zip

The piece letters I use are similar to yours so it should be compatible with your engine, but note that
Stockfish uses a different piece letter for the Chancellor I think. So if we want to standardize it better do it now.
The variant name I use is "musketeer", and also I don't suffix gating moves with promotion letters.

One thing I do is to allow king captures ( I seem to get 2x larger nps with it) so you may see king captures in its PV.
Also, stalemate detection was kind of hard to get right with this approach, so I do it only the first two plies.
Without that, it was considering stalemate moves and was thinking it was winning ... But after the first two plies, it still assumes
stalemate to be a win, I don't think there is a lot of damage due to that.

With regard to NN, I am thinking of using existing NN to see how it does with the Archbishop and Dragon pieces selected. These are rook+knight
and queen+knight, which I plan to treat as two pieces on the same square and see if it gives reasonable outputs. For the rest of the pieces,
maybe an approximation will work, otherwise, a net has to be trained from scratch...

I am not yet able to make it play under xboard in "alien" mode as it seems it doesn't update the board
from the setup command that the engine sends. Gated pieces still remain on the back rank even when the piece
in front of them moves, so I guess xboard still constructs its own board from the moves engine's send (no alien support?).

[Ferdy]

Nice, that is very helpful for those interested in writing an engine for it!

My musketeer engine is now available in NebiyuAlien and I was able to play a full game with it in my GUI.

https://sites.google.com/site/dshawul/nebiyu160.zip

The piece letters I use are similar to yours so it should be compatible with your engine, but note that
Stockfish uses a different piece letter for the Chancellor I think. So if we want to standardize it better do it now.
The variant name I use is "musketeer", and also I don't suffix gating moves with promotion letters.

One thing I do is to allow king captures ( I seem to get 2x larger nps with it) so you may see king captures in its PV.
Also, stalemate detection was kind of hard to get right with this approach, so I do it only the first two plies.
Without that, it was considering stalemate moves and was thinking it was winning ... But after the first two plies, it still assumes
stalemate to be a win, I don't think there is a lot of damage due to that.

With regard to NN, I am thinking of using existing NN to see how it does with the Archbishop and Dragon pieces selected. These are rook+knight
and queen+knight, which I plan to treat as two pieces on the same square and see if it gives reasonable outputs. For the rest of the pieces,
maybe an approximation will work, otherwise, a net has to be trained from scratch...

I am not yet able to make it play under xboard in "alien" mode as it seems it doesn't update the board
from the setup command that the engine sends. Gated pieces still remain on the back rank even when the piece
in front of them moves, so I guess xboard still constructs its own board from the moves engine's send (no alien support?).

Thanks will try it. It would be interesting to see an NN specially in unicorn/hawk combo, which can jump at long distances, can fork, and mate without being blocked as these are jumpers and for humans it is already tactical even if these pieces are not yet gated.

[hgm]

The WinBoard-AA package now contains a WinBoard version that no longer needs a gating suffix to the move in holdingless Seirawan. WinBoard already had code that made it resistant to missing promotion characters, supplying a default in that case (usually Q). So I just had to make the legality test recognizing first-rank moves with something behind it as a promotion. The promotion character was not as insignificant as I thought, so I now set it to the piece behind it, in a bit of a kludgy way. (It would not work with an odd number of ranks.) But for now that should do.

It will still add a gating suffix in the moves it sends to the engine.

There is an issue in sending a move to the engine. Gating suffix is not required but winboard sent a move with suffix.

KingSlayer(first) - aiM(second)

White to play and played,

Code: Select all

131764 <first : move c1c3

Then winboad sent

Code: Select all

131764 >second: c1c3f

and was correctly rejected as illegal.

Code: Select all

131873 <second: Error (Illegal move): c1c3f

Well, this is what I wrote. WinBoard will still add gating suffixes. I want the SAN for such moves to contain suffixes, for clarity. E.g. Rc3/F. Stripping them off the move in coordinate notation would then be a bit inconsistent. On input WB considers suffixes optional.

The fortress piece on square C0 can no longer be gated. The correct move here is only c1c3 or normal move Rc3. The first engine is correct in sending the move c1c3. Winboard should just send c1c3 to the second engine. If you are not interested in fixing this, I will just let the engine ignore such move format.

Non-gatable pieces should not be on display. So the error is here that it was not blacked out after the piece in front of it was captured?

[hgm]

Does xboard (not winboard) have alien mode incorporated correctly? I was trying to play musketeer in alien mode but
it only updates the initial position correctly even if nebiyu sends a setup command after each move.
I installed xboard a while ago though.

Also, I remember xboard does not recognize a variant if I added a prefix of board size and holdings in the variant name, so what I did to fix this is make the first variant (or a chosen one) of list of variants with the same "parent variant" to be without a prefix when sending the list of supported variants. But in alien mode, I send with prefixes anyway. Is the parent for all alien variants "alien" or I can group them how I like. In any case, I think this parent variant mode complicates things more and it would be good if xboard recognizes a variant even if it is sent without board size/holdings prefix.

I don't think the Alien Edition ever worked in XBoard, although I am not completely sure. I think I was not yet seriously working on XBoard at the time the Alien Edition was created. The conversion of XBoard to GTK could not be merged with the alien branch of my repository, because too many files had changed location, and git did not recognize them.

As for variant names: the modern way is 'engine-defined variants': just use just any descriptive text name, and have the engine reply to it with a setup command specifying pieceToCharTable, board size, parent variant and initial position. The board-size prefix in variant names is a legacy of the time when the user, rather than the engine had to configure WinBoard for a variant, through board-size override options like -boardWidth, etc. Although it can sometimes still be useful as a work-around when different engines play the same variant under a different name. (When they both define the parent with prefix as a backup possibility, and the do not support so many variants that this is not unique.)