Engines playing Musketeer Chess, good price

[musketeerchess]

Hi

I’m Dr Haddad, chess fun and inventor of many chess variants.

Take a look at www.musketeerchess.net

This is an offer for the programmers.

My goal is the following:

Organise an annual [to begin] Tournament using winboard or another UCI compatible GUI.

The tournament should involve a minimum of 6 different engines.

Source code must be provided to avoid clones, the only participant with stockfish musketeer is @ianfab or @ddugovich in the official tournament but clones can compete for other prices, the clone should be identifiable and changes from original engine explained clearly.

Winner 1500$
2nd 1000$
3d 500$

Each participant with working engine without easily identifiable bugs 200$

The methodology to gate choice of the additional pieces etc should be agreed between programmers when we decide beginning of the tournament. Naturally i will be involved in this.

PRICES Payment method Paypal.

Additional 750$ for the programmer that can provide a GUI newly developed and that can use classic stockfish and musketeer stockfish.

Mail musketeerchess (a) gmail.com

[hgm]

One of the complicating features of Musketeer Chess is that each game starts with a 'prelude', where the players take turns to negociate an 'initial position' from which the normal play then starts. In Musketeer Chess this involves picking two participating piece types, and the files on which these can be 'gated' onto the board.

For engine-engine play this only raises the issue of how these choices should be encoded when the GUI relays them from one engine to the other as if they were real moves. But for human-engine play an interface should be provided to make their choices known to the GUI. One way to do this would be through a pop-up dialog where the user can type the choice (e.g. the ID of the chosen piece, or the letter of the file where it gates) in response to a question. WinBoard already supports this feature (invoked by the CECP 'askuser' command). This is not very user-friendly, though; it would be much nicer if the user could select the piece by being shown a chess board that has all pieces that can be chosen on it, and then merely has to clcik on the one he wants. And click on the square where it should be gated later in the game.

But these choosing clicks are then not actual chess moves, and the position presented to the user for making these choices might bear no relation to the eventual initial position (although it will affect the latter). E.g. for choosing a piece type all 10 Musketeer pieces would have to be presented (for black and white) on the board, while actual play will start from the FIDE setup plus the two chosen pieces off board. Of course the choices could be disguised as normal moves, e.g. for choosing a piece you have to make an arbitrary move with it rather than just clicking it, and to choose a gating file you have to make a move that ends on that file (or perhaps occupy all gating-square candidates with Pawns, which the user then would have to move away to select the square). But that still would be kludgy, and rather confusing to the user.

Now WinBoard already has a number of features that could be put to good use for implementing such a dialog. If the engine has sent feature highlight=1 at startup, it will receive a 'lift' command whenever the user selects a piece (by clicking on it). The original purpose of that was to allow the engine to send a 'highlight' command to the GUI, telling it where the selected piece can move to. In the prelude phase the engine could consider the piece identified by this 'lift' command to define the user's piece-type choice.

Engines can also send 'setup' commands, to make the GUI set up an arbitrary position. These are currently only accepted at the start of a game in an engine-defined variant, and only the first one would be accepted, after which WinBoard's variant setting is no longer 'unknown', and further 'setup' commands would be ignored. This could be made more versatile by defining a new (pseudo-)variant 'prelude', in which 'setup' commands are also accepted. The first 'setup' commands could then change the variant from 'unknown' to 'prelude', and the engine could follow it up with as many other 'setup' commands as it wants, until the final one changes the variant from 'prelude' to what it needs to be. As each 'setup' command (re-)defines both the list of participating pieces and the board position, the engine can use this to present a number of arbitrary boards to the user in response to the 'lift' commands. E.g. it first shows a board that has white Musketeer pieces of all 10 types on it. When the user clicks one, in response to the 'lift' command this generates, it then shows a board with 8 times the selected piece on the 1st rank, and 8 times its own choice on the 8th rank (so the user knows what piece type the engine selected). The user can then click one of these 8 pieces to identify its gating square. The engine replies to the corresponding lift command with a 'setup' containing a board that has the already chosen gating square empty, and a white version of the piece selected by the engine on the 7 other 1st-rank squares. And a black version of the piece chosen by the user on the (8th-rank) gating square the engine has chosen for that. When the user finally clicks the gating square for this second piece, a 'setup' command defines the negociated initial position and participating pieces, and the game can start with an ordinary move (as the engine now ignores further 'lift' commands).

So from the engine side the whole thing boils down to sending a number of 'setup' commands in response to the first three 'lift SQR' commands.

[musketeerchess]

Hi HG

I think i’m going to ease things for engine contests. White will make his choice then black choses from remaining 9 possibilities. Programmers should give the possibility to define a default combination in parameters of their engine which will ease the tournament organisation and keep it fair as the engines will begin with the same default combination of additional pieces.

