ianfab
commented
4 years ago Thanks, I was not aware of all the possibilities in the pieceToCharTable. However, admittedly I just did not care much about even trying for Kyoto shogi, since I assumed that it simply will not work at all.
Most of the decisions for FEN and move notation in Fairy-SF is not based on what would make most sense for the specific variant at question, but by how to design it that it is unambiguous for all variants that can be configured in Fairy-Stockfish. Since promotions and demotions could be optional, I decided to always indicate them. One limitation that also has an impact, is that in Fairy-Stockfish a piece type can only exist once per variant, i.e., you can not have a G gold and a T gold/tokin. That is why promoted types that have the same movement always need to be represented with a + in both the FEN and the promotion move, otherwise the piece characters could clash.
Is there a realistic chance of being able to play Kyoto shogi (or micro shogi) in XBoard by adaptations in Fairy-SF or would it anyway need an explicit implementation in XBoard?
HGMuller
There are several problems with the Kyoto Shogi implementation under CECP. Kyoto Shogi is a pretty hard game to implement as an engine-defined variant, or even to configure a GUI for, if the GUI doesn't already know it. XBoard already had some general features that were helpful implementing it, but I still had to add some others. And IIRC the engine cannot control all of those through the protocol; it still needs some configuration by the user.
Anyway, the pieceToCharTable that Fairy-Stockfish sends is no good at all. It doesn't even mention the basic pieces (PSGLK), it is just the pieceToCharTable for Chess (PNBRQK). But the pieceToCharTable in CECP does more than just defining piece names: it must also define how pieces promote (if they have Shogi-style promotions). The best way to do that is to use a two-character combination ^L in a position of the pieceToCharTable for the promoted version of L; XBoard would use the notation +L for such a piece in FEN and SAN.
XBoard does allow defining aliases for piece names, however, and the pieceToCharTable send in the setup command can do that too, by writing =Y directly behind the ID of a piece that you want to be known also under the name Y. In Kyoto Shogi it seemed a good idea to define nicknames for all the 'promoted' pieces, as they are not really promoted at all, but just alternating forms of the same piece. The form that starts in the initial position has hardly any different status from the other, and I see that in the FEN for the starting position Fairy-Stockfish even considers some of the initial pieces the promoted form, which supports this view. So it seemed a good idea to not denote the Rook as +P, but just as R, which could be achieved by writing ^P=R in the Rooks location of the pieceToCharTable. Similarly, the Tokin can be T, and used as a basic piece, while the alias for a 'promoted' Tokin +T can then be L for Lance. The 'promotion on drop' peculiar to Kyoto Shogi can then be written using the alias, R@c3, rather than +P@c3 or P@c3+.
The holdings size specified by Fairy-Stockfish in the setup command is wrong too; it should not be 10 but 4. There are only 4 different piece types that can go in the holdings; R and P are not different piece types in Kyoto Shogi, and either one could be dropped as itself or the other. XBoard chooses to display them as their 'unpromoted' forms P, S, G or T when in the holdings (so the usual principle of 'demote on capture' remains applicable). It then allows promotion on dropping (IIRC by keeping the Shift key pressed during the drop).
Then there is the issue of move notation. I saw that Fairy-Stockfish indicates the 'demotions' by a minus suffix. I admit that this is the logical thing to do. But in move notations the hyphen is commonly used for other purposes, so that this easily leads to ambiguities. Of course in the protocol moves are not supposed to contain hyphens. But it would be very unfortunate if a different move parser was needed for protocol and other moves, especially since CECP also allows sending of move in SAN format (yegh!). In Kyoto Shogi promotion or demotion suffixes are of course entirely redundant; the only reason to include them would be to 'coach' a GUI that doesn't know the rules, to make it aware the move is a promotion. This could of course also be achieved by using chess-style promotion suffixes, e1e2r (using the alias) instead of e2e1+ and then e2e1p instead of e2e1- (without the need to introduce any new promotion suffix, even without using alias, as the basic piece will always have its own ID).
Note that adding promotion suffixes helps to make an ignorant GUI perform the engine moves correctly, but doesn't do anything for user moves. To allow the engine to help the GUI performing the user move correctly, it can use the highlight protocol, indicating the move targets in blue. The GUI will interpret the blue highiglight as a forced Shogi-style promotion (no promotion popup or anything).