Comment on FEN format #3
Comments
|
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 ddugovic/Stockfish#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. |
|
Thanks for the link, just knew it. I hope HGM would fully support musketeer in WB. |
|
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. |
|
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 boardimage 1: Piece idL/l = Leopard Upper case id: White color startfen
Fields in fenpiece locations: 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 startfena3h3 Example moves in a game1 a3h3 Black cannon is automatically selected and placed on that square. fen: Legal movesd6a6 1... e6a6 White elephant is automatically selected and placed on that square. fen: Legal movesh3a0 2 h3b0 Legal movesa5a9 2... a5d9 Legal movesh4a0 3 h4f0 Legal movesa6a9 3... a6g9 Game notation from above sample move sequences
continue to illustrate the loss of gating right of a musketeer piece.
image 8: 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 |
|
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? |
|
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. |
I am actually expecting you to support musketeer chess fully in winboard.
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.
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.
I cannot exactly agree when you use the word prelude. Meaning of prelude: But in musketeer chess the opening stage is very important.
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. |
|
Sorry, the quoting didn't quite work as I expected, here, so my original posting was rather messed up. This is the second attempt:
With dedicated support there would be no need at all to encode choices as moves with artificial from- or to-squares.
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.
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.
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. |
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.
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 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. |
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.
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"] |
|
The problem with a format like |
|
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
<#3?email_source=notifications&email_token=AIIE4HK6RKK7UZ65XZK5KYTQ4DLCBA5CNFSM4FG4UBWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIC5ZZI#issuecomment-570809573>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIIE4HJGPQXM6V56UK24MF3Q4DLCBANCNFSM4FG4UBWA>
.
|
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. |
|
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
<#3?email_source=notifications&email_token=AIIE4HNUOHXXG2L5P5C3F6TQ4EF5NA5CNFSM4FG4UBWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIDBZ5Y#issuecomment-570825975>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIIE4HMWYJEHZ62VUCTHXNLQ4EF5NANCNFSM4FG4UBWA>
.
|
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. |
|
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'. |
|
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
<#3?email_source=notifications&email_token=AIIE4HIBEDOQM6LOM3QLIZDQ4GHVTA5CNFSM4FG4UBWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIDQ4AY#issuecomment-570887683>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIIE4HOKFMTXIGVTTXJLQGTQ4GHVTANCNFSM4FG4UBWA>
.
|
|
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.
|
|
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 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 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 |
|
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
<#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
<#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
<#3?email_source=notifications&email_token=AIIE4HPOXNQWSBDNBX45UETQ4L5YNA5CNFSM4FG4UBWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIE66CY#issuecomment-571076363>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIIE4HMPYVA2UHHWVP4UGXLQ4L5YNANCNFSM4FG4UBWA>
.
|
All right I get that.
There is a space between C and U in I prefer:
I prefer the format: As we know the uci protocol prefers the key: value pairs in communication.
That is fine with me. Musketeer start position another ideaOn the other hand I have something to comment regarding startpos. You prefer this: But this is musketeer chess, its startpos should be different. It can be:
There are 2 rows added, empty at the moment, for GP phase. These 2 rows are essential in this game as mentioned already. Sending sample position to uci enginemusketeer startpos = Available musketeer pieces in the start position: The selected pieces Example of api/gui and engine communications from the start positionFrom gui To white engine: To black: position startpos selection C To white: position startpos selection CU To black: position startpos selection CU gate b To white: position startpos selection CU gate bc To black: position startpos selection CU gate bcg To white: position startpos selection CU gate bcgh To black: position startpos selection CU gate bcgh moves e2e4 |
|
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. |
|
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. |
|
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. |
The reason for this is to make it easier to send the FEN to the engine and let it analyze that. The
can be sent to the engine with just
where:
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, 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. |
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.
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. |
This one,
is based on uci protocol formating. That And then just send to the engine, cecp protocol is different.
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. |
|
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.
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. |
There is convenience when users communicates with FEN. It is not about the length it is about the simplicity of sending the FEN to the engine.
Because Berolina Chess is 8x8, also piece types are the same (although the pawn movement is different), from pawn to king. |
|
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. |
|
Hi 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. What are your suggestions my friends |
|
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. |
The startpos of chess is just like that,
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:
Row 0 and row 9 are currently empty, but they are real because those will be occupied with musketeer piece types In chess, all piece types involved in the game are indicated in its startpos. That is the reason why the selectable The GUI designer may ignore such musketeer startpos format but the startpos
has to be like that, representing the board layout and location of default piece types |
|
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. |
|
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). |
|
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. |
|
Hi HG 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? Thanks HG Zied |
|
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. 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. 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 |
|
HERE HGM EXPLAINS AND PROPOSES A COMMON METHOD FOR PROGRAMMERS FOR ADDING MUSKETEER CHESS UNDER WINBOARD. VERY INTERESTING PROCESS. THANKS HG, PLEASE ANSWER SOME OF MY QUESTIONS THAT FOLLOW. IN PARTICULAR GIVE US THE LINKS FOR KING SLAYER AND EXPLAINATIONS YOU GIVE ABOVE. HGM: "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.": HGM: "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)." HGM:
Zied: = COULD BE INTERESTING TO ADD THE PRELUDE PHASE IN THE PGN TO HELP REPLAY THE GAMES FOR ANALYSIS PURPOSE OF THE PRELUDE PHASE ! WILL PROBABLY ALSO HELP MAKING BOOKS. HGM Zied: ** YES WHEN THE VARIANT WILL BECOME MORE WIDELY PROGRAMMED AND BOOKS DEVELOPED FOR THE PRELUDE, BUT FOR NOW MY THOUGHTS ARE THE PRELUDE IS PART OF THE GAME AND SHOULD BE TRACED SOMEWHERE WHEN REPLAYING THE GAMES ! ** HGM Zied: ** SEE COMMENT ON 3 ** HGM Zied HGM Zied HGM Zied HGM We would have to discuss this. 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 (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) does conduct a prelude dialog with the user in graphical form: I placed the code for doing this in the public domain, and published it on TalkChess. Zied HGM 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 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. |
|
I added d9a43e8 that allows to switch between the internal and the XBoard/Winboard FEN format for Musketeer chess. Since on-the-fly detection of the FEN format during parsing is tricky, the format for now has to be explicitly enabled via the UCI option Edit: Actually detecting the FEN format is trivial. I removed the UCI option again, see 13cf3e1. |
|
I decided to go for a full-fledged solution and "simply" took over most of the CECP protocol implementation from Fairy-Stockfish and it worked surprisingly well. I tested that Musketeer-Stockfish now works in XBoard. For now Musketeer-Stockfish skips the setup phase when using the CECP protocol. |
|
hi ianfab |
|
I will make a release, then you can download the windows binary. |
|
I created a first release at https://github.com/ianfab/Musketeer-Stockfish/releases with Linux and Windows binaries for three common architectures (basic x86-64, popcnt/modern, bmi2). |
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 1In 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-fileThe engine would then limit its move generation gating a piece at b-file.
The text was updated successfully, but these errors were encountered: