CrazyWa bug / Kyoto Shogi

[hgm]

For me the black pieces are written in light grey.



Kyoto Shogi is so unusual that one has to wonder whether it pays to put all the highly specialized features it needs in a general-purpose variant engine.

[Evert]

For me the black pieces are written in light grey.

Interesting.
It looks like it's printing all piece codes with high intensity set, while in Linux/OS X it doesn't have high intensity set on either the White or the Black pieces. Will investigate.

Kyoto Shogi is so unusual that one has to wonder whether it pays to put all the highly specialized features it needs in a general-purpose variant engine.

To an extend, that's true. On the other hand, it has to deal gracefully and sensibly with situations that come up as a result of rules defined by the user.
As long as it's something that can be dealt with at the start of the game, it should be fine.

[hgm]

I guess the problem is mostly in the heuristic for determining piece values, and how to incorporate 'latent value' (such as the ability of FIDE Pawns to promote). This would also depend on how difficult it would be to activate the latent value (how difficult it is to reach the promotion zone, which then depends on how far the piece is removed from the zone, and how many targets in the zone it can cover, and how long it will take before the opponent can no longer defend those targets). In Kyoto Shogi promotion is trivial, as you start inside the zone, and even non-captures can promote there. In case of a demotion it is important whether the demotion is mandatory.

Another problem is how the piece value depends on location. Usually a slight increase towards the center, with a magnitude depending on the speed of the piece, works already quite satisfactorily. But for irreversible pieces like a (non-promoting) Lance the location has huge impact on the value.

I guess the method based on future mobility goes a long way towards solving the latter issue. If some non-linearity could be added (e.g. using alpha*(1/nrOfMoves(from) + gamma)*SUM nrOfMoves(to)), and the primary counting would not only count target squares, but give some bonus for orthogonally adjacent squares, it might be able to reproduce the classical values quite well.

[hgm]

I did a quick hack of the WinBoard Alien Edition, so that it can support Kyoto Shogi. One problem is that the Alien Edition is rather old, and doesn't support the more advanced features of the pieceToCharTable, such as associating arbitrary pieces to be each other's (un)promoted form through the "^X" notation. But it has the kanji for all large Shogi variants, as well as on-the-fly generation of mnemonic piece symbols from the move table built into the WinBoard front-end. So I am sort of stuck with it for my Shogi-Variants package, and want Kyoto Shogi to be incorporated in that.

Rather than adding a new standard variant, I decided to support Kyoto Shogi as 5x5+4_shogi. (The holdings size distiguishes it from mini-Shogi.) This of course goes disastrously wrong w.r.t. promotions, in a way reconfiguring the primitive pieceToCharTable cannot fix. So I added a new feature / command-line option -demotions, which accepts a string in pieceToCharTable format. Its effect is that any piece for which an ID is defined in it will be considered 'auto-promoting' to the piece of the mentioned ID. For this to work one of the two pieces has to be defined with ID '+' in the normal pieceToCharTable, and a nick-name has to be defined for it as a normal letter. This way each piece can be known through a letter ID even in Shogi variants. The -demotions argument then tells how each piece must promote/demote after every move.

When a piece is auto-promoting this has many consequences:
* promotion suffixes on input moves will be ignored
* no promotion suffixes will be written on SAN output moves
* a '+' suffix will be written on output moves in coordinate notation
* it will be allowed to drop the piece in promoted form

To configure WinBoard Alien for Kyoto Shogi then needs

Code: Select all

-variant shogi
-boardWidth 5
-boardHeight 5
-holdingsSize 4
-pieceToCharTable "++BR++...G.TK++br++...g.tk"
-pieceNickNames "PN..LS.pn..ls."
-demotions "RGSPTB...N.L.rgsptb...n.l."
-loadPositionFile "kyoto.fen"

This selects BRGT as the 'unpromoted' forms, so that these will be displayed in the holdings for dropping; the PNLS, which are in general weaker and less likely to be dropped will require the user to hold the Shift key down during the drop. Otherwise there are no consequences at all of which pieces are designated as promoted; FENs will use the nicknames for auto-promoting pieces.

