Crowded Xiangqi

[yawnoc]

Would this half-board variant be difficult to implement?

rnbakabnr/pcp1p1pcp/9/PCP1P1PCP/RNBAKABNR

Spec: https://yawnoc.github.io/crowded-xiangqi

1. All is as standard Chinese Chess, except the below:
2. The number of ranks is reduced from ten to five.
3. Pawns and cannons start on the second rank.
4. Pawns can move sideways at the second-last rank (i.e. after advancing two steps forward).
5. Generals cannot can fly horizontally (i.e. it is legal for the two generals to be two steps apart on the central rank, where the two palaces overlap the two generals cannot simultaneously be in the central rank, where the two palaces overlap, unless there is an intervening piece).

I hope there's not some trivial forced mate for Red which I haven't been able to spot.

[ianfab]

Most of the rules can already be configured without any code changes via a variant configuration file. The only exception is that the flying general rule currently is implemented in the way that it includes all rook attacks, i.e., also horizontal ones.

[yawnoc]

I'm happy for the generals to be able to fly sideways (now that I think about it, it makes more sense if they can). I'll change the spec.

[gaintpd]

There is another mini-sized xiangqi variant, which is called minixiang, which is similar to minishogi. I do not know whether it is patented.

here is the link. https://www.chessvariants.com/page/MSminixiang

[ianfab]

@yawnoc With the rule change you applied your variant can be fully configured without any code changes. Have you already been able to define the variant configuration file for your variant, or do you need any help?

[yawnoc]

I think the following configuration works, although I've only tested it via CLI (haven't sat down to try hooking up a GUI yet).

# Crowded Xiangqi
[crowdedxiangqi:xiangqi]
maxRank = 5
startFen = rnbakabnr/pcp1p1pcp/9/PCP1P1PCP/RNBAKABNR w - - 0 1
mobilityRegionBlackKing = d3 e3 f3 d4 e4 f4 d5 e5 f5
mobilityRegionBlackFers = d3 e3 f3 d4 e4 f4 d5 e5 f5
mobilityRegionBlackElephant = *1 *2 *3 *4 *5
soldierPromotionRank = 4

What would it take for this variant to be added to the pychess site?

[ianfab]

The config looks good. In principle it should work in Winboard/XBoard, but I have not tested it.

For a variant to be added to pychess, the very first step of course is that it needs to be supported by Fairy-Stockfish, which in this case already comes out of the box. Since any variant causes additional implementation and maintenance effort for pychess, it should also prove to be sound and interesting in playtesting, and in the end the decision of course is up to gbtami whether he considers a variant to be worth adding. However, before asking him, especially for new variants, the variant should be heavily tested, because there are tons of variants, so only a very small selection of especially popular, traditional, and interesting variants can be implemented.

[yawnoc]

The XBoard GUI (4.9.1-1 amd64 installed using apt) seems to disrespect the mobility regions for generals and advisors, both those explicitly defined for black and those inherited from xiangqi for red.

test.fen: 3k5/9/3a1A3/9/5K3 w - - 0 1 The displayed possible moves seem OK...

...but you can make moves other than those displayed:

Horizontal flying is also broken:

Also pawns can move horizontally immediately, despite soldierPromotionRank.

These problems don't occur for the Fairy-Stockfish CLI, but only when you play via the XBoard GUI.

[ianfab]

The GUI does not really know all the rules of the game, it just has basic knowledge about the pieces that the engine communicates to it. For the displaying of legal moves, it has to rely on the engine to communicate them. However, in XBoard this filtering of legal moves is only applied if you enable the respective options (Test Legality, Show Target Squares), otherwise you can execute any illegal move on the board.

[yawnoc]

Strange; I got the expected behaviour by unchecking Test Legality.

[ianfab]

Interesting, at least it is working now :). Feel free to share your variant configuration at https://github.com/ianfab/Fairy-Stockfish/wiki/Variant-configuration#variant-configuration-collection.

[yawnoc]

Feel free to share your variant configuration at [...]

Have done!