During the tournament the choice of the default combination will be subject to change from round to round. And each mini match will be at least 16 games with black and the same with white vs each opponent.

[hgm]

Note that engines tend to play rather deterministic, so usually engine tourneys force game diversity by starting the games from a forced opening line from a book. Even if it is just a book of random moves for lack of any real theory. But in the case of Musketeer Chess that would mean the prelude will always be played from the book, and never by the engines themselves. If the book in this respect was just randomly picking pieces and gating squares, the whole point of taking turns on this evaporates, and the complex negociation procedure might as well have been replaced by just loading preselected initial positions from after the prelude. (Something that all GUIs and engines already support...)

That being said, it seemed an interesting challenge to support such preludes in WinBoard through the existing protocol commands. This required only minimal changes in the way WinBoard handles these commands. So rather than accepting only a single board position (from which the game would then start) from the engine once a variant gets selected, the engine can now send as many board as it wants, by specifying parent variant 'prelude' in the 'setup' commands. When finally a 'setup' command arrives that specifies another parent variant than 'prelude', the board in it will be used as start position. The preceding boards can then all be 'graphical menus' for selecting something.

I modified my engine KingSlayer to announce that it plays variant 'musketeer', and implemented the Musketeer Chess prelude in it for selecting pieces and gating squares. (After that it stops, as it was lying about being abe to play Musketeer Chess; it just goes on as a game of normal Chess without ever gating any of the selected Musketeer pieces onto the board.) The first board it shows after 'New Game' is



from which white can then select the first Musketeer piece by clicking on it. After two more boards for selecting the gating squares (which at the same time show what the opponent has chosen in terms of pieces and gating squares), the negociated initial position of the game appears:



(BTW, screenshots are from XBoard, not WinBoard.)

The code in the engine that does this is:

Code: Select all

int engineSide=NONE;         // side played by engine
char inBuf[80];
int prelude[6], preptr, lastPrinted = -1, variant;
char *whitePieces = "ACDEF00/0HLMSU";
char *blackPieces = "acdef00/0hlmsu";
char *ptc = "PNBRQ.EA...C..F.MHDSULKpnbrq.ea...c..f.mhdsulk";

int
Prelude ()
{
  char buf1[80], buf2[80], buf3[80], w, b; int i;
  if(preptr < 6 && engineSide == (preptr & 1 ? BLACK : WHITE)) { // engine's turn to pick something
    do {
      prelude[preptr] = (preptr < 2 ? 10 : 8) * (rand() & 0xFFF) >> 12; // pick it
    } while(preptr == 1 ? prelude[0] == prelude[1]                      // retry if same piece
                        : prelude[preptr] == 4 ||                       // or gating under King
                          preptr == 5 && prelude[5] == prelude[3]);     // or on same square
    preptr++;
  } else if(preptr == lastPrinted) return (preptr < 6);
  // now it is always the user's turn to pick something (or move)
  w = whitePieces[prelude[0] + 4*(prelude[0] > 4)];
  b = blackPieces[prelude[1] + 4*(prelude[1] > 4)];
  switch(preptr) {
    case 0: // present all white pieces
      strcpy(buf1, whitePieces);
      printf("setup (%s) 8x8+0_prelude 8/8/8/0%s00/8/8/8 w - - 0 1\n", ptc, buf1);
      break;
    case 1: // present all black pieces except the white choice
      strcpy(buf1, blackPieces);
      buf1[prelude[0] + 4*(prelude[0] > 4)] = w;
      printf("setup (%s) 8x8+0_prelude 8/8/8/0%s00/8/8/8 w - - 0 1\n", ptc, buf1);
      break;
    case 2: // white choice fills 1st rank, black choice fills 8th
      for(i=0; i<8; i++) buf1[i] = w, buf2[i] = b; buf1[8] = buf2[8] = 0;
      printf("setup (%s) 8x8+0_prelude %s/8/8/8/8/8/8/%s w - - 0 1\n", ptc, buf2, buf1);
      break;
    case 3: // white choice on its gating square, black choice fills 8th rank
      for(i=0; i<8; i++) buf1[i] = '0', buf2[i] = w + 32; buf1[8] = buf2[8] = 0;
      buf1[prelude[2]] = w;
      printf("setup (%s) 8x8+0_prelude %s/8/8/8/8/8/8/%s w - - 0 1\n", ptc, buf2, buf1);
      break;
    case 4: // whitened black choice on remaining 5-7 1st-rank squares, blackened white choice on its gating square
      for(i=0; i<8; i++) buf1[i] = b - 32, buf2[i] = '0'; buf1[8] = buf2[8] = 0;
      buf2[prelude[3]] = w + 32; buf1[prelude[2]] = w + 32;
      if(prelude[2] == 4) buf1[0] = buf1[7] = '0'; if(prelude[2] == 0 || prelude[2] == 7) buf1[4] = '0'; // no K & R
      printf("setup (%s) 8x8+0_prelude %s/8/8/8/8/8/8/%s w - - 0 1\n", ptc, buf2, buf1);
      break;
    case 5: // both whitened pieces on their gating squares, blackened white choice on 7, 6 or 5 remaining 8th-rank squares
      for(i=0; i<8; i++) buf1[i] = '0', buf2[i] = b; buf1[8] = buf2[8] = 0;
      buf2[prelude[3]] = w + 32; buf1[prelude[2]] = w; buf1[prelude[4]] = b - 32;
      if(prelude[3] == 4) buf2[0] = buf2[7] = '0'; if(prelude[3] == 0 || prelude[3] == 7) buf2[4] = '0'; // no K & R
      printf("setup (%s) 8x8+0_prelude %s/8/8/8/8/8/8/%s w - - 0 1\n", ptc, buf2, buf1);
      break;
    case 6:
      strcpy(buf3, ptc);
      for(i=5; i<22; i++) if(ptc[i] != w && ptc[i] != b - 32) buf3[i] = buf3[i +23] = '.';
      for(i=0; i<8; i++) buf1[i] = '*', buf2[i] = '*'; buf1[8] = buf2[8] = 0;
      buf2[prelude[3]] = w + 32; buf2[prelude[5]] = b; buf1[prelude[2]] = w; buf1[prelude[4]] = b - 32;
      printf("setup (%s) 8x10+0_fairy %s/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/%s w KQkq - 0 1\n", buf3, buf2, buf1);
  }
  lastPrinted = preptr;
  return (preptr < 6);
}

