Engines playing Musketeer Chess, good price

[hgm]

Well, there still is a problem with the proposed Musketeer FENs that was brought up by the Stockfish developers: for loading a position in the engine where the Musketeer pieces already have been traded out of the game, it would not be clear to the engine which pieces a Pawn can promote to. But that problem doesn't exist for initial positions.

I am not sure this problem is worth addressing. FENs do not fully encode the game state anyway; you will need the game history since the last irreversible move for that. (To catch repetitions.) We could simply accept that the eligible promotion pieces are not always FEN-encoded, and only load Musketeer positions into engines starting from an initial position (or at least one with both Musketeer types present) followed by a series of moves. That doesn't seem to hurt much.

[hgm]

To encourage people to convert their engine to play Musketeer Chess, I want to point out that this can often be quite simple. Gating in Musketeer Chess is automatic rather than optional, so it would not have to be encoded in the move format. In my mailbox engine it would require only a small change to implement it. Normally I have something like:

Code: Select all

MOVE DECODE:
  move => { fromSqr, toSqr, captSqr, promotionGain }
  piece = board[fromSqr]; victim = board[captSqr]; promoted = piece + promotionGain;
MAKEMOVE:
  board[captSqr] = 0;
  board[fromSqr] = 0; board[toSqr] = promoted; // This line will be adapted
  materialKey += keyChange[promotionGain] - mKeys[victim];
  boardKey ^= zobrist[victim][captSqr] ^ zobrist[promoted][toSqr] ^ zobrist[piece][fromSqr];
  pstEval += PST[victim][captSqr] + PST[promoted][toSqr] - PST[piece][fromSqr];
UNMAKE:
  board[toSqr] = 0; board[captSqr] = victim; board[fromSqr] = piece;
  materialKey = savedMaterialKey; boardKey = savedBoardKey; pstEval = savedEval;

What you can do is use a different piece type for a piece that is still able to gate in another piece (but which moves the same), and for each piece type tabulate the type of the piece it will gate onto the board, in an array gated[], and what it changes to (so it loses its gating power) in an array spent[]; The change in MAKEMOVE then becomes:

Code: Select all

  board[fromSqr] = gated[piece]; board[toSqr] = promoted - spent[piece];

Almost all piece types will have gateds[piece] = spent[piece] = 0, so MAKEMOVE acts as always. For the types that stand on gating squares, gated[] holds the pre-determined gating type. For gating moves there is no promotion, so promotionGain = 0 and promoted = piece. The pstEval is thus just adapted as if the gating piece moves on its own PST; (This could be either the same as that of the piece it changes to, or have an extra low value at the gating square to encourage gating.) If the PST include the piece base value, this would be set to the sum of the value of gating and gated piece for this table, so that a capture of it would gain both. Gating in itself does only reap positional gain; the piece in hand is worth nearly as much as on the board.

[musketeerchess]

Thank you HG for your help.
Now that gating the pieces is almost standard under winboard i’m waiting for the participants

To encourage people to convert their engine to play Musketeer Chess, I want to point out that this can often be quite simple. Gating in Musketeer Chess is automatic rather than optional, so it would not have to be encoded in the move format. In my mailbox engine it would require only a small change to implement it. Normally I have something like:

Code: Select all

MOVE DECODE:
  move => { fromSqr, toSqr, captSqr, promotionGain }
  piece = board[fromSqr]; victim = board[captSqr]; promoted = piece + promotionGain;
MAKEMOVE:
  board[captSqr] = 0;
  board[fromSqr] = 0; board[toSqr] = promoted; // This line will be adapted
  materialKey += keyChange[promotionGain] - mKeys[victim];
  boardKey ^= zobrist[victim][captSqr] ^ zobrist[promoted][toSqr] ^ zobrist[piece][fromSqr];
  pstEval += PST[victim][captSqr] + PST[promoted][toSqr] - PST[piece][fromSqr];
UNMAKE:
  board[toSqr] = 0; board[captSqr] = victim; board[fromSqr] = piece;
  materialKey = savedMaterialKey; boardKey = savedBoardKey; pstEval = savedEval;

What you can do is use a different piece type for a piece that is still able to gate in another piece (but which moves the same), and for each piece type tabulate the type of the piece it will gate onto the board, in an array gated[], and what it changes to (so it loses its gating power) in an array spent[]; The change in MAKEMOVE then becomes:

Code: Select all

  board[fromSqr] = gated[piece]; board[toSqr] = promoted - spent[piece];

