Comment on FEN format

[fsmosca]

I just use the format similar to seirawan chess i.e the castle field also include the virgin files. Example for Unicorn/Hawk combo on startpos.

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR[HUhu] w KGFDCBQkgfdcbq - 0 1

In this example, white can gate a Hawk or Unicorn on files a, b, c, d, e, f, g, h. The K is for castle king-side, for gating at e-file and gating at h-file. When a h-rook is moved, it could no longer castle king-side and it could no longer gate at h-file. If the king at e1 is moved, it could no longer castle in king-side and queen-side, and could no longer gate at e-file. WB (winboard) understand this as game progresses, and able to identify which squares/files are still virgins. The Q is similar for d-file and a-file.

The user can pre-select which file a fairy piece would gate thru the option, see the issue on "Comment on move format" When user selects the Hawk to gate at b-file, WB will inform the uci engine, setoption name WHawkFile value b-file The engine would then limit its move generation gating a piece at b-file.

[ianfab]

Thanks for your feedback.

The design of the interface was basically an ad-hoc solution, since I was not aware of any engine or GUI for Musketeer chess. On the one hand I like your idea of a workaround to make it work with Winboard, but on the other hand, I think it really is just a workaround and not an ultimate solution, since the design of the interface would be made to fit the GUI and not the game. The setup phase should be part of the gameplay and the move history, and not a configuration option.

For the FEN, I tried to find a format that contains all required information to continue a game from that position (i.e., being a full representation of the game state, apart from repetitions), while keeping the redundancy as small as possible. In case you have not seen it yet, there is a related thread at https://github.com/ddugovic/Stockfish/issues/506.

Regarding the one-letter representation of the pieces, I just took what was suggested by Zied in the aforementioned thread. I do not have a strong preference, so if there is a consensus, I am of course open to changing them.

Maybe there could be a hybrid approach to support the workaround for Winboard as an alternative interface (e.g., via a UCI option) while keeping the current one.

[fsmosca]

Thanks for the link, just knew it.

I hope HGM would fully support musketeer in WB.

[HGMuller]

