musketeerchess
commented
4 years ago 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 !!
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.": 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: 1) " 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). "
2) "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.
ianfab
raphaeleliekakou
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.