Musketeer Chess Variant pieces available at HouseofStaunton

[Ferdy]

You are right.

An engine tournament with at least 8 participants will be funded of 250 usd for the winner, 150 usd for the 2nd, 100usd for the third and 50usd for each participant.

This tournament must be held online (the easiest way is to use winboard).

The tournament should be in Blitz format which will allow to make a triple round-robin tournament.

That one is interesting without tournament it's boring . Problem is we don't have enough participants.

[musketeerchess]

Hi
There must be a few engines at least
Sothat it becomes an interesting tournament.

[Evert]

Hi
There must be a few engines at least
Sothat it becomes an interesting tournament.

Well, Sjaak II can play it as long as using Seirawan gating rules counts.
In fact, it can handle all of the possible pieces that are listed on the website, not just the Leopard and the Cannon (but you can't enable all of them because then the holding size is too large for XBoard, so most are disabled when playing through XBoard).

[musketeerchess]

Hi
i'm interested in testing your engine.

Can you mail me the engine with instructions of installation to musketeerchess @ gmail.com

Thanks

[hgm]

(but you can't enable all of them because then the holding size is too large for XBoard, so most are disabled when playing through XBoard).

Indeed, this is an annoying problem. It also crops up in Wa Shogi, which has 16 piece types that could get into the hand, and only an 11x11 board. The kludge solution is to define it as an 11x16 board with the upper 5 ranks blacked out. Quite ugly, though. Double-column holdings would also be awkward, as XBoard uses the blacked-out column between the board and holdings to hold and display the counts. So you would need an extra blacked-out coulumn too, so you end up with (11+8)x11, which is hardly an improvement over (11+4)x16.

Perhaps a solution is to allow holdings both next to and above/below the board? Pieces that map to holding squares larger than the number of board ranks could then be re-mapped to the top/bottom holdings. Would require a lot of code changes in XBoard, though. And for only Wa that seems hardly worth it. (Although now that I have studied the Wa rules better, is seems to me that Wa with drops could be a very good game.)

For Seirawan-type games this is really unfortunate, as captured pieces do not go to the holdings there, so that space reserved for the types initially not in hand is wasted space. The assignment of holdings square to piece type is done by a function PieceToNr in XBoard (which was already a big improvement over using the internal piece code itself, which was initially done, as now it can ignore piece types disabled in the pieceToCharTable). So PieceToNr could be made to check for variant seirawan, and work different in that case. But how could it know which pieces to skip? Internally it could have an array of booleans that for each piece type tells if it requires holding space, and I guess this could be set from the holdings in the setup FEN in seirawan-type games.

Note that for Musketeer dumping all exo-pieces into the holdings initially is not really what you want, as the user could then gate all of them. And even if you restricted the number of gatings, they could decide to gate different sets of pieces. Preselection of which two types you will be allowed to gate is still an essential part of the rules here, even if you do away with preselection of where they are allowed to be gated. So I don't really think that Musketeer would need such an extended holdings.

The best way to set up a tourney would be to play multiple games per pairing, with each possible pre-selection of piece types. E.g. if there are 6 exo-pieces, this makes 6*5/2 = 15 possible pairs, and you could play 2x15 games per pairing to try them all. If that is too much, one could make a selection of the pairs. The various choices of which piece types participate basically define sub-variants.

Fairy-Max should have little problems in being configured for playing each of these sub-variants as a different game. It would just be a matter of re-defining the move of the Hawk and Elephant in Seirawan Chess (which it already plays) to that of the Musketeer pieces that should participate, and all these piece types are within the capabilities of Fairy-Max' generic move generator.

[Evert]

Hi
i'm interested in testing your engine.

Can you mail me the engine with instructions of installation to musketeerchess @ gmail.com

Thanks

I'll try to do a release this weekend, but it may be early next week, depending on how much time I have for it this weekend and what type of issues I run into.

Don't expect much though; Sjaak II is not a strong engine and its opening play in particular is pathetic (it actually looks worse than I remember, so I may have broken something). It does play a load of different variants though.

[Evert]

Note that for Musketeer dumping all exo-pieces into the holdings initially is not really what you want, as the user could then gate all of them. And even if you restricted the number of gatings, they could decide to gate different sets of pieces. Preselection of which two types you will be allowed to gate is still an essential part of the rules here, even if you do away with preselection of where they are allowed to be gated. So I don't really think that Musketeer would need such an extended holdings.

The problem is really the pieceToChar string: ideally, I would leave all piece types in there and let the initial position determine which of them participate. This doesn't work though because having all pieces defined in pieceToChar blows up the holding size.

[hgm]

The problem is that the pieceToChar string is also used for defining promotion choice. So it is legitimate to have pieces in there that do not occur in the initial position (board + hand). In Team-Mate Chess this is actually used, as the Adjutant can only be obtained through promotion. Otherwise I could simply have XBoard delete all pieces not in the initial position from the pieceToCharTable.

@Zied: I see the move of the fortress was changed?
Beware that the diagram on your website for the Archbishop is missing one x, in the upper-right corner.

[Evert]

The problem is that the pieceToChar string is also used for defining promotion choice. So it is legitimate to have pieces in there that do not occur in the initial position (board + hand). In Team-Mate Chess this is actually used, as the Adjutant can only be obtained through promotion. Otherwise I could simply have XBoard delete all pieces not in the initial position from the pieceToCharTable.

It's not a simple problem.
Since this is an engine-defined variant anyway, I could
add a token to the rule description to tell Sjaak II to filter the pieceToChar it sends to XBoard for pieces that occur in the initial position. Because XBoard then doesn't have full information on what pieces participate this would make it impossible to setup a position thought XBoard though (it could still be done by adding a "startup FEN:" input field to Sjaak II's engine options dialog box, but it's not very pretty)...

@Zied: I see the move of the fortress was changed?
Beware that the diagram on your website for the Archbishop is missing one x, in the upper-right corner.

Ah, good point: I remember that there was a reason I couldn't implement the Fortress at all, but with the currently listed move it's no problem.

[hgm]

I think the most sensible approach is to treat them as different variants. The engine would have to know anyway that you are not allowed to promote to piece type Z if X and Y where the only pieces you had in hand at the start of the game, which makes treatment as a single variant containing all possible pieces difficult. A similar problem occurs in Chess with Different Armies. In Fairy-Max I use an engine-defined combo option to select the actual armies.

I guess having options that only have a meaning for one particular variant is also rather unsatisfactory.