Engines playing Musketeer Chess, good price

[hgm]

Isn't losing the gating piece when king is in check already punishment enough?

That is the point one has to take the risk when planning to gate at king file. The advantage however is that one can have a centralized piece after a successful gating.

What Daniel means is losing the piece because it would get captured after the gating, not because the gating would be forbidden in this special case.

[Ferdy]

Isn't losing the gating piece when king is in check already punishment enough?

That is the point one has to take the risk when planning to gate at king file. The advantage however is that one can have a centralized piece after a successful gating.

What Daniel means is losing the piece because it would get captured after the gating, not because the gating would be forbidden in this special case.

Ahh right, more punishment for king that is under attack and cannot capture its attacker and is forced to move.

[musketeerchess]

This is part of the risks when one drops a musketeer piece (in the gating preparation phase) in the king file, as we know the king file is one of the central files of the board where deploying for example a chancellor (R+N) is very tempting.

Except that when one drops a piece behind a King, one does it because one intends to castle quickly, long, long before the opponent has any chance to check you. One doesn't want to spoil ones own castling by making another move with the King just to gate. One doesn't want one's King to move, destroying the possibility to castle, even if it doesn't gate anything. It is generally advisable to gate under pieces that will be developed quickly, as not having gated does not only pose the risk of the opportunity being destroyed, but also lowers your instant tactical power. Having a Chancellor in the central files is good, but only if it is actually there (i.e. is gated). Even having a Chancellor in the corner is better than having an ungated Chancellor; ungated Chancellors are not only completely useless, they are in great jeopardy. They can be captured, but are not allowed to move. If you choose a gating square out of necessity, because the gated piece is needed there to neutralize a tactical threat, this would also only work if you gate it in time to fight off the threat.

It seems there is no use case for this rule in a serious game. Having the rule seems as pointless as adding a rule that you are allowed to remove your own queen on the move after the opponent moved a Kight backwards.

Hi
The rule that drops Gating a piece if the king is attacked and obliged to move without capturing the attacking piece is encountered in "real" life much more than you think, especially considering some leapers like Unicorns or Hawks !!

This gives some tactical shots in the opening that obliges the attacked side to play carefully and forces some moves. This also tells that when you face Hawk or Unicorn, chosing the King as the Gate Selected piece isn't a wide decision as The Selected piece will only be able to engage during the battle after castling or when the king moves for the first time.

Think about these situations.

[musketeerchess]

Isn't losing the gating piece when king is in check already punishment enough?
It would be simpler to just allow gating every time the piece in front moves, and then let the consequences (e.g. gating piece being immediately captured being one of them) prevail. If the king is incheck, obviously the gating can not occur by castling, but it should happen by all other means. In your example of a Knight checking a king, if the king moves and is allowed to gates, then the consequence is an exchange of a Cannon for knight. If the king is not allowed to gate, it would loose a Cannon so the punishment is more. It just adds more complexity, but there is no obvious need for the rule, sorry if I misunderstood your point.

Hi
Played many games where these tactics wisely used helped to gain the advantage and win.

I agree with you that this could be interpreted as an artificial rule.

I think it'll disappear in version2!

[musketeerchess]

Isn't losing the gating piece when king is in check already punishment enough?
It would be simpler to just allow gating every time the piece in front moves, and then let the consequences (e.g. gating piece being immediately captured being one of them) prevail. If the king is incheck, obviously the gating can not occur by castling, but it should happen by all other means. In your example of a Knight checking a king, if the king moves and is allowed to gates, then the consequence is an exchange of a Cannon for knight. If the king is not allowed to gate, it would loose a Cannon so the punishment is more. It just adds more complexity, but there is no obvious need for the rule, sorry if I misunderstood your point.

Hi
Played many games where these tactics wisely used helped to gain the advantage and win.

I agree with you that this could be interpreted as an artificial rule.

I think it'll disappear in version2!

A new engine that will play Musketeer Chess: Ethereal, https://github.com/AndyGrant/Ethereal