There seems to be one last strange glitch with XBoard: whenever a pawn move has its destination in the last rank, XBoard will disappear the pawn. (This glitch doesn't happen for normal xiangqi.)

FEN: 4k4/9/9/p8/R4K3 b 0 1 Behold, a pawn about to capture a chariot on the last rank...

... which vanishes upon doing so (is this what the notation =. means?):

Hilariously, Fairy-Stockfish will insist that the pawn hasn't disappeared, and try to move it horizontally:

A workaround is to redo the problem pawn moves manually by switching to 'Edit Game' mode (which for some reason doesn't disappear the pawn).

[ianfab]

This issue also occurred for Janggi, and the only way I found to fix it was to use a different symbol (in the pieceToCharTable) for the soldier than the pawn (first slot). For pieces that are represented as pawns XBoard apparently assumes that they get promoted, but since no promotion piece is specified, the soldier just disappears.

[HGMuller]

I am not sure what exactly you are doing. Normally XBoard automatically promotes Pawns when they reach the last rank, and if the move had no promotion suffix, the promotion choice defaults to Queen. (For moves entered by mouse it would trigger the promotion popup / sweep selection.) But in games where a Queen is not in the pieceToCharTable, this will make it simply disappear.

In Xiangqi this is suppressed, as Pawns do not promote there. So it seems you are not playing this game as 'variant xiangqi'. That would also explain why confinement of K and A to the Palace is not enforced; XBoard only does that in Xiangqi. (There are some versions of XBoard around where this is broken, however; At some point I completely rewrote the XBoard move generator, but forgot to put in the confinement. This was fixed long ago, though.)

[yawnoc]

So it seems you are not playing this game as 'variant xiangqi'.

Correct, I am playing a custom variant loaded by using ./stockfish load variants.ini in the Engine command. The built-in 'variant xiangqi' in XBoard does not have the disappearing-pawn glitch.

Would setting the promotion suffix to 'pawn' work? This would seem a better fix (from a semantic point of view) than using archbishops as substitutes for pawns in the pieceToCharTable.

[HGMuller]

It would not be a fix but a work-around. When an engine plays a custom variant, it is supposed to communicate the parameters of this variant (which include a 'parent variant') to the GUI. For this variant you would obviously need the parent variant to be Xiangqi, because you don't want Pawns to promote, capture straight ahead, and acquire a sideway move wen on the othe board half. Apparently it doesn't specify that, and this is what would have to be fixed.

It also puzzles me that you can do moves to a square that is not highlighted. XBoard is supposed to refuse those.

[ianfab]

Fairy-Stockfish does specify the parent variant as xiangqi in the setup command, that should not be the issue. The parent variant can be explicitly configured via the variantTemplate option in the variant configuration.

[HGMuller]

Well, that is weird. The code for deciding whether Pawns should promote just tests for the variant, not whether this was used as parent for something else. Problem is that I cannot test it; I did download the Fairy-Stockfish binary, but I don't have the configuration file that defines this game.

[ianfab]

You can find the configuration at https://github.com/ianfab/Fairy-Stockfish/wiki/Variant-configuration#crowded-xiangqi. This already contains the workaround though, so the pieceToCharTable needs to be adapted to reproduce the issue. On the command line, I get the following:

xboard
variant crowdedxiangqi

setup (.N.R.ABP.K.C...........n.r.abp.k.c..........) 9x5+0_xiangqi rnbakabnr/pcp1p1pcp/9/PCP1P1PCP/RNBAKABNR w - - 0 1
piece R& R
piece A& F
piece C& mRcpR
piece P& fsW
piece N& nN
piece B& nA
piece K& W

[HGMuller]

OK, I copied that definition into a file, changed the Pawns back to Pawns, started SF with the instruction to load it, and selected the variant. Then I played a game in Edit Game mode. And I don't have this problem. The Pawn stays a Pawn on moving to 5th rank (or 1st rank). Also when I let Stockfish make the move.

[ianfab]

I also can not reproduce it in edit game mode, but when letting the engine make the move, the issue is triggered in XBoard (commit c971f92, did not check latest version yet; Edit: same with 162b833). E.g., in this game I let the engine make the last move:

[Event "Computer Chess Game"]
[Site ""]
[Date "2020.10.07"]
[Round "-"]
[White ""]
[Black "Fairy-Stockfish 031020 LB 64 BMI2"]
[Result "*"]
[TimeControl "60+1"]
[Variant "crowdedxiangqi"]
[VariantMen "P:fsW;N:nN;R:R;A:F;B:nA;K:W;C:mRcpR"]
[FEN "rnbakabnr/pcp1p1pcp/9/PCP1P1PCP/RNBAKABNR w 0 1"]
[SetUp "1"]

{--------------
r n b a k a b n r
p c p . p . p c p
. . . . . . . . .
P C P . P . P C P
R N B A K A B N R
white to play
--------------}
1. g3 a3 2. gxg4 axa2 3. gxg5 axa1=. {+1,30/20 6}
*

[HGMuller]

OK, it seems to matter whether legality testing is on or off. The Pawn only disappears here when I switch it off. I will trace back why exactly this happens.

[HGMuller]

OK, I figured it out. XBoard's move generator specifies if a move is a promotion. The move parser tests whether moves that should be promotions contain a promotion suffix, and if not, appends a default. (That default is usually the ID defined for the Queen symbol in the pieceToChar, but here that is invalid, as the Queen does not participate.) The native move generator refrains from calling Pawn moves to last rank promotions in Xiangqi, to prevent this appending there. Only text moves need to be parsed, so moves entered by mouse will bypass this entire procedure, and have their own code for deciding when to invoke the promotion-choice procedure.

But in this variant the engine sends a 'piece' command for the Pawn. This overrules the native move generator, and instead uses the Betza generator. This Betza generator did not make an exception for last-rank Pawn moves in Xiangqi. So redefining the Pawn move did have the undesired effect of making the Pawn promotable, even in Xiangqi.

[ianfab]

Since the requested variant is supported via configuration, I am closing this.