I am not yet sure how the promotion suffix is best treated. Requiring it on the moves and paying attention to it is more flexible, as you could then also do variants where promotion is not automatic (such as micro-Shogi, where you would write the '+' then only on captures). But in PGN it looks very ugly to have all these redundant suffixes; SAN already explicitly mentions whether a move is a capture. Plus that having suffixes raises the issue whether it shoud be a '+' or western-style mentioning the ID. It might be better to just inform WinBoard that automatic (i.e. suffix-less) promotion only occurs on captures, through an option -promoteOnCapture true/false.

The pieceToCharTable can be set by the engine (just as board and holdings size) through the 'setup' command. In the XBoard standard edition the -pieceNickNames can be set by embedding "=Y" behind a piece ID; the 'setup' parser splices the pieceToChar string by excising those for the purpose of setting the pieceToCharTable, and uses them to construct a pieceNickNames table. A similar method could be used for putting the 'demotions' info in the pieceToChar string, e.g. by embedding ">Z" to indicate the piece before it auto-promotes to Z. Then the setup command for Kyoto Shogi would look:

setup (+=P>R+=N>GB>SR>P+=L>T+=S>B...G>N.T>LK+=p>r+=n>gb>sr>p+=l>t+=s>b...g>n.t>lk) 5x5+4_shogi pskgt/5/5/5/TGKSP [-] w 0 1

Or (probably better), having '-' as an alternative for the '^' that the standard edition uses to define a piece as '+' and at the same time associate it with the upromoted piece 'X' by writing "^X", where "-X" would then also define the piece (and its partner) as auto-promoting to each other, and the "=Y" would still define the nicknames:

setup (-R=P-G=NBR-T=L-B=S...G.TK-r=p-g=nbr-t=l-b=s...g.tk) 5x5+4_shogi pskgt/5/5/5/TGKSP [-] w 0 1

To have the engine configure micro-Shogi would also require setting the -promoteOnCapture argument. Perhaps this could be done through a special symbol at the end of the pieceToChar string ('!' ?).

[GregNeto]

Great News!

I would like to give it a try (and the new crazywa).

pm me when you need an alpha tester ...

[hgm]

I still have to decide on how exactly to do this in the XBoard standard edition. I made a patch that uses -X in the pieceToCharTable string to define a pait (X, +X) that Shogi-promote to each other like ^X does, but at the same time sets both X an +X to auto-promote on every move. It oesn't seem useful to have only one member of the pair auto-promote.

The main question is how the fact that a piece is auto-promoting should affect the normal behavior of XBoard. In any case the move execution will automatically promote or demote the piece, even when the internal move encoding doesn't specify a promotion move.

For the move notation this has the consequence that promotion suffixes can be ignored. Or perhaps just the '+' should be ignored, so that promoting to another piece than the designated partner (e.g. because of contagion) can still be specifie. For SAN output the auto-promotion will not add a + suffix (an automatic consequence of the internal representation not specifyig a promotion), but for protocol move the '+' will be added if the moved piece is auto-promoting. This allows the engine to be stupid.

The legality checking now assumes that auto-promoting pieces can be dropped with either side up. Basically this is an independent property of auto-promotion, so in the future this should perhaps be controlled in another way (like through the Betza move specifications). For Kyoto an micro-Shogi this suffices, though.

Then there is the issue of the notation to use for promotion drops. For Kyoto Shogi I now define nicknames for all promoted pieces, and changed the SAN generation such that it prefers using nicknames over +X notation for auto-promoting pieces. I wonder if this isn't something I should always do for Shogi-promoted pieces that have nicknames (even when they do not auto-promote).

I also wonder if I should take provisions for the case where no nickname is defined for the promoted version of an auto-promoting pair. I suppose I could simply fall back on the usual +X notation,even for promotions. (I.e. write +P@e4 to drop a Kyoto Rook.)