Also the Musketeer Chess engine of our website is better.

[AndrewGrant]

Isn't losing the gating piece when king is in check already punishment enough?
It would be simpler to just allow gating every time the piece in front moves, and then let the consequences (e.g. gating piece being immediately captured being one of them) prevail. If the king is incheck, obviously the gating can not occur by castling, but it should happen by all other means. In your example of a Knight checking a king, if the king moves and is allowed to gates, then the consequence is an exchange of a Cannon for knight. If the king is not allowed to gate, it would loose a Cannon so the punishment is more. It just adds more complexity, but there is no obvious need for the rule, sorry if I misunderstood your point.

Hi
Played many games where these tactics wisely used helped to gain the advantage and win.

I agree with you that this could be interpreted as an artificial rule.

I think it'll disappear in version2!

A new engine that will play Musketeer Chess: Ethereal, https://github.com/AndyGrant/Ethereal

Also the Musketeer Chess engine of our website is better.

https://github.com/AndyGrant/Ethereal-Musketeer Tentatively.

[musketeerchess]

Isn't losing the gating piece when king is in check already punishment enough?
It would be simpler to just allow gating every time the piece in front moves, and then let the consequences (e.g. gating piece being immediately captured being one of them) prevail. If the king is incheck, obviously the gating can not occur by castling, but it should happen by all other means. In your example of a Knight checking a king, if the king moves and is allowed to gates, then the consequence is an exchange of a Cannon for knight. If the king is not allowed to gate, it would loose a Cannon so the punishment is more. It just adds more complexity, but there is no obvious need for the rule, sorry if I misunderstood your point.

Hi
Played many games where these tactics wisely used helped to gain the advantage and win.

I agree with you that this could be interpreted as an artificial rule.

I think it'll disappear in version2!

A new engine that will play Musketeer Chess: Ethereal, https://github.com/AndyGrant/Ethereal

Also the Musketeer Chess engine of our website is better.

https://github.com/AndyGrant/Ethereal-Musketeer Tentatively.

Hi Andrew
Thanks for updating the URL.

Waiting to see your excellent work.

Zied

[musketeerchess]

Here is an interesting statement by HGM that defines a standard way to ease programming of Musketeer Chess Engines Under Winboard, using UCI. This is a beginning. Probably still a few details to improve especially PGN notation of the "prelude phase".

This discussion can be found here: https://github.com/ianfab/Musketeer-Stockfish/issues/3

Also thanks to the excellent work of Ferdinand Mosca, the rules are clearer and can be found here: https://github.com/fsmosca/musketeer-chess


HERE HGM EXPLAINS AND PROPOSES A COMMON METHOD FOR PROGRAMMERS FOR ADDING MUSKETEER CHESS UNDER WINBOARD. VERY INTERESTING PROCESS.

