CrazyWa bug / Kyoto Shogi

[hgm]

While I was implementing Kyoto Shogi in CrazyWa, I noticed that it did not react to the 'level' command, but always plays at its default TC (40 moves/ 5min). Which I never noticed before, as I always test at 40 moves/5 min.


This was due to a stupid bug. CrazyWa clears the first byte of the input buffer as soon as it extracted the first word for recognizing it as a command, so the next call to the command parser would read a new line. (Commands that could not be parsed immediately stay in the buffer, and would then be parsed on the next call, usually after the search aborted.) But I was parsing the 'level' command with a sscanf(inBuf, "level %d %d %d", ... , and this never saw anything, as the leading 'l' at that time was already clobbered. It should have done sscanf(inBuf+6, "%d %d %d", ... , similar to what I did for extracting parameters of the other commands.

So CrazyWas was always playing 40 moves/5 min. No wonder it performed below par in tournaments with a longer TC!

Anyway, Kyoto Shogi seems to work. Cannot really test it well, as there is no satisfactory way to do Kyoto Shogi in WinBoard yet. The alternating promotion and demotion of the pieces, and the possibility to drop pieces in promoted form, is just to weird. I guess I will add a standard variant 'kyoto' to WinBoard, which allows piece to be dropped in promoted form, and has some UI to enter such a move. (Perhaps clicking the selected piece in the holding to make it 'flip'?) And where a '+' promotion suffix on a move with an already promoted piece would be considered legal, and make the piece demote.

Crazywa currently requires the '+' suffix on every move except King moves (as Kings cannot promote), which seems redundant. OTOH, if the new standard variant should also be able to act as a parent to micro-Shogi, where promotion only occurs on capture, it does seem a good idea to keep indicating it explicitly. For dropping the promoted version of a piece it now uses alternative piece IDs (R, G, T and B instead of +P, +N, +L and +S). Not sure if this is tenable if it must be possible to associate the base and promoted types differently.

[Evert]

SjaakII can play Kyoto Shogi, and if you grab the source you can use the referee program Sjef to play matches between two engines, should you wish to do that (Sjef may only work on Linux).
It has the same restriction of requiring the redundant +, which I've been meaning to make optional. Haven't gotten around to that though.

[hgm]

What format does Sjef need for the promotion drops? (And how does it encode the promoted pieces in FEN?) I was in doubt wether to use R@c1, +P@c1 or P@c1+. I finally decided to use a separate ID for the promoted pieces, (i.e. R@c1), also because it is rather arbitrary which side of the pieces should be considered the promoted one. And for technical reasons the way I do that in CrazyWa internally might not be the most intuitive one: it was most convenient to have P, L and N be unpromoted, so that they would automatically obey the existing drop restrictions, and the extra code for dropping the promoted version can simply drop everywhere.

[GregNeto]

Certainly I will be giving it a try, kyoto is my favorite form of chess!

I have been working an a very basic kyoto shogi engine in golang, it uses good old minimax ...

It is monochrome, flipping the board and pieces after makemove. The hands are part of the position representation. Every move, even a drop, is made with a from-to encoding

func StartGame() State {
s := State{}
s.position = [41]int{
0, 0, 0, 0, 0, 0, 0, 0,
-2, -6, -1, -4, -8,
0, 0, 0, 0, 0,
0, 0, 0, 0, 0,
0, 0, 0, 0, 0,
8, 4, 1, 6, 2,
0, 0, 0, 0, 0, 0, 0, 0}
s.halfmove = 0
s.score = 0
return s
}

func (s State) DisplayBoard() {

pieces := map[int]string{
0: ".", //empty
-1: "k", //king
1: "K", //KING
-2: "p", //pawn
2: "P", //PAWN
-3: "r", //rook
3: "R", //ROOK
-4: "s", //silver
4: "S", //SILVER
-5: "b", //bishop
5: "B", //BISCHOP
-6: "g", //gold
6: "G", //GOLD
-7: "n", //knight
7: "N", //KNIGHT
-8: "t", //tokin
8: "T", //TOKIN
-9: "l", //lance
9: "L", //LANCE

-10: "1", // one pawn in hand
10: "1",
-11: "1", // one rook in hand
11: "1",
-12: "1", // one silver in hand
12: "1",
-13: "1", // one bishop in hand
13: "1",
-14: "1", // one gold in hand
14: "1",
-15: "1", // one knight in hand
15: "1",
-16: "1", // one tokin in hand
16: "1",
-17: "1", // one lance in hand
17: "1",
-18: "2", // two pawns in hand
18: "2",
-19: "2", // two rooks in hand
19: "2",
-20: "2", // two silvers in hand
20: "2",
-21: "2", // two bishops in hand
21: "2",
-22: "2", // two golds in hand
22: "2",
-23: "2", // two knights in hand
23: "2",
-24: "2", // two tokins in hand
24: "2",
-25: "2", // two lances in hand
25: "2",
}


I always wondered if it would be possible to use Winboard Alien with the "setup FEN" command to Play, but work, time and lacking programming skill stood in the way

[GregNeto]

and yes, both sides/faces of the piece are represented in the hands; when one piece is captured, both sides are added in hand, when a piece is dropped both sides are cleared

[hgm]

The current version of WinBoard Alien would not accept the demotion, and flag a promotion suffix on already-promoted pieces as an illegal move. It also would not recognize a promotion suffix or prefix on drop moves.

Another problem would be to associate the pieces to the correct promoted form, which is entirely different as WinBoard normally does it (which is based on regular Shogi). You ca work around that by using external bitmaps, but then WinBoard would still associate a wrong move with it, and you could only play with legality checking off.

The regular edition of WinBoard now also supports the 'setup' command, and has a more advanced pieceToCharTable, which can associate arbitrary pieces as each others promotion partner, by interpreting "^X" as the promoted form of "X". It would designate such a pieces as +X in SAN or FEN. This would be able to handle Kyoto Shogi when we are prepared to indicate +P, +L, +N and +S as R, T, G and B, respectively.

That would still leave the issue of demotion and promotion drops. A new symbol in the pieceToCharTable could be defined, similar to ^, but indicating 'bi-directional promotion' ("-X" ?), generally applicable across variants. This could then also be made to imply that such pieces can be dropped in promoted form. Then no new variant would have to be introduced, and Kyoto Shogi could be played as engine-defined variant based on Shogi. Except that the promotion zone would be wrong: it would be assumed to be 1 rank deep, on a 5x5 board, and it would need to be 5 ranks deep for Kyoto.

So perhaps zone depth should also have an overrule option, which also could be transmitted through a setup command. E.g.

setup (PN-S-PLS...-N.-LKpn-s-pls...-n.-lk) 5x5+4=5_shogi p+nks+l/5/5/5/+LSK+NP [-] w 0 1

where the =5 would overrule the normal zone depth.

Purists would probably object against the opening position containing promoted pieces, and insist that the Knight should be +G instead. This is why I tried to avoid the '+' notation altogether. WinBoard already has an option to define alternative IDs for pieces, which would then be recognized on input, but never used on output. We could adopt the convention that on bi-directionally promoting pieces, the nicknames would also be used on output, instead of the +X notation. The pieceToCharTable in the 'setup' command can already define the nicknames, by inclusion of "=Y" after the normal piece ID. E.G. "-P=R" would do the trick, and make WinBoard use R where it would otherwise have used +P.

and yes, both sides/faces of the piece are represented in the hands; when one piece is captured, both sides are added in hand, when a piece is dropped both sides are cleared

I thought about doing it that way in the GUI as well, but the problem is that you would have to display 8 piece types in the hand, with a board with only 5 ranks. The latest WinBoard is capable of having the holdings stick out (like in Wa Shogi), but this is pretty ugly. I would prefer to be able to flip the pieces by some kind of mouse click on the holdings. Actually it would be best if the R, G, T and B would be displayed by default (after capture), as you would almost always want to drop those. (Although for B this is not very clear.) So then P, N, L and S would have to be the promoted forms.

[Evert]

What format does Sjef need for the promotion drops? (And how does it encode the promoted pieces in FEN?) I was in doubt wether to use R@c1, +P@c1 or P@c1+. I finally decided to use a separate ID for the promoted pieces, (i.e. R@c1), also because it is rather arbitrary which side of the pieces should be considered the promoted one. And for technical reasons the way I do that in CrazyWa internally might not be the most intuitive one: it was most convenient to have P, L and N be unpromoted, so that they would automatically obey the existing drop restrictions, and the extra code for dropping the promoted version can simply drop everywhere.

Sjef is completely agnostic with respect to move notation and FEN. It actually depends on a third "referee" engine to monitor the game, adjudicate and (optionally) provide FEN and SAN data (for which it looks for some custom feature strings). For the most part, it just hands moves from engine 1 straight to engine 2. The only processing it does, I think, is to chain multi-leg moves.

SjaakII, however, uses Shogi-style notation for moves in Kyoto (P@c1+ to drop a promoted Pawn), but that's only because the definition was written that way (could be changed easily). I think the main reason for that was that doing so actually allows you to play engine matches using XBoard (which is ok with promoting pieces every move, but will complain about dropping promoted pieces when it thinks you only have the unpromoted form in hand).

[Evert]

That would still leave the issue of demotion and promotion drops. A new symbol in the pieceToCharTable could be defined, similar to ^, but indicating 'bi-directional promotion' ("-X" ?), generally applicable across variants. This could then also be made to imply that such pieces can be dropped in promoted form. Then no new variant would have to be introduced, and Kyoto Shogi could be played as engine-defined variant based on Shogi. Except that the promotion zone would be wrong: it would be assumed to be 1 rank deep, on a 5x5 board, and it would need to be 5 ranks deep for Kyoto.

Can't that also be already defined in the piece strings? Or am I mixing things up?
Promotion moves can obviously also be specified in response to "lift".

[hgm]

True, but things in general work more smoothly is they do not require communication with the engine. And it puts a rather large burden on the engine to support the highlight protocol. If the depth of a promotion zone can be adapted by just =N in the setup command, as it should for rectagular zones, this would be enormously simpler.

[hgm]

SjaakII can play Kyoto Shogi, and if you grab the source you can use the referee program Sjef to play matches between two engines, should you wish to do that (Sjef may only work on Linux).
It has the same restriction of requiring the redundant +, which I've been meaning to make optional. Haven't gotten around to that though.

Which version of Sjaak II plays Kyoto Shogi? I downloaded version 1.4.1, (Windows version), but Kyoto Shogi is not in the list.