Almost all piece types will have gateds[piece] = spent[piece] = 0, so MAKEMOVE acts as always. For the types that stand on gating squares, gated[] holds the pre-determined gating type. For gating moves there is no promotion, so promotionGain = 0 and promoted = piece. The pstEval is thus just adapted as if the gating piece moves on its own PST; (This could be either the same as that of the piece it changes to, or have an extra low value at the gating square to encourage gating.) If the PST include the piece base value, this would be set to the sum of the value of gating and gated piece for this table, so that a capture of it would gain both. Gating in itself does only reap positional gain; the piece in hand is worth nearly as much as on the board.

[Ferdy]

Well, there still is a problem with the proposed Musketeer FENs that was brought up by the Stockfish developers: for loading a position in the engine where the Musketeer pieces already have been traded out of the game, it would not be clear to the engine which pieces a Pawn can promote to. But that problem doesn't exist for initial positions.

I am not sure this problem is worth addressing. FENs do not fully encode the game state anyway; you will need the game history since the last irreversible move for that. (To catch repetitions.) We could simply accept that the eligible promotion pieces are not always FEN-encoded, and only load Musketeer positions into engines starting from an initial position (or at least one with both Musketeer types present) followed by a series of moves. That doesn't seem to hurt much.

I think for a start the initial position is enough.

To be simpler without using prelude, the musketeer pieces at ranks 0 and 9 can be varied and the engine should understand when gui sends for example,

Code: Select all