STILL SOME ISSUES THAT SHOULD BE ADDED IN MY OPINION PARTICULARLY ADDING THE PRELUDE (PIECE AND GATING SELECTION) IN THE PGN FOR ANALYSIS PURPOSES !! THE FINAL IMPACT OF SUCH ADDITION IS: HELP BOOK PREPARATION BUT ALSO IMPROVE PROGRAMMING FEATURES CONCERNING GATING SELECTION (I ASSUME THAT ALL THE PIECES ARE EQUALLY INTERESTING FOR THE GAME, MY PERSONAL PREFERENCES ARE NOT FOR THE QUEEN LIKE PIECES (I LIKE HAWK, UNICORN, LEOPARD AND NATURALLY ARCHBISHOP) BUT THE ENGINE IS NOT HUMAN AND WILL HANDLE ALL THE PIECES WITHOUT PREFERENCE. PROBABLY THE PIECE CHOICE PREFERENCE BY THE ENGINE WILL BE EITHER BOOK PROGRAMMED BUT ALSO PERSONALITY PROGRAMMING !!

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.":
Zied: ** SURE **
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:
" 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. "
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
3) "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."
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
4) " 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.”
Zied: ** SEE COMMENT ON 3 **
HGM
5) "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.
Zied
** " YES FOR ENGINE VS ENGINE TOURNAMENTS **
HGM
6) "An engine that has not yet received a start position through 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.)
Zied
** = IT COULD BE AN ALTERNATIVE, TO GIVE VARIETY TO THE OPENING POSITIONS; THIS WILL ALSO SHOWS FOR SURE THE IMPORTANCE OF AGTING SELECTION AS THIS RANDOMNESS WILL FOR SURE IN SOME POSITIONS FAVOR ONE OR ANOTHER SIDE !! **
HGM
7) "WinBoard currently has no support for a dialog between two engines during the prelude phase.
Zied
** ENGINE VS ENGINE GAMES SHOULD BY-PASS THIS EITHER BY USING A BOOK TO REACH A DESIRED OPEN POSITION (FOLLOWING A PRELUDE DEFINED PATH INSIDE THE BOOK) SO ENGINES SHOULD BE ABLE NORMALLY TO DIALOG BETWEEN EACH OTHERS EITHER VIA SELF PLAY MODE OR USING A BOOK ! **
HGM
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 (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:
a) Presents a board containing all Musketeer pieces to the user when it is the user's turn to select a piece type,
b) Engine is made aware of which piece the user clicked on to make his choice.
c) Engine 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.
Zied
** Please PRECISE THE LINK **
HGM
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.

[hgm]

Well, a small correction to start with: for playing under WinBoard, you of course need to use CECP (popularly known as 'WB protocol').

UCI engines can only run under WinBoard through an adapter.

Also note that the order of selections in the prelude follows completely from the position that emerges as a result of the prelude, and the knowledge which player chose what piece type. Stepping back through the prelude would merely make the pieces on the 'pre-gating squares' disappear one by one. I think there is too little to gain by actually showing such a trivial transformation of the position to make it worth the trouble of implementing this possibility. People are not idiots; they will be perfectly capable to imagine how a position would look with some of the gatable pieces absent. I also cannot see any reason why such an intra-prelude position should be presented to an engine; the only thing the engine could say about it would be something like "here I chose this piece / gating square (that you have already seen), because my built-in book said that I should".

[musketeerchess]

HG: Well, a small correction to start with: for playing under WinBoard, you of course need to use CECP (popularly known as 'WB protocol').
UCI engines can only run under WinBoard through an adapter.

Zied: Absolutely, programmer know that there is UCItoWB Adapter to make their engine compatible with Winboard.

HG: Also note that the order of selections in the prelude follows completely from the position that emerges as a result of the prelude, and the knowledge which player chose what piece type.

Zied: It's clear that the order of Piece Selection in Prelude is the order that will be used when the engine will show the Board when communicating with the Human to help him decide the Piece Selection and Gating Selection.

HG: Stepping back through the prelude would merely make the pieces on the 'pre-gating squares' disappear one by one. I think there is too little to gain by actually showing such a trivial transformation of the position to make it worth the trouble of implementing this possibility. People are not idiots; they will be perfectly capable to imagine how a position would look with some of the gatable pieces absent. I also cannot see any reason why such an intra-prelude position should be presented to an engine; the only thing the engine could say about it would be something like "here I chose this piece / gating square (that you have already seen), because my built-in book said that I should".

Zied: Agree. My request was to add these informations at the beginning of the PGN. That way it will make it possible to follow a game as if it is a normal one. PS and GS are real moves (in Musketeer Chess at least). The question is the Following: How can these informations be Added to PGN to have the information available?

For the moment it's not really obvious for all of us the usefulness of this process. Imho these informations are part of the game and thus should be ideally available when replaying the game. For engine vs engine or engine vs human using books, the PS and GS will be given by the book. But this should be available somewhere in the game at least for statistics and analysis purposes as the books can be improved with more games and by analysing them. That's the idea.