(Not yet quite what a real Musketeer engine would need, as it finally ends up in parent variant 'fairy', which doesn't allow for any gating.) This routine Prelude() is called at the point where the engine would normally decide whether it would have to start thinking (based on engineSide and the side to move), but if it returns 1 to indicate we are still in the prelude, this thinking will be suppressed. When it is the engine's turn to pick something, it picks randomly here; of course a special search could be preformed here in order to attempt making the best choice. (I cannot really imagine that any advantage can be derived from chosing the piece types, but perhaps choosing a gating square does matter.)

This whole negociation procedure is basically invisible to WinBoard: the various choices are not counted as moves, and the game acts like it was started from the resulting position. E.g. when it is later saved as PGN it gives:

Code: Select all

[Event "Computer Chess Game"]
[Site "hgm-xboard"]
[Date "2019.12.15"]
[Round "-"]
[White "hgm"]
[Black "Simple 0.00"]
[Result "*"]
[TimeControl "40/600"]
[Variant "musketeer"]
[FEN "ml******/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/**L*M*** w KQkq - 0 1"]
[SetUp "1"]

{--------------
m l . . . . . .
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
. . L . M . . .
white to play
--------------}
1. d4 d5 {-0.04/13 16}
*

[hgm]

I now also implemented 'holdingless Seirawan Chess' in WinBoard. Variant seirawan is unique in that it allows gating, but normally the pieces that can be gated are displayed left and right of the board in the holdings. When the user wants to gate them in he then first selects the piece to be gated, and then moves away the gating piece from the back rank. Without holdings this obviously cannot be done.

So WinBoard now redefines the meaning of the first and final board rank to be a kind of holdings rather than part of the board, if the true holdings are absent. Difference is that each square in those ranks is now a holdings exclusively for gating on the file it is on (i.e. on the square just before it). Empty squares of these pseudo-holdings are blacked out, and each of them can only hold a single piece (but of any type). If there is something on that holdings square, it is automatically gated when the user moves away the (virgin) piece before it. Engines (or typed moves) still have to indicate that the move is a gating, through the promotion suffix.

This should allow Musketeer Chess to be played as an engine-defined variant with parent variant 8x8+0_seirawan.

[musketeerchess]

I now also implemented 'holdingless Seirawan Chess' in WinBoard. Variant seirawan is unique in that it allows gating, but normally the pieces that can be gated are displayed left and right of the board in the holdings. When the user wants to gate them in he then first selects the piece to be gated, and then moves away the gating piece from the back rank. Without holdings this obviously cannot be done.

So WinBoard now redefines the meaning of the first and final board rank to be a kind of holdings rather than part of the board, if the true holdings are absent. Difference is that each square in those ranks is now a holdings exclusively for gating on the file it is on (i.e. on the square just before it). Empty squares of these pseudo-holdings are blacked out, and each of them can only hold a single piece (but of any type). If there is something on that holdings square, it is automatically gated when the user moves away the (virgin) piece before it. Engines (or typed moves) still have to indicate that the move is a gating, through the promotion suffix.

This should allow Musketeer Chess to be played as an engine-defined variant with parent variant 8x8+0_seirawan.

Great

[hgm]

I included the fake Musketeer Chess engine, which only does the prelude, now in the WinBoard-AA package, which also contains the updated WinBoard executable. It should be possible to select that engine from the Startup Dialog comboboxes under the name 'Musky', and then use the New Variant dialog to select 'musketeer'. This would bring you into the prelude dialog for the white player (as WinBoard assumes by default after New Game that a human wants to play with white against the first engine).

Perhaps you can check if you like the boards I have chosen to allow selection of the piece and gating squares. To see how these selection boards look for the black player, you can select Mode->Machine White after New Game. Basically these boards can be made to look anyway you want, except that only clicks on pieces of the player's own color will be relayed to the engine (and can thus be used to select something).

[Ferdy]

I included the fake Musketeer Chess engine, which only does the prelude, now in the WinBoard-AA package, which also contains the updated WinBoard executable. It should be possible to select that engine from the Startup Dialog comboboxes under the name 'Musky', and then use the New Variant dialog to select 'musketeer'. This would bring you into the prelude dialog for the white player (as WinBoard assumes by default after New Game that a human wants to play with white against the first engine).

Perhaps you can check if you like the boards I have chosen to allow selection of the piece and gating squares. To see how these selection boards look for the black player, you can select Mode->Machine White after New Game. Basically these boards can be made to look anyway you want, except that only clicks on pieces of the player's own color will be relayed to the engine (and can thus be used to select something).

That is nice. Regarding board colors not really a big issue but I think the H1A8 diagonal should have a light color (see ref.) the same as in normal chess.



Ref.: https://musketeerchess.net/games/musket ... -short.php

So basically a seirawan on 8x10 without holding and parent fen is also different.
8x10+0_seirawan *d***s**/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/*S**D*** w KQBCDFGkqbcdfg - 0 1

[hgm]

As to the square colors: you are right, of course; I never pay attention to absolute colors. This is simply a matter of configuring the board theme, swapping the texture bitmaps for the light and dark squares. I suppose people that want to play Musketeer would want to use their own piece images anyway (as the on-line Board Painter tool has them), so they would also have to specify another piece-image directory. Here I just used XBoard's default piece set, using Lance for Dragon=Amazon, Snake for Spider, Lion for Leopard, Crowned Rook for Fortress.

As to the FEN: indeed, that is what I currently use. Note that the virginity indicators for the ranks without gating piece can be safely omitted. I am still wondering whether I should not make a special FEN standard for 'holdingless Seirawan' (or even whether it should not be a variant of its own, say 'gating'). On Variant-Stockfish Github I once proposed to treat Musketeer FENs as if the gating and gated piece were initially 'stacked', and use parentheses for indicating a square with a stack of pieces on it. E.g. (NC) for a square that contains a Knight with a Cannon 'under it' (so that moving the Knight will expose the Cannon). That would mean the FEN could be ordinary 8x8, without any need for encoding virginity other than what is relevant for castling, as the fact that the stack is still there implies it is virgin. After capture the entire stack disappears, and on moving it splits up.

[musketeerchess]

Hi Ferdinand and HG

Great to see both of you here.

FERDY POINTED THE COLOUR ISSUE EASILY FIXED.

Both the FEN systems that HG mentioned for the additional pieces seem ok. In fact its necessary for engine vs engine matches. The choice should be probably for an 8x10 fen as it will easy research for better gating strategies for the fairy pieces.

But for first tournaments the standard FEN seems ok too as the positions will be predetermined

As to the square colors: you are right, of course; I never pay attention to absolute colors. This is simply a matter of configuring the board theme, swapping the texture bitmaps for the light and dark squares. I suppose people that want to play Musketeer would want to use their own piece images anyway (as the on-line Board Painter tool has them), so they would also have to specify another piece-image directory. Here I just used XBoard's default piece set, using Lance for Dragon=Amazon, Snake for Spider, Lion for Leopard, Crowned Rook for Fortress.

As to the FEN: indeed, that is what I currently use. Note that the virginity indicators for the ranks without gating piece can be safely omitted. I am still wondering whether I should not make a special FEN standard for 'holdingless Seirawan' (or even whether it should not be a variant of its own, say 'gating'). On Variant-Stockfish Github I once proposed to treat Musketeer FENs as if the gating and gated piece were initially 'stacked', and use parentheses for indicating a square with a stack of pieces on it. E.g. (NC) for a square that contains a Knight with a Cannon 'under it' (so that moving the Knight will expose the Cannon). That would mean the FEN could be ordinary 8x8, without any need for encoding virginity other than what is relevant for castling, as the fact that the stack is still there implies it is virgin. After capture the entire stack disappears, and on moving it splits up.