setboard *d***s**/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/*S**D*** w KQBkqbf - 0 1

The gating capability of musketeer pieces are in KQBkqbf field.

[hgm]

I uploaded a new WinBoard-AA package: in the previous one promotions would not work for holdingless Seirawan, because WinBoard thought the promotion zone was in the 0th and 9th rank!

I also made the musky.exe in the Fairy-Max folder of that package now into a real Musketeer Chess engine, rather than just a demo for the prelude. That is, it seems to be able to play a human-engine game; I didn't test its (or WinBoard's) capabilities to play engine-engine Musketeer games yet.

This engine is a KingSlayer derivative, which I called KingSlayer-Aramis. KingSlayer is a simple demo engine which is just one step up from Fairy-Max. (At least it puts the moves in a list first and sorts them, rather than searching them as the come from the move generator.) For normal Chess it should have an Elo rating around 2100-2200. (It clobbers Fairy-Max rather badly.) Actually I converted the KingSlayer derivative that plays Chess with Different Armies for this, because it already implemented selecting pieces for participation from a long list of possibilities. Originally I thought it would not be possible to make KingSlayer play Musketeer Chess, because of its piece(-type) encoding: it used the '8'-bit to indicate the piece color, so that only 7 low-order bits were available for indicating the piece type. (For Chess with Different Armies this was enough, as each army there has 6 piece types, just like in FIDE (which is actually one of the armies), albeit rather strange types.) After allowing for an empty square, this only left room for 7 piece types, and Musketeer Chess needs 8. But I discovered there was not much harm in using the '16'-bit for piece encoding as well; that the numbering of types of the same color is not consecutive, but that white codes now are 0-7 (empty and FIDE) plus 16-23 (Musketeer) had no adverse effects. I always use codes 16 and 17 (+8 for black) as the participating Musketeer types, and two codes in the range 18-23 for a 'combination piece' (i.e. the starting piece on a gating square).

[Ferdy]

I uploaded a new WinBoard-AA package: in the previous one promotions would not work for holdingless Seirawan, because WinBoard thought the promotion zone was in the 0th and 9th rank!

I also made the musky.exe in the Fairy-Max folder of that package now into a real Musketeer Chess engine, rather than just a demo for the prelude. That is, it seems to be able to play a human-engine game; I didn't test its (or WinBoard's) capabilities to play engine-engine Musketeer games yet.

Tried winboard-aa and musky, and still has a limited promotion options.

[hgm]

The promotion popup should really be considered deprecated, especially in variants. Each variant would need its own set of piece names, which in case of engine-defined variants are not even known to WinBoard, as only the IDs are. So I quickly gave up on that, and did not even provide alternative popups for any variant other than normal, Capablanca (where I could squeeze extra ArchBishop and Chancellor buttons in the existing dialog), Shogi (which just needed Yes and No) and Spartan Chess.) To offer all participating pieces as choice in any variant, I invented 'detour under-promotion' (-sweepPromotions true): this makes the dragged piece cycle through all eligeable types (based on the pieceToCharTable).

I now uploaded an update, where the engine is also able to play from a setup (initial) position. Parsing of the 0th and 9th FEN rank in that case replaces the prelude. This also allows switching to 'Two Machines' mode after the prelude (where the second engine then gets the position loaded through setboard), or after pasing a FEN into WinBoard.

[JohnWoe]

Great variant!

So I derived a Musketeer Chess960 engine from my Sapeli 1.67 engine.

I will publish the source codes really soon.

A sample game Capitaine versus Capitaine.
First both AIs selects pieces.
Here:
O = CHANCELLOR
C = CANNON
Then places them on pockets.
After that the game starts like normal chess game but pocket pieces enter the board at some point.

Code: Select all

... Game Over ...
[ Variant: Musketeer Chess960 ]
[ Think time: 1000 ]
[ Date: 25.12.2019 15:21:55 ]
[ White: Capitaine 0.10 ]
[ Black: Capitaine 0.10 ]
[ Result: { Draw 1/2-1/2 } ]
O C O@c0 O@d9 C@d0 C@c9 d1c3 d8e6 f2f3 c8d6 c1d3 b7b6 g1f2 g7g5 f1h1 a8b7 e2e4 g8g6 e4e5 d6f5 a2a3 f8h8 b1a2 e6d4 a2c4 c7c5 b2b3 d7d5 e5d6 e7d6 c3d5 c8d7 d5e3 d6d5 e3f5 d5c4 f5d4 c4d3 d4b5 d7d5 a3a4 d3c2 d1c2 d5f4 a1c3 a7a6 b5a3 f4f2 f1f2 e8e1 c1e1 f8e8 f2e2 e8e2 e1e2 d8e6 e2e6 f7e6 d2d3 g5g4 f3g4 g6g4 c2e1 g4f5 e1e3 f5h5 g2g3 h5d1 g1f2 d1b3 a3c4 b8c7 c4b2 b6b5 a4b5 a6b5 f2e2 e6e5 b2d1 b3e6 c3b2 b5b4 d1f2 e6b3 b2c1 b3b1 e3d2 b1a2 f2e4 c5c4 e2e1 c4c3 d2e2 b7e4 e2e4 a2h2 e4f3 h2g1 f3f1 g1f1 e1f1 b4b3 c1e3 b3b2 f1e2 b2b1d g3g4 b1d3 e2d3 e5e4 d3c3 c7e5 c3c4 h7h5 g4h5 g8f7 h5h6 e5d4 e3d4 e4e3 d4e3 f7f6 h6h7 f6f5 h7h8d f5g4 h8e5 g4h4 e3g5 h4h3 c4d5 h3g2 d5e4 g2f1 e4d3 f1g2 d3e4 { Draw 1/2-1/2 }

Capitaine also searches before gated pieces:

Code: Select all

./capitaine -search 10000
info depth 0 nodes 3039 time 12 nps 253250 score cp -8 pv C
info depth 1 nodes 14372 time 42 nps 342190 score cp 8 pv C
info depth 2 nodes 56882 time 173 nps 328797 score cp -8 pv D
info depth 3 nodes 157059 time 353 nps 444926 score cp 8 pv D
info depth 4 nodes 354881 time 568 nps 624790 score cp -5 pv C
info depth 5 nodes 1858116 time 1953 nps 951416 score cp 8 pv D
info depth 6 nodes 5691798 time 5099 nps 1116257 score cp 1036 pv D
info depth 7 nodes 11819895 time 10000 nps 1181989 score cp 1036 pv D

It works pretty fine:
Benching normal chess positions like this: Disable gated pieces with L- etc

Code: Select all

./capitaine -bench
> Benchmarking ( 15s ) ...

[ 1: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR[A-a-C-c-] w KQkq - ]
info depth 0 nodes 1068 time 5 nps 213600 score cp 16 pv g1f3
info depth 1 nodes 27332 time 86 nps 317813 score cp 5 pv e2e3
info depth 2 nodes 165113 time 299 nps 552217 score cp 7 pv g1f3
info depth 3 nodes 227488 time 365 nps 623254 score cp 7 pv g1f3
info depth 4 nodes 405835 time 518 nps 783465 score cp 7 pv g1f3
info depth 5 nodes 1109430 time 1020 nps 1087676 score cp 6 pv g1f3
info depth 6 nodes 2660967 time 2199 nps 1210080 score cp 11 pv g1f3
info depth 7 nodes 6252305 time 5000 nps 1250461 score cp 11 pv g1f3

[ 2: 3k4/3pp3/8/8/8/8/3PP3/3K4[A-a-C-c-] b - - ]
info depth 0 nodes 18 time 0 nps 0 score cp 5 pv d8c7
info depth 1 nodes 92 time 0 nps 0 score cp 5 pv d8c7
info depth 2 nodes 606 time 0 nps 0 score cp 2 pv e7e5
info depth 3 nodes 1244 time 0 nps 0 score cp 4 pv e7e5
info depth 4 nodes 3179 time 1 nps 3179000 score cp 0 pv d7d6
info depth 5 nodes 6389 time 2 nps 3194500 score cp 5 pv e7e5
info depth 6 nodes 15085 time 4 nps 3771250 score cp -1 pv e7e5
info depth 7 nodes 23241 time 6 nps 3873500 score cp 4 pv e7e5
info depth 8 nodes 52039 time 14 nps 3717071 score cp 7 pv e7e5
info depth 9 nodes 85832 time 23 nps 3731826 score cp 7 pv e7e5
info depth 10 nodes 243660 time 62 nps 3930000 score cp 5 pv e7e5
info depth 11 nodes 441502 time 108 nps 4087981 score cp 6 pv e7e5
info depth 12 nodes 1574137 time 382 nps 4120777 score cp 2 pv e7e5
info depth 13 nodes 2569662 time 623 nps 4124658 score cp 6 pv e7e5
info depth 14 nodes 5647787 time 1326 nps 4259266 score cp 3 pv e7e5
info depth 15 nodes 9738376 time 2323 nps 4192154 score cp 5 pv e7e5
info depth 16 nodes 21237201 time 5000 nps 4247440 score cp 5 pv e7e5

[ 3: k7/7p/8/8/8/8/6P1/K7[A-a-C-c-] b - - ]
info depth 0 nodes 12 time 0 nps 0 score cp 14 pv a8b7
info depth 1 nodes 95 time 0 nps 0 score cp 4 pv a8b7
info depth 2 nodes 255 time 0 nps 0 score cp 5 pv a8b7
info depth 3 nodes 814 time 0 nps 0 score cp 10 pv h7h5
info depth 4 nodes 1228 time 0 nps 0 score cp 8 pv h7h5
info depth 5 nodes 2252 time 0 nps 0 score cp 10 pv h7h5
info depth 6 nodes 4407 time 1 nps 4407000 score cp 6 pv h7h5
info depth 7 nodes 8339 time 1 nps 8339000 score cp 10 pv h7h5
info depth 8 nodes 17563 time 3 nps 5854333 score cp 4 pv h7h5
info depth 9 nodes 34751 time 7 nps 4964428 score cp 8 pv h7h5
info depth 10 nodes 66953 time 13 nps 5150230 score cp 6 pv h7h5
info depth 11 nodes 135911 time 27 nps 5033740 score cp 6 pv h7h5
info depth 12 nodes 270232 time 56 nps 4825571 score cp 6 pv h7h5
info depth 13 nodes 529184 time 117 nps 4522940 score cp 6 pv h7h5
info depth 14 nodes 1077813 time 254 nps 4243358 score cp 3 pv h7h5
info depth 15 nodes 2706850 time 695 nps 3894748 score cp 3 pv h7h5
info depth 16 nodes 6414428 time 1683 nps 3811306 score cp 0 pv h7h5
info depth 17 nodes 14670742 time 4100 nps 3578229 score cp 0 pv h7h5
info depth 18 nodes 17934853 time 5000 nps 3586970 score cp 0 pv h7h5

= nodes 45424359 mnps 3.028 time 15.000 depth 41

[JohnWoe]

Took me quite a while to get used to Musketeer chess but now it's pretty clear. There is 10 additional pieces to implement

My engine Capitaine is Chess960. Should I remove chess960 castling from that and simplify the engine even more? As those gated pieces already create lots of randomness?

Here is Capitaire perft from standard starting position:
First: Negotions.
Second: Placing pieces.
Then: Start counting.

Code: Select all

./capitaine -perft 9
> Perft ( 9 ) ...

depth 0 nodes 1 mnps 0.000 time 0.000
depth 1 nodes 10 mnps 0.000 time 0.000
depth 2 nodes 90 mnps 0.000 time 0.000
depth 3 nodes 720 mnps 0.000 time 0.000
depth 4 nodes 5760 mnps 0.000 time 0.000
depth 5 nodes 37440 mnps 37.440 time 0.001
depth 6 nodes 262080 mnps 29.120 time 0.009
depth 7 nodes 5241600 mnps 12.879 time 0.407
depth 8 nodes 104832000 mnps 12.493 time 8.391
depth 9 nodes 2333036160 mnps 12.421 time 187.823

= nodes 2443415861 mnps 12.426 time 196.631

[musketeerchess]

Hi Toni
Nice work

Please try to make your engine compatible with Winboard and that engine vs engine games be automatic without need for human hands.

Also the 960Chess isn’t neede. There is variety in Musketeer Chess without hurting the beauty of the initial position in Chess which is not the case of chess960

Regards

Zied