WinBoard now provides a way to play Musketeer Chess as an engine-defined variant, and I converted my engine KingSlayer to actually do this. But I haven't really changed anything in WinBoard's FEN parser and generator yet, so for the moment it uses a FEN that faithfully represents what it shows on the display, which is a board without holdings, and two extra ranks that are blacked out except for the gatable pieces. (Blacked-out squares are indicated as '*' in WinBoard's FEN system.)

As far as I am concerned this is not final, and we could agree here on a better system. I also haven't decided on any formal notation of the piece and gating-square selections in the 'prelude'; as far as WinBoard is concerned the prelude is not part of the game, and it starts running the clocks and counting moves only after all pieces are set up. (As I implemented Musketeer Chess as an engine-defined variant, the GUI receives the initial position from the engine in a 'setup' command, and KingSlayer 'negociates' this position in human-engine games in a way that is invisible to the GUI., while engine-engine games are simply starting from a position with given gating pieces and squares.)

I am still hesitant to accept the choice of participating pieces as part of the game; IMO it is more a pre-game negociation between the players about what (sub-)variant they want to play. As such I also doubt the necessity to encode the available promotion choices in the FEN. For one, FENs never represent the complete game state; this would require the entire game history, or at least all reversible moves leading up to the position. Without this you would not be able to recognize repetition draws. As far as I am concerned we could designate participating piece types (and thus available promotion choices) as another game-state aspect that is not encoded in the FEN, but has to follow from the game history. In UCI it is customary to send all moves from the very first position (even the irreversible ones), so it is sufficient that initial positions unambiguously show which pieces participate. Which Musketeer positions directly after the prelude do.

I don't want to meddle with UCI too much, but I would prefer it that the choices made in the prelude are not considered normal moves, but go into a separate (novel, oprional) section of the position-moves command. Like

position FEN prelude CHOICE1 CHOICE2 ... moves MOVE1 MOVE2 ...

This can also be seen as an 'extended FEN' that has the prelude field appended to a normal FEN. If the participating piece types and gating squares are already apparent from the specified FEN the prelude section can be omitted. For an end-game position where the additional types have already been captured, the prelude field can be used to specify the (additional) promotion choices.

The only additional task of the FEN is then to indicate the squares where pieces can be gated, and what will appear there. I still think the 'stacking notation' I proposed earlier would be best for this: a number of piece IDs in parentheses would indicate a 'stack' of pieces, i.e. an ordered set of pieces occupying the same square. In the case of Musketeer Chess the rule for such stacks would be that only the first ('upper') piece can be moved, and would leave the piece 'under' it behind as the gated piece. This system can even be used for describing game states within the prelude: the move-number field of the FEN being 1 would reveal we are dealing with a position in or directly after the prelude, and the number of pieces already stacked would indicate how far the prelude has progressed. There only is the matter of how to indicate the choice of piece types before any of the pieces of this type have been placed; we could adopt the convention that these coices are stacked under the opponent King. This could actually be a general convention for indication participating types that are currently not on the board (for the purpose of indicating promotion choice). Like

4(Ka)3/4P3/8/8/8/8/8/4(kC)3 w 0 43

for indicating a KPK position where promotion to Cannon and Archbishop is also allowed.

[fsmosca]

After some considerations, I like the jocly approach. I don't know how jocly represents FEN but below example is what I would suggest.

Show the initial board where a user can select pieces. Both white and black pieces are on the board, let the user move it at specific squares for a couple of initital moves, record it so game history is preserved. See illustrations below.

Initial board

image 1:

Piece id

L/l = Leopard C/c = Cannon U/u = Unicorn D/d = Dragon M/m = Chancellor A/a = Archbishop E/e = elephant H/h = Hawk F/f = Fortress S/s = spider

Upper case id: White color Lower case id: Black color

startfen

8/rnbqkbnr/pppppppp/3hemac/3lfdsu/LHEMA3/CFDSU3/PPPPPPPP/RNBQKBNR/8 w KQkq - 0 1 - -

Fields in fen

piece locations: 8/rnbqkbnr/pppppppp/3hemac/3lfdsu/LHEMA3/CFDSU3/PPPPPPPP/RNBQKBNR/8 side to move: w castling rights: KQkq e.p square: - halfmove clock: 0 fullmove number: 1 Musketeer pieces: - gating rights: -

The first 6 fields is basic fen, but in musketeer I like to extend it by appending the musketeer pieces and gating rights fields. See below example of how this is updated.

Legal moves from startfen

a3h3 b3h3 c3h3 d3h3 e3h3 a4h3 b4h3 c4h3 d4h3 e4h3

Example moves in a game

1 a3h3 image 2:

Black cannon is automatically selected and placed on that square.

fen: 8/rnbqkbnr/pppppppp/3hemac/3lfdsu/LHEMA3/1FDSU2C/PPPPPPPP/RNBQKBNR/8 b KQkq - 1 1 c - Musketeer pieces: c, where: c = cannon

Legal moves

d6a6 e6a6 f6a6 g6a6 d5a6 e5a6 f5a6 g5a6 h5a6 a5h6, black refuses white's choice, in this case the musketeer piece types will be cannon and leopard

1... e6a6 image 3:

White elephant is automatically selected and placed on that square.

fen: 8/rnbqkbnr/pppppppp/e7/c7/7E/7C/PPPPPPPP/RNBQKBNR/8 w KQkq - 2 2 ce - Musketeer pieces: ce, where: c = cannon, e = elephant

Legal moves

h3a0 h3b0 h3c0 h3d0 h3e0 h3f0 h3g0 h3h0

2 h3b0 image 4: fen: 8/rnbqkbnr/pppppppp/e7/c7/7E/8/PPPPPPPP/RNBQKBNR/1C6 b KQkq - 3 2 ce B Musketeer pieces: ce, where: c = cannon, e = elephant gating rights: B, white can gate at b file, upper case B is for white

Legal moves

a5a9 a5b9 a5c9 a5d9 a5e9 a5f9 a5g9 a5h9

2... a5d9 image 5: fen: 3c4/rnbqkbnr/pppppppp/e7/8/7E/8/PPPPPPPP/RNBQKBNR/1C6 w KQkq - 4 3 ce Bd Musketeer pieces: ce, where: c = cannon, e = elephant gating rights: Bd, white can gate at b file and black can gate at d file

Legal moves

h4a0 h4c0 h4d0 h4e0 h4f0 h4g0 h4h0

3 h4f0 image 6: fen: 3c4/rnbqkbnr/pppppppp/e7/8/8/8/PPPPPPPP/RNBQKBNR/1C3E2 b KQkq - 5 3 ce BdF Musketeer pieces: ce, where: c = cannon, e = elephant gating rights: BdF, white can gate at b and f files and black can gate at d file

Legal moves

a6a9 a6b9 a6c9 a6e9 a6f9 a6g9 a6h9

3... a6g9 image 7: fen: 3c2e1/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/1C3E2 w KQkq - 6 4 ce BdFg Musketeer pieces: ce, where: c = cannon, e = elephant gating rights: BdFg, white can gate at b and f files and black can gate at d and g files

Game notation from above sample move sequences

1. a3h3 e6a6 2. h3b0 a5d9 3. h4f0 a6g9

continue to illustrate the loss of gating right of a musketeer piece.

4. e2e4 f7f6 5. f1c4e {white gates its elephant} 5... b8c6 6. c4g8

image 8: fen: 3c2e1/r1bqkbBr/ppppp1pp/2n2p2/8/4P3/8/PPPP1PPP/RNBQKENR/1C6 b KQkq - 0 6 ce Bd

On gating rights, black has only d, its right at g is lost because the knight at g8 square was captured. The board still contains the black elephant but could no longer be gated.

Tracking what happens to the game is easier. Player preferences of pieces when white and black is traceable and can be used to generate opening stats.

FEN representation is easier to comprehend, 2 rows are added making it 10x8 and just append the 2 new fields for musketeer pieces and gating rights.

Piece selections and gating are similar to the rules at https://musketeerchess.net/games/musketeer/rules/rules-short.php

[HGMuller]

One problem with this is that moves like a3h3 and h3b0 are not ordinary moves, as they have side effects that can impossibly be foreseen by a GUI that is not specifically programmed for exact implementation of the Musketeer prelude: a3h3 makes a black piece pop up on a5, and h3b0 makes a whole bunch of pieces disappear. And for a GUI that knows all about Musketeer preludes, there is no need to encode piece selection as a normal move, and it would be much clearer to just give the piece ID as Stockfish does now. 'C' makes it pretty obvious that a Cannon is selected, but who would know what 'a3' means?

There also is much redundancy in your FEN proposal: there is no need to leave pieces on the extra ranks when their gating rights disappear through capture. Doing so allows the same game state to be encoded through different FENs (with dummy pieces on non-virgin files). If we would not allow non-gatable pieces there is no need at all for a virginity field: presence of the piece on the extreme rank would imply virginity of the piece in front of it. This is also how we would want a GUI to display it: as virginity is a game-state aspect that is not directly visible, presence of 'dead' pieces on the extreme ranks would be very confusing.

The only reason to allow non-gatable pieces in the FEN could be to indicate they can be used as promotion choice, but then the pieces field would be redundant. Even for describing the various phases of the prelude there is no need for it: if the full-move counter is advanced during the prelude, the selected pieces can simply be put somewhere on the board or on the extra ranks. The value of the full-move counter would unambiguously indicate that the pieces are not in their final place yet; they would only be there for counter values > 3. And if there was to be a separate FEN field for indicating the selected pieces without putting them on h3/h4/a5/a6 in the board array, the already existing holdings field would be the obvious choice for it.

A more pragmatic issue is that I don't see any practical application for communicating intra-prelude positions. I cannot imagine puzzles of the kind: "White picked an Elephant as the first Musketeer piece. Which piece is best to pick for black now?". So why design all kind of new conventions or notations to describe something no one would ever use?

[HGMuller]

Also note that if this is how you want the prelude to look in WinBoard, this can be achieved in a similar way as KingSlayer-Aramis conducts his own prelude. Provided the selections are not considered moves. You just must make sure the engine sends a 'setup' command in response to every 'lift' command, to prevent the user from ever entereing a complete move. (Reception of the 'setup' command clears the selected piece in WinBoard.) So if the user clicks a Cannon on your initial screen, you can immediately send a 'setup' that specifies a white Cannon on h3 and a black one on a6, without any need for the user to click h3 (and thus precluding he would try to move it somewhere else). If the user clicks a piece he is not supposed to move, you can see that from the 'lift' argument, and just re-send the 'setup' he was working on, to effectively ignore that click.

[fsmosca]

One problem with this is that moves like a3h3 and h3b0 are not ordinary moves, as they have side effects that can impossibly be foreseen by a GUI that is not specifically programmed for exact implementation of the Musketeer prelude

I am actually expecting you to support musketeer chess fully in winboard.

: a3h3 makes a black piece pop up on a5, and h3b0 makes a whole bunch of pieces disappear. And for a GUI that knows all about Musketeer preludes, there is no need to encode piece selection as a normal move, and it would be much clearer to just give the piece ID as Stockfish does now. 'C' makes it pretty obvious that a Cannon is selected, but who would know what 'a3' means?

See image 1 and startfen from my previous post, to see what is a3. After selecting musketeer variant, GUI will show the image 1 to select the musketeer pieces.

There also is much redundancy in your FEN proposal: there is no need to leave pieces on the extra ranks when their gating rights disappear through capture.

The reason it is there is because there is history in it.

For GUI, the appearance of a musketeer piece that could no longer be gated can be made to look like disabled or grayed out but something that is still visible. When the game is replayed, that piece is still there to remind a user what really had happened on that piece. This is good for illustration purposes especially for those people who are new to musketeer chess.

However if the fen just came out of nowhere, musketeer piece that loses the right to gate can be removed in the piece field.

A more pragmatic issue is that I don't see any practical application for communicating intra-prelude positions. I cannot imagine puzzles of the kind: "White picked an Elephant as the first Musketeer piece. Which piece is best to pick for black now?". So why design all kind of new conventions or notations to describe something no one would ever use?

I cannot exactly agree when you use the word prelude.

Meaning of prelude: an introductory performance, action, or event preceding and preparing for the principal or a more important matter https://www.merriam-webster.com/dictionary/prelude

But in musketeer chess the opening stage is very important.

1. Piece selection, this is where a player would choose its favorite piece, can be leopard or a more powerful dragon etc. and with 10 musketeer piece types to choose from, it would be difficult to know the details and how to use if effectively on the board on given pawn structure or opening and strategic themes, so the tendency is to choose a piece that one feels more comfortable - master its attacking and defensive potentials, knowing where to place that piece on the board effectively (and what file it will be gated to deploy it faster). Some players can be more comfortable with unicorn or hawk perhaps. Forget about the engine it has no feeling. There is also what we call opening preparation, if you know your opponent before the game, you might as well study the piece that he/she does not like, and you can select that piece.

2. Gating preparation, selecting what file (a, or b to h) the musketeer piece (selected in item 1) will be introduced on the board. This is also very important. Do you like fast attack (placing a musketeer piece behind a knight, and then play Nf3 or Nc3). The moment black sees that white has played a musketeer piece on a file behind a knight, there is going to be a tension already, black would calculate where to put his musketeer piece too. I played some games with it in jocly and that is not easy at all. A white unicorn or a hawk placed behind a knight is generally dangerous for black, one should start calculating even at this stage.

Musketeer chess is very rich on opening preparations. If my opponent handling the black pieces is an expert in sicilian defense, what piece should I choose (and where to gate it) to make his opening not so effective? Is cannon in the center bad in ruy lopez opening? Is the corner square better for dragon? Lots of questions can be raised on the opening preparation alone.

[HGMuller]

Sorry, the quoting didn't quite work as I expected, here, so my original posting was rather messed up. This is the second attempt:

I am actually expecting you to support musketeer chess fully in winboard.

With dedicated support there would be no need at all to encode choices as moves with artificial from- or to-squares.

See image 1 and startfen from my previous post, to see what is a3.

That is exactly the point. You would have to consult an image to know what it means. If you see C you know it is a Cannon without consulting anything. The protocol would be complicated by the need to specify a totally arbitrary mapping between piece types and board squares.

For GUI, the appearance of a musketeer piece that could no longer be gated can be made to look like disabled or grayed out but something that is still visible.

This would require a totally new functionality in the GUI, which would not serve any purpose in any other variant, while even the purpose here is of very debatable use: it is simiar to requiring that in Seirawan Chess a Hawk and Elephant should be kept on display at all times to remind you that you are not playing FIDE. IMO it is good enough if the user is shown at the time of promotion what he can promote to.

But all this is a bit beside the point: we were discussing FEN format, not what a GUI should display to the user. It is in general detrimental to allow the same game state to be represented by multiple FENs (e.g. for database lookup of the position). Which is exactly what displaying non-gatable pieces would do. The purpose of FENs is not to remind inexperienced users, but to encode (partial) game states.

I cannot exactly agree when you use the word prelude.

Well call it what you like. 'Prelude', 'intro', 'selection', 'choices', 'pow-wow', it is all the same to me. The point is that this is a phase that is completely different from what goes on in the remainder of the game. Turns do not consist of a single piece moving from one square to another. The kludge of making the choices by articial moves do not obey the normal rules for how these piece move. Turns there even affect the rules according to which the remainder of the game is to be played (promotion choice).

So I think that what happens in this phase of the game deserves a separate section, as it is neither position nor moves. Hence my proposal to extend the UCI position-moves command to a position-choices-moves for variants that involve such a phase. In Musketeer Chess the 'choices' section could then be used to relay the chosen piece types and their gating files. This would not significantly complicate the design of UCI engines compared to what Stockfish is doing now: it should just read the token 'choices' (or whatever) as 'moves', and ignore any second occurrence of 'moves' on the line.

As I said, this extra section could be thought of as belonging to the FEN, which would lead to a format very close to what you proposed, except that it has the extra keyword 'choices' in it between the normal FEN and the piece-type and gating-squares that are suffixed as an extension.

[fsmosca]

Sorry, the quoting didn't quite work as I expected, here, so my original posting was rather messed up. This is the second attempt:

I am actually expecting you to support musketeer chess fully in winboard.

With dedicated support there would be no need at all to encode choices as moves with artificial from- or to-squares.

See image 1 and startfen from my previous post, to see what is a3.

That is exactly the point. You would have to consult an image to know what it means. If you see C you know it is a Cannon without consulting anything. The protocol would be complicated by the need to specify a totally arbitrary mapping between piece types and board squares.

For GUI, the appearance of a musketeer piece that could no longer be gated can be made to look like disabled or grayed out but something that is still visible.

This would require a totally new functionality in the GUI, which would not serve any purpose in any other variant, while even the purpose here is of very debatable use: it is simiar to requiring that in Seirawan Chess a Hawk and Elephant should be kept on display at all times to remind you that you are not playing FIDE. IMO it is good enough if the user is shown at the time of promotion what he can promote to.

But all this is a bit beside the point: we were discussing FEN format, not what a GUI should display to the user.

I showed how the FEN will be represented in the GUI, this is why the musketeer piece that loses its gating right should not be removed in the FEN, so that the GUI can draw it.

I cannot exactly agree when you use the word prelude.

Well call it what you like. 'Prelude', 'intro', 'selection', 'choices', 'pow-wow', it is all the same to me.

Perhaps we can call it a piece selection phase (PSP), and gating preparation phase (GPP), placing the selected musketeer piece on a file behind the FIDE pieces.

The point is that this is a phase that is completely different from what goes on in the remainder of the game. Turns do not consist of a single piece moving from one square to another. The kludge of making the choices by articial moves do not obey the normal rules for how these piece move. Turns there even affect the rules according to which the remainder of the game is to be played (promotion choice).

So I think that what happens in this phase of the game deserves a separate section, as it is neither position nor moves. Hence my proposal to extend the UCI position-moves command to a position-choices-moves for variants that involve such a phase. In Musketeer Chess the 'choices' section could then be used to relay the chosen piece types and their gating files. This would not significantly complicate the design of UCI engines compared to what Stockfish is doing now: it should just read the token 'choices' (or whatever) as 'moves', and ignore any second occurrence of 'moves' on the line.

As I said, this extra section could be thought of as belonging to the FEN, which would lead to a format very close to what you proposed, except that it has the extra keyword 'choices' in it between the normal FEN and the piece-type and gating-squares that are suffixed as an extension.

I am not too concerned of engine and gui interfacing. I am more concerned of a human/user gui interfacing. A user has to be given the view of what is going on at the board from the very beginning. The recorded game has to be replayable, showing the PSP and GPP.

[HGMuller]

Perhaps we can call it a piece selection phase (PSP), and gating preparation phase (GPP), placing the selected musketeer piece on a file behind the FIDE pieces.

I don't think it is good to design a protocol in a way that is too specifically tailored for one variant. Other variants may need to select whole armies (e.g. Chess with Different Armies), shuffle some pieces (Metamachy), swap pieces between the hand and the board (Superchess). I wouldn't want different keywords for each of those, that would just unnecessarily complicate the protocol. I want just one new keyword that can be used to cover everything that is not normal game play. 'Preparation' would also be fine with me.

I am not too concerned of engine and gui interfacing. I am more concerned of a human/user gui interfacing.

That is fine, but completely off-topic here. This is a forum for the development of an eninge, in particular Stockfish. For the engine it is only important how it should communicate with the GUI. How the GUI interacts with the user is for the GUI developer to decide, and needs to have no similarity whatsoever to how it communicates with the engine. (E.g. SAN vs coordinate notation.)

The importance of FEN format slightly transcends that of the communication protocol, though, as PGN game records, which really need to be standardized, also use FEN.And there would be some benefit (although no strict necessity) to use the same format for communicating positions to the engine.

BTW, a format like

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 prep E C e b b g

seems to fit your requirement of replayability, if the data behind 'prep' is supposed to be ordered. Or the preparation phase could be detached from the FEN, and put in a separate FEN tag: [Prep "E C e b b g"]

[ianfab]

The problem with a format like rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 prep E C e b b g is that it still contains superfluous information, at least if this format is also used for communication with the engine, because the files are not required any more once the pieces are gated. The FEN format of Musketeer-Stockfish in principle is similar, it just gets rid of superfluous information about the game state history.

[musketeerchess]

Hi Ferdy, Ian, HG, all of you.

First i wanted to wish you a Happy New Year, full of good things (especially programming ideas).

I'm very happy to see all these interesting ideas. Here are a few points i share with you.

In terms of FEN Choice, themost important thing seems to be an easy enough process that eases engine vs engine matches in a standardised wat.

Next step: it would be great to see Musketeer Stockfish compiled to be used Under Winboard. It'll be for sure a major step to better understand and improve Musketeer Chess Game Play.

I'm now in a process where i'm thinking about version2. This version will for sure use some of the pieces in version1 (Hawk Unicorn) but i think of getting rid of the very strong pieces (Dragon or Amazone for example) and use of a low range pieces maybe limiting capture of pieces of extended range !

To have a clearer idea of the next development phase testing Musketeer Chess more extensively using different engines is important as variety garanties more coverage to identify points to improve.

Thanks to all of you.

Zied

Le sam. 4 janv. 2020 à 19:51, Fabian Fichter notifications@github.com a écrit :

The problem with a format like rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 prep E C e b b g is that it still contains superfluous information, at least if this format is also used for communication with the engine, because the files are not required any more once the pieces are gated. The FEN format of Musketeer-Stockfish https://github.com/ianfab/Musketeer-Stockfish/wiki/Interface#fen-format in principle is similar, it just gets rid of superfluous information about the game state history.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/3?email_source=notifications&email_token=AIIE4HK6RKK7UZ65XZK5KYTQ4DLCBA5CNFSM4FG4UBWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIC5ZZI#issuecomment-570809573, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HJGPQXM6V56UK24MF3Q4DLCBANCNFSM4FG4UBWA .

[HGMuller]

The problem with a format like rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 prep E C e b b g is that it still contains superfluous information, at least if this format is also used for communication with the engine, because the files are not required any more once the pieces are gated.

What I had in mind is to simply drop the file part when it is no longer relevant, and only leave the type choices. A gating opportunity that has been used or destroyed can be represented by a dash to preserve the position of the others, but when all are dashes they can be omitted. The standard part of the FEN would then never have to indicate the gating pieces, locations or virginity.

I would prefer the turn indicator and move counters to stay at "w 0 1" during the entire prep phase, as white is going to do the first real move. I don't think the choices in the prep phase should be counted as moves for deciding when the next session would start in a classical TC. The number of items already in the prep field at full-move count = 1 tells us the prep phase still has to be completed (and what tshould be chosen next).

In PGN the prep part would be in a separate tag, and fully describe the game history of the prep phase. The body of the PGN then only has to contain the real moves, with count starting at 1.

[musketeerchess]

Hi In Musketeer Chess, the choice of the new pieces and the gating process has an importance as a tactical and strategical choice, making these steps important for the game process.

So in my opinion, taking into account this particular fact is probably important especially in terms of research: Having engines that after further development will ponder these specific steps will for sure help identify many points to improve in game playability ! And may be also could identify a strategy that is a game killer which will for sure be the most important step concerning the future development of this variant by continuously "correcting" these issues.

This is not only from a human perspective but also in my opinion important for engines. In fact, the engine that will handle this part the best can have an advantage.

Zied

Le sam. 4 janv. 2020 à 23:40, HGMuller notifications@github.com a écrit :

The problem with a format like rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 prep E C e b b g is that it still contains superfluous information, at least if this format is also used for communication with the engine, because the files are not required any more once the pieces are gated.

What I had in mind is to simply drop the file part when it is no longer relevant, and only leave the type choices. A gating opportunity that has been used or destroyed can be represented by a dash to preserve the position of the others, but when all are dashes they can be omitted. The standard part of the FEN would then never have to indicate the gating pieces, locations or virginity.

I would prefer the turn indicator and move counters to stay at "w 0 1" during the entire prep phase, as white is going to do the first real move. I don't think the choices in the prep phase should be counted as moves for deciding when the next session would start in a classical TC. The number of items already in the prep field at full-move count = 1 tells us the prep phase still has to be completed (and what tshould be chosen next).

In PGN the prep part would be in a separate tag, and fully describe the game history of the prep phase. The body of the PGN then only has to contain the real moves, with count starting at 1.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/3?email_source=notifications&email_token=AIIE4HNUOHXXG2L5P5C3F6TQ4EF5NA5CNFSM4FG4UBWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIDBZ5Y#issuecomment-570825975, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HMWYJEHZ62VUCTHXNLQ4EF5NANCNFSM4FG4UBWA .

[fsmosca]

I would prefer the turn indicator and move counters to stay at "w 0 1" during the entire prep phase, as white is going to do the first real move.

PS (piece selection) followed by GP (gating preparation) are also real moves or actions, in fact they are the most important moves because without those, there is no musketeer chess. This is the unique part of musketeer chess from other variants. GP (placing a musketeer piece behind a FIDE piece, at row 9 for black and row 0 for white) can be both strategic and tactical. Once white drops a musketeer piece at row 0, black can already begin analyzing the possible positions that may arise (this can consume time) depending on where black would place its musketeer piece. If I am black and opponent places its unicorn at g file. I will be in danger in the line e2e4 e7e5 g1f3u because the unicorn can goto f5 via g1h4/h4f5 mate, assuming I ignore defending the f5 square. But wait my move e7e5 has already ignored the f5 square, what if e2e4 e7e6 (french defense)? so that his unicorn will be discouraged to goto f5? See the strategic and tactical thinking involved in the GP phase.

[HGMuller]

It depends on how you define 'real'. In my definition a real move involved taking a piece from the board, and putting it down on another square by a relative displacement that belongs to a pre-defined set of displacements allowed for that piece type during the entire game. Choosing a piece or a square does not satisfy that definition. That making the choice counts as a turn and has strategic importance does not make it a 'move'.

After sleeping on it I am not so happy with a prep field fully describing the preparation history being part of a FEN. There are conflicting requirements there: a FEN for a given game state should be unique to facilitate searching it in a database, while different order of making the piece and square choices would lead to the same game state.

With this in mind I consider it undesirable to have the history of gating-square choices being necessary for identifying the gating possibilities in FEN. It is important to record this history in PGN, and I still think the best way to achieve that is by means of a Prep tag. But given that a FEN format must exist that identifies the gating possibilities by itself, I would prefer the FEN tag in the PGN to reflect the game state after the prep stage. This would mean the SAN moves in the move section of the PGN are fully understandable from the FEN alone, and the Prep tag is only of interest for knowing which player chose what.

Note that the available promotion choices in a PGN game that started from a position deep in the game (after the Musketeer pieces have been all traded) already follows from the VariantMen tag in the PGN.

The redundancy of having the gating possibilities both explicitly shown in the FEN as well as following from the Prep tag is not uncommon in PGN. E.g. castling rights are always indicated in a FEN tag (if one is needed), even when the move section contains castling moves that imply these rights must have existed.

In the communication protocol there would be the choice of sending the FEN of the position after completion of the prep stage, or the FIDE start position followed by the history of the prep stage. In UCI that would look like

position fen GATING_INDICATING_FEN moves ...

or

position startpos prep PIECE_TYPE_CHOICES GATING_SQUARE_CHOICES moves ...

as one would always have after irreversible turns. The latter format also allows loading the engine with a game state during the prep phase, where the 'moves' section can be entirely omitted. It is customary in UCI to always send the entire game (i.e. the second format above), except when this is really impossible because a partial game starting from a custom position was loaded into the GUI. We can adopt the convention that in such a case a dummy prep section would be included to define the promotion choice. (The GUI would have derived that information from the VariantMen tag in the PGN used to load the partial game.) The engine would know the prep section is a dummy (rather than an invitation to choose gating squares) even if no move section followed, because the command didstart with 'position fen' rather than 'position startpos'.

[musketeerchess]

Hi Ferdy I agree with what you said, i also made the same reflection but without having given an example. What you pointed is exactly what i was thinking about.

I must also add the Following: i personally lost many games because of a bad strategical choice that begun from inadequate Gating Preparation. I like the PS (Piece Selection) and GP (Gating Preparation) as they are the essence of Musketeer Chess Variant, easy to retain and understand.

Also i think that it opens new fields in terms of engine programming as pondering these specific parameters is of tremendous importance (game play, finding a winning strategy for white which will be a major factor to fix if the engines find a strategy that garantees a huge white advantage, etc.)

Thanks to all of you.

Zied

Le dim. 5 janv. 2020 à 09:01, fsmosca notifications@github.com a écrit :

I would prefer the turn indicator and move counters to stay at "w 0 1" during the entire prep phase, as white is going to do the first real move.

PS (piece selection) followed by GP (gating preparation) are also real moves or actions, in fact they are the most important moves because without those, there is no musketeer chess. This is the unique part of musketeer chess from other variants. GP (placing a musketeer piece behind a FIDE piece, at row 9 for black and row 0 for white) can be both strategic and tactical. Once white drops a musketeer piece at row 0, black can already begin analyzing the possible positions that may arise (this can consume time) depending on where black would place its musketeer piece. If I am black and opponent places its unicorn at g file. I will be in danger in the line e2e4 e7e5 g1f3u because the unicorn can goto f5 via g1h4/h4f5 mate, assuming I ignore defending the f5 square. But wait my move e7e5 has already ignored the f5 square, what if e2e4 e7e6 (french defense)? so that his unicorn will be discouraged to goto f5? See the strategic and tactical thinking involved in the GP phase.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/3?email_source=notifications&email_token=AIIE4HIBEDOQM6LOM3QLIZDQ4GHVTA5CNFSM4FG4UBWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIDQ4AY#issuecomment-570887683, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HOKFMTXIGVTTXJLQGTQ4GHVTANCNFSM4FG4UBWA .

[HGMuller]

I think everyone agrees on this, it isn't really an issue. I just don't see how it is of any relevance here (i.e. for the matter of whether the choices made in the prep phase should be indicated by the FEN, in the move section or in a separate PGN tag)..

[fsmosca]

I think everyone agrees on this, it isn't really an issue. I just don't see how it is of any relevance here (i.e. for the matter of whether the choices made in the prep phase should be indicated by the FEN, in the move section or in a separate PGN tag)..

I am not sure of what FEN format do you really like, so I have a couple of questions.

1. What is the FEN of musketeer start position?
2. From your musketeer start position, after white selected cannon, what is its FEN?
3. From your musketeer start position, after white selected cannon, and black selected unicorn, what is its FEN?
4. From your musketeer start position, after white selected cannon, and black selected unicorn, white places its cannon behind the white knight at b file, what is its FEN?
5. From your musketeer start position, after white selected cannon, and black selected unicorn, white places its cannon behind the white knight at b file, black places its cannon behind the bishop at c file, what is its FEN?
6. From your musketeer start position, after white selected cannon, and black selected unicorn, white places its cannon behind the white knight at b file, black places its cannon behind the bishop at c file, white places its unicorn behind the knight at g file, what is its FEN?
7. From your musketeer start position, after white selected cannon, and black selected unicorn, white places its cannon behind the white knight at b file, black places its cannon behind the bishop at c file, white places its unicorn behind the knight at g file, black places its unicorn behind the rook at h file, what is its FEN?

[HGMuller]

Well, this is what we are here to determine. Note, however, that my proposal for PGN is to include the FEN for the position after the preparation phase in the FEN tag, even for games that did involve a preparation phase (rather than starting from some arbitrary other position late in the game). And leave out a FEN tag alltogether for a 'game' that was aborted before the preparation phase was completed. With this PGN format, the use case for the intra-preparation-phase FENs would be almost non-existent.

It does not seem possible to post the FENs you ask for here in the 'natural' (WYSIWYG) format currently used by WinBoard, because these contain asterisks for the dark squares. So let me post them in the 'stacked' format, where the gating and gated piece are imagined to occupy the same square as an ordered pair, enclosed by parentheses. A possible encoding could then be:

1: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 2: rnbqkbnr/pppppppp/8/8/8/8/(PC)PPPPPPP/RNBQKBNR w KQkq - 0 1 3: rnbqkbnr/(pu)ppppppp/8/8/8/8/(PC)PPPPPPP/RNBQKBNR w KQkq - 0 1 4: rnbqkbnr/(pu)ppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKBNR w KQkq - 0 1 5: rn(bc)qkbnr/(pu)ppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKBNR w KQkq - 0 1 6: rn(bc)qkbnr/pppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKB(NU)R w KQkq - 0 1 7: rn(bc)qkbn(ru)/pppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKB(NU)R w KQkq - 0 1

This uses the kludge of representing a selected, but not yet placed piece as residing under the left-most Pawn; other klududges are imaginable for this, like locating it on the h3 and a6 square, displaying it instead of the King, etc.

It could be argued that these are ugly kludges, and that it could be better to represent (say) case #3 by something like:

3b: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 choice C U

That would be fine with me too; I don't care at all because no GUI I would make would ever send any of the FENs 2-6 to the engine. (Nor put them in the FEN tag of a PGN.) It would load the corresponding positions into the engine by starting from the default startpos #1, followed by the choices that have been made. E.g. in UCI:

2: position startpos prelude C 6: position startpos prelude C U b c g

For #7 I would probably prefer

7: position fen rn(bc)qkbn(ru)/pppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKB(NU)R w KQkq - 0 1

[musketeerchess]

Hi I think in FEN Notation the 3b 6 and 7 notations are the ones to adopt as the choice of the selected pieces and their gating squares are precised here.

Any system that precises these two phases of the game are ok to be used. But making it "standardised" if probably better to ease programming and for engine vs engine matches and tournaments.

Best regards

Zied

Le lun. 6 janv. 2020 à 10:55, HGMuller notifications@github.com a écrit :

Well, this is what we are here to determine. Note, however, that my proposal for PGN is to include the FEN for the position after the preparation phase in the FEN tag, even for games that did involve a preparation phase (rather than starting from some arbitrary other position late in the game). And leave out a FEN tag alltogether for a 'game' that was aborted before the preparation phase was completed. With this PGN format, the use case for the intra-preparation-phase FENs would be almost non-existent.

It does not seem possible to post the FENs you ask for here in the 'natural' (WYSIWYG) format currently used by WinBoard, because these contain asterisks for the dark squares. So let me post them in the 'stacked' format, where the gating and gated piece are imagined to occupy the same square as an ordered pair, enclosed by parentheses. A possible encoding could then be:

1: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 2: rnbqkbnr/pppppppp/8/8/8/8/(PC)PPPPPPP/RNBQKBNR w KQkq - 0 1 3: rnbqkbnr/(pu)ppppppp/8/8/8/8/(PC)PPPPPPP/RNBQKBNR w KQkq - 0 1 4: rnbqkbnr/(pu)ppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKBNR w KQkq - 0 1 5: rn(bc)qkbnr/(pu)ppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKBNR w KQkq - 0 1 6: rn(bc)qkbnr/pppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKB(NU)R w KQkq - 0 1 7: rn(bc)qkbn(ru)/pppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKB(NU)R w KQkq - 0 1

This uses the kludge of representing a selected, but not yet placed piece as residing under the left-most Pawn; other klududges are imaginable for this, like locating it on the h3 and a6 square, displaying it instead of the King, etc.

It could be argued that these are ugly kludges, and that it could be better to represent (say) case #3 https://github.com/ianfab/Musketeer-Stockfish/issues/3 by something like:

3b: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 choice C U

That would be fine with me too; I don't care at all because no GUI I would make would ever send any of the FENs 2-6 to the engine. (Nor put them in the FEN tag of a PGN.) It would load the corresponding positions into the engine by starting from the default startpos #1 https://github.com/ianfab/Musketeer-Stockfish/issues/1, followed by the choices that have been made. E.g. in UCI:

2: position startpos prelude C 6: position startpos prelude C U b c g

For #7 I would probably prefer

7: position fen rn(bc)qkbn(ru)/pppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKB(NU)R w KQkq - 0 1

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/3?email_source=notifications&email_token=AIIE4HPOXNQWSBDNBX45UETQ4L5YNA5CNFSM4FG4UBWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIE66CY#issuecomment-571076363, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HMPYVA2UHHWVP4UGXLQ4L5YNANCNFSM4FG4UBWA .

[fsmosca]

Well, this is what we are here to determine. Note, however, that my proposal for PGN is to include the FEN for the position after the preparation phase in the FEN tag, even for games that did involve a preparation phase (rather than starting from some arbitrary other position late in the game). And leave out a FEN tag alltogether for a 'game' that was aborted before the preparation phase was completed. With this PGN format, the use case for the intra-preparation-phase FENs would be almost non-existent.

All right I get that.

It does not seem possible to post the FENs you ask for here in the 'natural' (WYSIWYG) format currently used by WinBoard, because these contain asterisks for the dark squares. So let me post them in the 'stacked' format, where the gating and gated piece are imagined to occupy the same square as an ordered pair, enclosed by parentheses. A possible encoding could then be:

1: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 2: rnbqkbnr/pppppppp/8/8/8/8/(PC)PPPPPPP/RNBQKBNR w KQkq - 0 1 3: rnbqkbnr/(pu)ppppppp/8/8/8/8/(PC)PPPPPPP/RNBQKBNR w KQkq - 0 1 4: rnbqkbnr/(pu)ppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKBNR w KQkq - 0 1 5: rn(bc)qkbnr/(pu)ppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKBNR w KQkq - 0 1 6: rn(bc)qkbnr/pppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKB(NU)R w KQkq - 0 1 7: rn(bc)qkbn(ru)/pppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKB(NU)R w KQkq - 0 1

This uses the kludge of representing a selected, but not yet placed piece as residing under the left-most Pawn; other klududges are imaginable for this, like locating it on the h3 and a6 square, displaying it instead of the King, etc.

It could be argued that these are ugly kludges, and that it could be better to represent (say) case #3 by something like:

3b: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 choice C U

That would be fine with me too; I don't care at all because no GUI I would make would ever send any of the FENs 2-6 to the engine.

There is a space between C and U in 3b: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 choice C U What is its purpose?

I prefer: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 CU The choice word and the space between C and U are removed. The field where the CU occupies can be called musketeer piece field.

(Nor put them in the FEN tag of a PGN.) It would load the corresponding positions into the engine by starting from the default startpos #1, followed by the choices that have been made. E.g. in UCI:

2: position startpos prelude C 6: position startpos prelude C U b c g

I prefer the format: 2: position startpos selection C 3: position startpos selection CU gate bcg where: White cannon can gate at b file. Black cannon can gate at c file. White unicorn can gate at g file.

As we know the uci protocol prefers the key: value pairs in communication.

For #7 I would probably prefer

7: position fen rn(bc)qkbn(ru)/pppppppp/8/8/8/8/PPPPPPPP/R(NC)BQKB(NU)R w KQkq - 0 1

That is fine with me.

Musketeer start position another idea

On the other hand I have something to comment regarding startpos. You prefer this: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 We know it is the start position of chess.

But this is musketeer chess, its startpos should be different. It can be:

8/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/8 w KQkq - 0 1 LCUDMAEHFS

There are 2 rows added, empty at the moment, for GP phase. These 2 rows are essential in this game as mentioned already. LCUDMAEHFS are the available musketeer pieces that are involved in this game, this should be specified. But only 2 piece types will be selected eventually. Musketeer Chess sub variant may be invented in the future to vary the piece types and maximum number of piece types allowed.

Sending sample position to uci engine

musketeer startpos = 8/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/8 w KQkq - 0 1 LCUDMAEHFS position startpos selection CU gate bcgh moves e2e4 e7e5

Available musketeer pieces in the start position: LCUDMAEHFS Selected musketeer piece types: CU, C: Cannon, U: Unicorn Allowed file gates: bcgh, White C: b, Black C: c, White U: g, Black U: h

The selected pieces CU must be present in the startpos available pieces LCUDMAEHFS.

Example of api/gui and engine communications from the start position

From gui To white engine: position startpos From engine To gui: bestselection C

To black: position startpos selection C To gui: bestselection U

To white: position startpos selection CU To gui: bestgate b

To black: position startpos selection CU gate b To gui: bestgate c

To white: position startpos selection CU gate bc To gui: bestgate g

To black: position startpos selection CU gate bcg To gui: bestgate h

To white: position startpos selection CU gate bcgh To gui: bestmove e2e4

To black: position startpos selection CU gate bcgh moves e2e4 To gui: bestmove e7e5

[HGMuller]

To me the space between the piece choices suggests temporal ordering; written together they would suggest an unordered set (like KQkq). UCI also writes spaces between the moves in the moves section of the position-moves command (which are also completely redudant), so it would be inconsistency in style to not write those in 'selection' and 'gate' sections of the same command.

Using separate sections each with their own name would not have my preference, because it promoses an explosion of new UCI keywords. Other variants will have preparation phases where players mustchoose things that are not gates or piece types (e.g. swap selected types with pieces on the board), so they would feel unhappy with ''selection' as well as 'gate', and feel compelled to introduce yet another keyword that describes the action better. This seems undesirable, which is why I proposed to use a single term that is general enough to cover all possible actions. But I am not in charge of UCI, so my opinion should just be considered advisory. I would always use plurals, however, to stay in style with 'moves' (i.e. 'selections' and 'gates').

More later...

[HGMuller]

About the start position: I think that what you propose is an attempt to encode the game rules in the FEN. In general I think this a bad idea; IMO FEN should be reserved for encoding game state of a game with given rules.

The problem here is that Musketeer Chess is not really a chess variant: a variant has fixed rules, and variants distinguish themselves from each other by having different rules. Musketeer Chess, OTOH, is a variant family: the rules for what Pawns can promote to are not fixed, but have to be negociated, which is tantamount to first agreeing on which variant you are going to play. The same happens in Chess with Different Armies; this also is a family of chess variants, and the players (or tournament director) first have to decide what variant of that family they are going to play, by selecting the armies. The CECP implementation of CwDA engines now recognizes this family aspects, by indeed considering each 'flavor' of CwDA a different variant. But to create order in this chaos, we adopted the convention that variant names can contain tildes to separate 'flavor specifications' from the 'family name', such as nutters~rookies~cwda, which would then CwDA with a white Nutty-Knights army and a black Remarkable Rookies army. As GUI could ameliorate the resulting combinatorial explosion of variant names by offering comboboxes for flavor selection in its New Variant dialog.

What you propose is basically to expand the family of Musketeer variants in a combinatorial way, by introducing new pieces, and allowing restriction of the type selection to arbitrary sub-sets of the available pieces. I am not sure that this is useful. Engines will only be able to play with the pieces they know, and telling them in a start-position FEN that they can also choose some they never heard of would cause problems if the opponent selects one of those. So it seems the only way to get a workable situation is when the choice is restricted to what the engines (or engine and user) have in common, and additional protocol would have to be added to negociate that. In addition there would have to be some minimum requirement for the number and type of supported pieces, to prevent engines will only implement Leopard and Unicorn out of laziness, and get away with it by simply refusing any other selection as 'uncommon'.

If you want a wider variety of Musketeer pieces, or prepare for future expansion of the set, I think the following method would have a better chance of success: allow the engine to select any piece that satisfies certain criteria, without the requirement that it should be picked from a pre-determined list, and have them describe the move of the pieces they selected to each other in Betza notation. E.g. white could select a piece that moves as Bishop or jumps to the second square orthogonally (Betza BD), and perhaps it should be allowed to assign an ID to it (rather than using fixed names X and Y). The opponent engine would then receive something like

position startpos selections G=BD

Rules for restricting the chosen move could be that the pieces must be at least 4-fold symmetric, are not divergent (i.e. captures as it moves), only uses ordinary (finite-range) slider moves or leaps, (so no hoppers or lame leapers, no bent slider trajectories) its number of moves would fall in a certain range (e.g. at least 4 from a central square, and never more than 27 from anywhere.

[HGMuller]

OK, so tildes can also not be used in this forum...

What I wanted to write above was nutters-rookies-cwda where the hyphens are actually tildes.

[gbtami]

@HGMuller you can type nearly anything in your comment in Markdown format! Read https://guides.github.com/features/mastering-markdown/ Markdown treats special characters as ordinary text if there is backslash escape character in front of them: setboard *d***s**/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/*S**D*** w KQBkqbf - 0 1 or \~\~\~

I agree with you that Musketeer chess is NOT one chess variant, but family of variants. I think the preparation phase shouldn't be part of FEN at all. It is enough to add that info to PGN tags.

Imagine when two player decides when they like compound pieces Archbishop and Chancellor. What to play? Capablaca chess or Janus chess? The piece selection phase in Musketeer is absolutely similar.

[musketeerchess]

About the start position: I think that what you propose is an attempt to encode the game rules in the FEN. In general I think this a bad idea; IMO FEN should be reserved for encoding game state of a game with given rules. The problem here is that Musketeer Chess is not really a chess variant: a variant has fixed rules, and variants distinguish themselves from each other by having different rules. Musketeer Chess, OTOH, is a variant family: the rules for what Pawns can promote to are not fixed, but have to be negociated, which is tantamount to first agreeing on which variant you are going to play. The same happens in Chess with Different Armies; this also is a family of chess variants, and the players (or tournament director) first have to decide what variant of that family they are going to play, by selecting the armies. The CECP implementation of CwDA engines now recognizes this family aspects, by indeed considering each 'flavor' of CwDA a different variant. But to create order in this chaos, we adopted the convention that variant names can contain tildes to separate 'flavor specifications' from the 'family name', such as nuttersrookiescwda, which would then CwDA with a white Nutty-Knights army and a black Remarkable Rookies army. As GUI could ameliorate the resulting combinatorial explosion of variant names by offering comboboxes for flavor selection in its New Variant dialog. What you propose is basically to expand the family of Musketeer variants in a combinatorial way, by introducing new pieces, and allowing restriction of the type selection to arbitrary sub-sets of the available pieces. I am not sure that this is useful. Engines will only be able to play with the pieces they know, and telling them in a start-position FEN that they can also choose some they never heard of would cause problems if the opponent selects one of those. So it seems the only way to get a workable situation is when the choice is restricted to what the engines (or engine and user) have in common, and additional protocol would have to be added to negociate that. In addition there would have to be some minimum requirement for the number and type of supported pieces, to prevent engines will only implement Leopard and Unicorn out of laziness, and get away with it by simply refusing any other selection as 'uncommon'. If you want a wider variety of Musketeer pieces, or prepare for future expansion of the set, I think the following method would have a better chance of success: allow the engine to select any piece that satisfies certain criteria, without the requirement that it should be picked from a pre-determined list, and have them describe the move of the pieces they selected to each other in Betza notation. E.g. white could select a piece that moves as Bishop or jumps to the second square orthogonally (Betza BD), and perhaps it should be allowed to assign an ID to it (rather than using fixed names X and Y). The opponent engine would then receive something like position startpos selections G=BD Rules for restricting the chosen move could be that the pieces must be at least 4-fold symmetric, are not divergent (i.e. captures as it moves), only uses ordinary (finite-range) slider moves or leaps, (so no hoppers or lame leapers, no bent slider trajectories) its number of moves would fall in a certain range (e.g. at least 4 from a central square, and never more than 27 from anywhere.

Hi guys Very entertaining and passionate discussion here. Musketeer Chess is for sure a "family" of Chess Variants (the future evolution of the game will for sure lead to expansion of the number of pieces probably of limited range and not too strong).

So probably the best way to encode all of this is imho as follows: Forget about the fact the engines have to negotiate (for example, White will make the choice of the first piece, which will Apply systematically for Black, then Black will adapt his strategy chosing the second piece), after that White begins Gating square selection etc. In the end, black still has the last work as he will "adapt" his gating strategy to white's choice.

The most important principle in Musketeer Chess is that Black adapts his strategical and tactical choices as he choses the second piece and the fact he plays after white he will each time during the prelude phase adapt to white's choices ! and this in my opinion should be translated in the FEN as it is probably a crucial part of programming for this Family of Variants and for game play testing.

It's also an important issue when making engine tournaments as the best programmer who will either program well his engine (or make an extensive opening book) will possibly gain a substantial advantage from the opening phase.

This is one of the crucial parameters i thought about for a long period when inventing and finalising the Musketeer Chess Variant (MCV Family of Variants).

[fsmosca]

To me the space between the piece choices suggests temporal ordering; written together they would suggest an unordered set (like KQkq).

According to pgn specs KQkq must be ordered.

16.1.3.3: Castling availability

The third field represents castling availability. This indicates potential future castling that may of may not be possible at the moment due to blocking pieces or enemy attacks. If there is no castling availability for either side, the single character symbol "-" is used. Otherwise, a combination of from one to four characters are present. If White has kingside castling availability, the uppercase letter "K" appears. If White has queenside castling availability, the uppercase letter "Q" appears. If Black has kingside castling availability, the lowercase letter "k" appears. If Black has queenside castling availability, then the lowercase letter "q" appears. Those letters which appear will be ordered first uppercase before lowercase and second kingside before queenside. There is no white space between the letters.

Ref: http://www.saremba.de/chessgml/standards/pgn/pgn-complete.htm#c16.1

[fsmosca]

About the start position: I think that what you propose is an attempt to encode the game rules in the FEN.

I am not sure what your are talking about, but rank 0 and 9 are important in musketeer chess, it should be included on its startpos.

Musketeer chess board without showing the selectable musketeer pieces

startpos: 8/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/8 w KQkq - 0 1 LCUDMAEHFS

It is vital that ranks 0 and 9 along with the selectable musketeer pieces LCUDMAEHFS should be specified in the startpos. The user and engine should know it.

Musketeer chess board showing selectable (a max of 2 types) musketeer pieces

[fsmosca]

The most important principle in Musketeer Chess is that Black adapts his strategical and tactical choices as he choses the second piece and the fact he plays after white he will each time during the prelude phase adapt to white's choices ! and this in my opinion should be translated in the FEN as it is probably a crucial part of programming for this Family of Variants and for game play testing.

There should be a FEN after every move or act that will be taken even at PS and GP phase. Finding better selection and gating to suit a player's style or play are more easier with the help of the engine.

[fsmosca]

We can use key words in plural form.

position startpos selections CU gates bcgh moves e2e4 e7e5

An improvement in file gates is,

position startpos selections CU gates BcGh moves e2e4 e7e5

In the file gates BcGh, upper case is for white, lower case is for black.

White:

selected C can only gate at B selected U can only gate at G

Black

selected C can only gate at c selected U can only gate at h

[HGMuller]

According to pgn specs KQkq must be ordered.

But that is an artificial rule, only needed becuse by nature castling rights do not form an ordered set. QKqk would have meant exactly the same. The PGN standard strives for unique representation of a game, so it must add additional rules to force the use of one of the 24 possible permutations, and outlaw all the others. This is quite different from encoding the piece choice, where CU would mean something different from UC, and adopting an extra rule to force uniqueness (e.g. that the pieces have to be mentioned in alphabetical order) is exactly what we don't want. At least if your goal is to describe the game history. If the goal is just to describe the sub-variant it does not matter who chose what, arnd requiring alphabetic ordering would be fine.

There should be a FEN after every move or act that will be taken even at PS and GP phase.

Why? I have no use case for that.

It is vital that ranks 0 and 9 along with the selectable musketeer pieces LCUDMAEHFS should be specified in the startpos. The user and engine should know it.

The user and the engine should know the game rules in general. How does the user/engine know that Pawns can be moved up 2 squares from the second rank? Must it be indicated in FEN? How does he know the King only moves 2 squares in Q-side castling, and not 3? Must it be indicated in FEN? How does he know that C means Cannon, and that it doesn't move like a Xiangqi Cannon? Must it be indicated in FEN? In general rule knowledge that is universal (i.e. not dependent on game state) will not be indicated in FEN. Even if it is helpful in identifying the variant. E.g. a FEN for Capablanca Chess will look like a Janus Chess position, once the Chancellors and Archbishops have been traded. But it is not, because the Pawns will be able to promote to Chancellor, which would not be allowed in Janus. The FEN does not indicate this, however. The players are supposed to know whether they are playing Capablanca of Janus, and FENs in general are only interpretable in the context of such knowledge.

That you can select from these 10 pieces (and how each of those moves) is part of the game rules of Musketeer Chess, and the players are supposed to know that they are playing Musketeer Chess. There is no need to tell them that through the FEN. In the protocol the variant (CECP) or UCI_Variant (UCI) command should be used to convey that info, not the FEN of the start position.

[HGMuller]

@musketeerchess:

It's also an important issue when making engine tournaments as the best programmer who will either program well his engine (or make an extensive opening book) will possibly gain a substantial advantage from the opening phase.

Beware that there is a huge practical problem in measuring this. Because chess engines tend to be rather deterministic in their move choice, and left to themselves from the very start, when you make them play 100 games against each other they would play the same game 100 times (or at least a game that starts the same for a large number of moves). So there is a fair chance that the weaker engine would win 100-0, because it was lucky that the game produced by the two quickly leads to a position where the stronger one makes a mistake, although in general the weaker one has a much larger probability to make a mistake. The large sample means nothing in this case, because the games were not sufficiently independent.

For this reason the paradigm im engine testing is to run games from an opening book or a set of opening lines leading to thousands of very different positions, from which the engines then continue the game. Then you can play thousands of games between the same two engines, and they will all be completely different, so that you can get a statistically accurate estimate of their strength.

But the choice of pieces and gating squares is the first thing you do in Musketeer Chess, so it would always be part of the opening line, and never played by the engine itself. A way out would be to first let the engines think to make their choice, and then force diversification of the games by having a number of different book lines starting from every possible combination of chosen gatings. But then, if one of the engines would score better than the other, it could be because the book lines are biased in favor of one of them. You cannot correct that by playing them with reversed colors (as would normally be done), because with reversed colors they would make different gating selections, so that they won't get to use the same opening lines.

Conventional testing methods will be able to tell you which engine is stronger in the middle- and end-game, without any unusual problems; this can even be detailed by making such measurements for given piece choices. (E.g. engine A is very strong, except when it has to play with Archbishops, then it performs much poorer against the same opponents. This would for instance happen if it assigned a completely wrong piece value to the Archbishop.)

It would be very hard to measure the quality of the piece and gating choices, though. This is similar to the question of whether 1.e4 or 1.d4 is the better opening move, and conventional engines are known to be quite poor at deciding this. For this reason even strong engines still use opening books that were generated from human games. The correct approach here seems to objectively establish the quality of all possible choices (basically short opening lines) by starting many games from the position after a given gating choice. Then the strength of the engine can be judged from the known quality of the choice that it makes. I can add that no one ever judges conventional engines that way. That is, no one cares if Stockfish would play 1.Nf3 without book, while human opening theory has shown that 1.d4 statistically gives a better score.

[ianfab]

I think the only way to measure performance including the opening in Musketeer chess with enough variety would be to play Musketeer960 games, but of course not all engines might perform the same on 960 positions and many might not even support it.

[HGMuller]

This is indeed a possible solution. There should not be any problem with engine support if we limit ourselves to shuffles that leave the King and Rooks in place. To get enough shuffles the white and black pieces could be shuffled independently.

A concern with Musketeer Chess could be that the desirability of a gating location could both be dependent on the absolute location as on the piece that starts there. Without ever having played the game my instinct would be to avoid gating under pieces that should be developed only late in the game, such as Queen and a-Rook. And also avoid gating on the f- and g-file, as this will interfere with K-side castling. So the b-file and e-file would be my preferred locations, with the c-file as a backup for facing specific tactical problems.

[ianfab]

From experience with S-Chess it can sometimes be useful to gate a hawk under a bishop or an elephant under a queen, because you have one more attacker to a square you can now safely move to or sacrifice on, e.g., moving a bishop from c1 to g5 to attack the queen or capturing with the queen on d4 with a supporting chancellor on d1. So I agree that something similar most likely applies even more to Musketeer chess, since you need to decide in advance.

[fsmosca]

There should be a FEN after every move or act that will be taken even at PS and GP phase.

Why? I have no use case for that.

The reason for this is to make it easier to send the FEN to the engine and let it analyze that.

The

position startpos selections CU gates Bc

can be sent to the engine with just

position fen

where: fen = the fen after CU are selected and gates are specified to be at Bc.

That you can select from these 10 pieces (and how each of those moves) is part of the game rules of Musketeer Chess, and the players are supposed to know that they are playing Musketeer Chess. There is no need to tell them that through the FEN. In the protocol the variant (CECP) or UCI_Variant (UCI) command should be used to convey that info, not the FEN of the start position.

It is better to already have an idea about the game by just seeing its startpos. It does not mean there is a need to tell the user about the game through the FEN.

When user sees the startpos of the game, 8/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/8 w KQkq - 0 1 LCUDMAEHFS user knows that he is going to play the musketeer chess and not any other game.

The user may know or not know the start FEN of the game, but for musketeer chess its start FEN has to be unique and not just any other startpos.

[HGMuller]

The reason for this is to make it easier to send the FEN to the engine and let it analyze that.

The

position startpos selections CU gates Bc

can be sent to the engine with just

position fen

where: fen = the fen after CU are selected and gates are specified to be at Bc.

How is that easier? The FEN will be far longer, and most of the alternative "position startpos selections CU gates Bc" is self-inflicted by requiring so many kewords and making them long.

It is better to already have an idea about the game by just seeing its startpos. It does not mean there is a need to tell the user about the game through the FEN.

When user sees the startpos of the game, 8/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/8 w KQkq - 0 1 LCUDMAEHFS user knows that he is going to play the musketeer chess and not any other game.

The user may know or not know the start FEN of the game, but for musketeer chess its start FEN has to be unique and not just any other startpos.

FENs are not meant to be shown to the user; no GUI would do that. A user would know he is going to play Musketeer Chess because he just set the GUI to play Musketeer Chess (e.g. selecting it from the New Variant menu). There would be no other way to play Musketeer Chess; pasting a FEN into the GUI would certainly not make it switch variant. It would just reject the FEN for having too many ranks. Engines would know they are playing Musketeer Chess because the CECP variant command or the UCI_Variants option told them so. A PGN file would be recognizable as a Musketeer game because the Variant tag would say that.

[fsmosca]

The reason for this is to make it easier to send the FEN to the engine and let it analyze that. The position startpos selections CU gates Bc can be sent to the engine with just position fen where: fen = the fen after CU are selected and gates are specified to be at Bc.

How is that easier? The FEN will be far longer, and most of the alternative "position startpos selections CU gates Bc" is self-inflicted by requiring so many kewords and making them long.

This one,

position startpos selections CU gates BcGh moves e2e4 e7e5

is based on uci protocol formating.

That startpos selections CU gates BcGh moves e2e4 e7e5 can be converted to fen.

And then just send to the engine, position fen

cecp protocol is different.

It is better to already have an idea about the game by just seeing its startpos. It does not mean there is a need to tell the user about the game through the FEN. When user sees the startpos of the game, 8/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/8 w KQkq - 0 1 LCUDMAEHFS user knows that he is going to play the musketeer chess and not any other game. The user may know or not know the start FEN of the game, but for musketeer chess its start FEN has to be unique and not just any other startpos.

FENs are not meant to be shown to the user;

I understand that, but FEN's are not meant to be kept either.

As I understand the specific topic here is not about showing and hiding the FEN to the user, but it is about the startpos of musketeer chess. I like to see the startpos of musketeer chess implemented to be different from startpos of chess.

[HGMuller]

I still do not see your point. Deep in a game of (say) 60 moves, then, yes, it will be more compact to send "position fen FEN moves A_FEW_REVERSIBLE_MOVES" than the entire game. (And I could add that despite that, every GUI I know would still send the entire game.) But in the Musketeer preparation phase this will never be the case, as there will at most be 2 type selections and 3 gates.

position fen 2u1c3/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/1C4U1 w KQkq - 0 1

will always be a lot longer than

position startpos selections C U gates b e g c

Even if there would be a FEN definition for intra-prep positions, UCI interfaces would most likely use the second format, as it is customary to send the entire game. from startpos on.

I like to see the startpos of musketeer chess implemented to be different from startpos of chess.

Why? The start position of Berolina Chess is the same as that of normal Chess. And of Atomic Chess. And of Suicide Chess. And of Losers Chess. And of King of the Hill.

What would be the purpose of it being different? What bad thing would happen in practice when they are the same? When I wanted to send the position to a UCI engine I would just use the string "startpos". Never the FEN, no matter how it looked.

[fsmosca]

I still do not see your point. Deep in a game of (say) 60 moves, then, yes, it will be more compact to send "position fen FEN moves A_FEW_REVERSIBLE_MOVES" than the entire game. (And I could add that despite that, every GUI I know would still send the entire game.) But in the Musketeer preparation phase this will never be the case, as there will at most be 2 type selections and 3 gates.

position fen 2u1c3/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/1C4U1 w KQkq - 0 1

will always be a lot longer than

position startpos selections C U gates b e g c

Even if there would be a FEN definition for intra-prep positions, UCI interfaces would most likely use the second format, as it is customary to send the entire game. from startpos on.

There is convenience when users communicates with FEN. GUI can send by fen or by position startpos selections CU gates BcGh

It is not about the length it is about the simplicity of sending the FEN to the engine. position fen not startpos selections CU gates BcGh but it does not mean that startpos selections CU gates BcGh is bad. If the game starts from startpos, you can use startpos selections CU gates BcGh.

I like to see the startpos of musketeer chess implemented to be different from startpos of chess.

Why? The start position of Berolina Chess is the same as that of normal Chess.

Because Berolina Chess is 8x8, also piece types are the same (although the pawn movement is different), from pawn to king.

[HGMuller]

Musketeer Chess is 8x10. So which variant would have the same FEN (without the list of selectable pieces)?

Perhaps I should refrain from discussing how FENs should look that I would never use anyway.

[musketeerchess]

Hi Here are the most important elements:

FEN shouldn't describe a chess variant for sure. The GUI should recognize the played chess variant because it was chosen. The players also know that they play Musketeer Chess and are supposed to know the rules of the game like for a classic chess game. So here i think that HGM got a good point.

In Musketeer Chess bith the Piece Selection and the Gating Phase are important components of strategical and tactical choices. For game variety, engine vs engine matches will need a book. But these specific phases of the game should be for sure explored and programmed.

Maybe the corresponding programming isn't directly to be used in engine vs engine matches, but probably it's a Homework to build a reliable opening book that could be used by the specific engine is the matches / tournaments.

I think that the discussion concerning the FEN notation in Musketeer Chess Variant Family approaches the final conclusions. The next question is: How can an engine be programmed to answer the Following questions: Piece selection (probably in the beginning of the game this should be random: select from any programmed piece with known rules, which leaves the place to introduce or add new pieces in the future developments of this family of games. The choice could be influenced also by some programming features: for example we want rapid attacking games, the pieces with the highest number of leaping possible squares or highest number of different attacking directions should be favored in the choice !)

Once the first piece was selected, it's black to chose the second piece. The choice can be made to answer possible threats by white: pondering for a few moves, analysing different gating squares of the first chosen piece and try determine if there are immediate threats or possible threats coming after 6-8 plys and then chosing the piece that helps better counter the threats.

It's a wide research and programming features. Probably, these features will possibly be determined after thousands of games. Initial placement of the pieces and some other characteristics (for example complimentary rules for pieces where you chose two different pieces that cover when associated together the widest range of squares with a bonus for the squares covered by leapers) etc.

What are your suggestions my friends

[musketeerchess]

found an interesting article on CLOP: Automated Tuning Algorythms that should be a way helping in the possible choice of Piece Selection and Gating Preparation, but i think it should be especially used for PS of the second piece and GP.

https://www.chessprogramming.org/CLOP

[fsmosca]

Hi Here are the most important elements:

FEN shouldn't describe a chess variant for sure. The GUI should recognize the played chess variant because it was chosen. The players also know that they play Musketeer Chess and are supposed to know the rules of the game like for a classic chess game. So here i think that HGM got a good point.

The startpos of chess is just like that,

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

8 rows by 8 columns with piece types NBRQK located on specific squares, empty rows have digit 8 and no selectable piece types.

In musketeer chess it has 10 rows by 8 columns.

musketeer startpos: 8/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/8 w KQkq - 0 1 LCUDMAEHFS

LCUDMAEHFS represents selectable musketeer piece types, call that fen location as selectable musketeer piece field.

Row 0 and row 9 are currently empty, but they are real because those will be occupied with musketeer piece types LCUDMAEHFS (a maximum of only 2 piece types) later in the game during GP (Gating preparation) phase.

In chess, all piece types involved in the game are indicated in its startpos.

That is the reason why the selectable LCUDMAEHFS has to be included in the musketeer startpos and the piece location field 8/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/8 has to be properly represented too.

The GUI designer may ignore such musketeer startpos format but the startpos

8/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/8 w KQkq - 0 1 LCUDMAEHFS

has to be like that, representing the board layout and location of default piece types PNBRQK and indicating the selectable musketeer piece types LCUDMAEHFS that are involved in the game.

[HGMuller]

I am not sure selecting pieces and gates is a matter of 'tuning' through games (as CLOP does). For normal Chess evaluations tuning is important, because the heuristic evaluation always is a compromise. There will always be positions where things that are on average good will backfire. So it is very important to guage them on a representative set of positions, and what is representative depends to a great extent on what the engine prefers, which is again affected by what we are trying to tune. So tuning on a fixed set of positions will not give optimal results, and you really have to use any proposed evaluation for generating the games and determine the performance based on those.

Type and gate preferences, however, will not affect the remainder of the game. It can be objectively be decided which choices are better, and whether the engine prefers a good or a poor choice will not affect how well it performs for a given choice. So you can first optimize play for a given choice, and generate games to determine how good this choice was. Altering the preference for that (or any other) choice will then not affect that, so there is never any backlash from prefering the best choice; it will remain best no matter how much you prefer it.

Basically the problem is equivalent to determining which opening lines are best in normal Chess. If people do this purely with an engine, they do it by book building and analysis of book positions, not by tuning based on games.

I must say it is hard for me to imagine that the choice of piece type can result in any advantage at all, since both players will get a piece of that type. There still is so much freedom after that in selecting gates, that it would be very unlikely that none of those choices would satisfactorily neutralize any threat that the selected pieces can pose.

[musketeerchess]

Hi HG, i understand your doubts concerning the importance of Piece Selection and Gating Phase. I played hundreds of games of Musketeer Chess myself, and thousands of computer games. I my personal games, i sometimes lost them because of a poor choice concerning gating squares (that seemed to be good at first but were poor). For example, playing with a Spider and making Fianchetto openings turned to be a successful strategy in many games. I lost a game like that, after that i got inspiration from this lost game and won a game using almost the same opening ideas. even if we begin with same Pieces, the gating squares and strategy in the opening is crucial ! (or seems to be).

[HGMuller]

Note that I only expressed doubts concerning the importance of piece-type selection. Not on the selection of gating squares. If you know any combinations of two types that would give a clear advantage to one of the players even with their best choice of gating square, I would be very interested to hear it. But it is not really worth it to argue about this. The point is that these selections are the first things that are done in the game, and if they really are critical, the logical approach for an engine would be to play them from a built-in book. When playing black the engine would just have to know what piece type it should best select in response to 10 possible opponent choices, what first gating square it should select in response to the 80 possible combinations of the opponent's type choice and first gating square (and its own preferred piece), and what second gating square it should pick in response to the 560 possible combinations of the opponent's chosen type and two gating squares. When playing white it can react only to black's type choice and first gating square, of which there are 80 combinations. The required 'book' would need to contain only 640 six-move lines to exhaustively cover all possible game starts. A serious engine developer would just empirically decide which choices in any of the possible situations are best for his engine by playing games from the position that would / could result from the choices, and recording the WDL stats of those.

[musketeerchess]

Hi HG I agree with you that a serious programmer will also make a book to “help” his engine take what looks to be a wise choice concerning PS and GS.

You stressed here one important thing: black’s choices are crucial and are the most important.

Some of the pieces used currently has unique or almost unique rules. So even the piece choice in the opening books will certainly evolve with a better programming to take advantage of their specific rules. And the more a new piece positional evaluation is improved, the more chosing it becomes a good alternative not only because the engine will use it more efficiently, but also to have more variety in game play.

As discussed before, can you precise to us how King Slayer handles Musketeer Chess compared to Seirawan Chess? This is intended to give a common path for programmers and make their engines compatible for tournament play under winboard.

Thanks HG

Zied

[HGMuller]

Well, in this case it is not just to 'help' the engine doing something that its general abilities it would need in any case for the remainder of the game would be able to do as well (but perhaps somewhat less good). As is the case in opening books for orthodox Chess. Here it provides an easy shortcut for doing something that otherwise would have to be specially coded in a more complex way that would make it more difficult to control the choices. I guess an engine would always need good understanding of all the Musketeer pieces, as it cannot avoid the opponent picking the piece he masters least.

The way WinBoard currently treats a game of Musketeer Chess is by splitting it into a 'prelude' (the type and gating-square selection) and a a 'regular part' (the board moves). The regular part would be recorded in PGN in the place where one normally finds SAN moves, and the FEN tag would reflect the situation after the prelude (from which the participating piece types and gating squares follow). If it is desirable to record the order in which the choices were made, this will be done in a special "Prelude" tag. This will be of no relevance any the engine loaded when such a game is loaded: the engine will simply be told to start from the given FEN. As far as WinBoard is concerned the game started there; it is not possible to step back into the prelude when stepping through the loaded game. Engine-engine games can be started using short unfinished games as opening lines in the normal way; the engines would then get the position after the prelude loaded into them, plus the moves of the regular part, before they are set playing. It is thus assumed that the prelude in engine-engine games will always be supplied by the book, in the form of the resulting position.

An engine that has not yet received a start position throug a 'setboard' command might want to conduct a dialog with the opponent for completing the prelude. An alternative would be to have it treat Musketeer Chess as a shuffle game, where it randomly selects pieces and gating squares for both players; WinBoard would then accept the choices of the first engine, and send the resulting position to the second one before starting a game. (This doesn't follow the official rules, but would still provide somewhat reasonable behavior in human-engine games, where the user always has the option of clicking 'new game' until the engine comes up with a post-prelude position he considers acceptable. And in tournaments that start from book the situation would never arise.)

WinBoard currently has no support for a dialog between two engines during the prelude phase. If there is strong demand for this, I can modify WinBoard to handle the (existing) tellopponent command in engine-engine games such that the included text string will be sent to the other engine (with some appopriate prefix). We would have to discuss this.

WinBoard does support several methods for conducting a dialog between an engine and a user, though. Messages can be presented to the user on engine request (telluser), and users can even be prompted for textual input (askuser). It is also possible for an engine to present arbitrary board positions to the user before the game has started, and to be kept aware of what board squares are clicked by the user.

KingSlayer-Aramis uses this latter method does conduct a prelude dialog with the user in graphical form: it presents a board containing all Musketeer pieces to the user when it is the user's turn to select a piece type, and is made aware of which piece the user clicked on to make his choice. It then presents a board with the piece of which the gating square should be determined on all 0th or 9th-rank ('pre-gating') squares, and awaits the user's click on any of those, and then repeats that for the second square. I placed the code for doing this in the public domain, and published it on TalkChess. In short, it works by sending a 'setup' command to the engine that specifies a board position and the images to be used for the mentioned pieces, and then waiting for a 'lift' command that will tell it the square that the user clicked (e.g. 'lift e4'). It can then make its own choice, and decide on the basis of what has been chosen so far what board it wants to present to the user now for selecting something from, and send a new setup command to present that board. Note that all this is going on without the GUI attaching any special meaning to it, and without the second engine being made aware of it. After the prelude has been completed this way, KingSlayer will send the final 'setup' command to specify participating pieces and the initial position that should be used for the subsequent game. The user will then get to see this start position, and can play his move (or the engine is set thinking by the GUI, if it is supposed to play white).

To be informed of user mouse clicks on the board, an engine should send feature highlight=1 at startup. It might then receive 'lift', 'put' and 'hover' commands, the latter two of it it can ignore, while the 'lift' command can be ignored after the prelude. The 'setup' commands to specify the boards that should be displayed as prelude menus should prefix the name of the parent variant by an exclamation point, to indicate they are non-final (so that later, and in particular the final 'setup' commands will not be ignored). As after a 'new' command engines are supposed to think they are playing black, the engine should send a command to prompt the user for the white piece-type choice in immediate response to the variant musketeer command. As always the current game state can be overruled through a 'setboard' command from the GUI; the engine will also have to reply with a 'setup' command to that, in order to inform WinBoard what images to use for the participating Musketeer pieces.