I vaguely remember that we discussed whether WinBoard would be able to support Kyoto Shogi. The issue here being that pieces, once promoted, can (actually: must) demote again on board moves, and that drops can be promotions at the same time. I am not sure this would currently work in WinBoard. But it does not seem difficult to make it work, in the new framework for promotions, where a table indicates what the promoted or demoted partner of each piece is. There would be an issue for how to notate moves (E.g. +G@a3 or G@a3+).
Is Sjaak II capable of supporting Kyoto Shogi?
Andrew Lin proposed we should play Kyoto Shogi at the next ICGA Olympiad.
Kyoto Shogi (Sjaak?)
Moderators: hgm, Rebel, chrisw
-
hgm
- Posts: 27790
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Kyoto Shogi (Sjaak?)
I believe so, but I don't remember what exactly it outputs for moves. I seem to recall it's something ugly.
I'll look it up and let you know. Obviously it was never tested under XBoard or against another engine.
I'll look it up and let you know. Obviously it was never tested under XBoard or against another engine.
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Kyoto Shogi (Sjaak?)
It can indeed play the game, using "westernised" promotion notation:
It sends promotion drops in the form "promoted_id@square", but I suppose it could be easily changed to use "id@square+" instead. Same for Shogi-style promotions.
Because the promotion choice is unique (and compulsory) the inclusion of the promotion character is superfluous, but I obviously never made it possible to just omit it (which I think is somewhere on my todo list).
Perhaps not surprising, but XBoard doesn't like it:
Code: Select all
Variant: Kyoto Shogi
Board: 5x5
XBoard pieces: "PNBR.....GS.......L...TKpnbr.....gs.......l...tk"
XBoard parent: fairy
FEN: "pgkst/5/5/5/TSKGP w 0 1"
Piece: King
Move: leap (0,1)|(1,1)
Symbol: "K", "K,k"
Flags: royal
Piece: Pawn
Symbol: "P", "P,p"
Move: step N
Promotion: all, all, "R"
Optional promotion: empty, empty
Piece: Rook
Symbol: "R", "R,r"
Move: slide (H,V)
Promotion: all, all, "P"
Demotion: "P"
Optional promotion: empty, empty
Piece: Tokin
Symbol: "T", "T,t"
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Promotion: all, all, "L"
Optional promotion: empty, empty
Piece: Lance
Symbol: "L", "L,l"
Move: step 5N
Promotion: all, all, "T"
Demotion: "T"
Optional promotion: empty, empty
Piece: Silver general
Symbol: "S", "S,s"
Move: aleap (0,1)|(1,1)|(1,-1)|(-1,-1)|(-1,1)
Promotion: all, all, "B"
Optional promotion: empty, empty
Piece: Bishop
Symbol: "B", "B,b"
Move: slide (D,A)
Promotion: all, all, "S"
Demotion: "S"
Optional promotion: empty, empty
Piece: Gold general
Symbol: "G", "G,g"
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Promotion: all, all, "N"
Optional promotion: empty, empty
# Define the pieces
Piece: Knight
Symbol: "N", "N,n"
Move: aleap (1,2)|(-1,2)
Promotion: all, all, "G"
Demotion: "G"
Optional promotion: empty, empty
Rule: keep capture, allow drops, promote drop
Rule: repeat4 = draw
Rule: perpetual = loss
Because the promotion choice is unique (and compulsory) the inclusion of the promotion character is superfluous, but I obviously never made it possible to just omit it (which I think is somewhere on my todo list).
Perhaps not surprising, but XBoard doesn't like it:
Code: Select all
1065 <first : # New game 'Kyoto Shogi'
1091 <first : setup (PNBR.....GS.......L...TKpnbr.....gs.......l...tk) 5x5+4_fairy pgkst/5/5/5/TSKGP w 0 1
recognized 'fairy' (-1) as variant kyoto_shogi
shuffleOpenings = 0
FEN castling rights: 134 134 4 134 134 4
1254 <first : piece K& K
1254 <first : piece P& fW@4
1254 <first : piece R& R
1254 <first : piece T& WfF
1254 <first : piece L& fR@4
1254 <first : piece S& FfW
1254 <first : piece B& B
1254 <first : piece G& WfF
1254 <first : piece N& ffN@3
1254 <first : pong 1
3635 >first : lift e1
3637 <first : highlight 5/5/5/4B/5
3638 <first : choice R
4660 >first : put e2
nps: w=-1, b=-1
nps: w=-1, b=-1
4661 >first : time 1000
4661 >first : otim 1000
book hit = (NULL)
4661 >first : e1e2
4778 <first : choice R
4779 <first : Error (Illegal move or unknown command): e1e2
-
hgm
- Posts: 27790
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Kyoto Shogi (Sjaak?)
There are several reasons why it would not work this way. But just to be sure, was legality checking off, here? It is strange XBoard would ignore the "choice R" here; landing on a blue square should otherwise always pay attention to a "choice" command, and even wait for one if the engine had not yet sent it. So on input it should have understood e1e2r, which makes it strange it only sends e1e2 to the engine. What happened in the display? did the Pawn indeed change into a Rook?
A problem is that the pieceToChar string defines 9 piece types, while the holdings make only room for 4. As there is no indication what is a promoted version of what, XBoard will assume everthing that does not fit is a promoted Pawn, and demote accordingly.
XBoard already does have a feature that might come in handy, though: there is a secondary pieceToCharTable set by the -pieceNicknames option, which is consulted first when converting IDs to pieces (such as it would when interpreting a promotion suffix). Originally I added that to allow reading of non-compliant FENs. But I made it configurable through the setup command by allowing writing X=Y for an ID in the pieceToChar string, where X would then go into the pieceToCharTable, but Y would become the pieceNickName for the same piece. I did this as preparation for Maka Dai Dai Shogi, where pieces sometimes must promote to the piece they capture, rather than to their own promoted type. As the contageous pieces can also (or only?) be promoted pieces, a notation for forcing this would be cumbersome, or even ambiguous, like e1xe2=+D or e1e2+d. To avoid that I planned to define nicknames for the +D, which then would be used in the promotion suffix or choice command printed by the engine.
This can also be used in Kyoto Shogi: define the Knight as ^G=N in the pieceToChar string, to tell XBoard it is a promoted Gold, and still be able to use the 'n' as promotion suffix. The definition ^G would define the Knight ID as '+', and at the same time would associate it with G, so that on capture a Knight would demote to Gold. And thus also no space in the holdings would be reserved for N.
The only problem is then to promote on drops. I would have to check if the notation G@e2+would work to drop a Knight; it could be that XBoard doesnot test forpromotion suffixes on drop moves. +G@e2 would probably be rejected because there is no N in the holdings. Which is a pity, because it would parse in the same way as N@e2, which is a nicer notation. I guess the MakeMove and legality testing could be changed here to interpret dropping of a piece with ID '+' as promotion on drop (i.e. decrease the holdings count for the demoted type, rather than the piece itself). And then the problem still exists of how the user should enter such a move.
It is a bit annoying that this would only work for engines that highlight. I could make XBoard pay attention to a 'choice' command on every square, when no 'highlight' is received. (I.e. treat every to-square like it is blue or purple, depending on the length of the choice string.) But this would be problematic if the promotion depends on where you land. In Kyoto Shogi that is fine, but in micro-Shogi it would depend on whether you capture or not. (And there could be games with non-standard promotion zones.) Perhaps an engine should be allowed to send "choice ?" in response to 'lift' to invoke the promotion procedure on landing (i.e. virtually turning all squares blue), so that XBoard would send an extra 'put' when the piece lands, put does not consider the move entry completed before it received another 'choice' command with a real piece.
A problem is that the pieceToChar string defines 9 piece types, while the holdings make only room for 4. As there is no indication what is a promoted version of what, XBoard will assume everthing that does not fit is a promoted Pawn, and demote accordingly.
XBoard already does have a feature that might come in handy, though: there is a secondary pieceToCharTable set by the -pieceNicknames option, which is consulted first when converting IDs to pieces (such as it would when interpreting a promotion suffix). Originally I added that to allow reading of non-compliant FENs. But I made it configurable through the setup command by allowing writing X=Y for an ID in the pieceToChar string, where X would then go into the pieceToCharTable, but Y would become the pieceNickName for the same piece. I did this as preparation for Maka Dai Dai Shogi, where pieces sometimes must promote to the piece they capture, rather than to their own promoted type. As the contageous pieces can also (or only?) be promoted pieces, a notation for forcing this would be cumbersome, or even ambiguous, like e1xe2=+D or e1e2+d. To avoid that I planned to define nicknames for the +D, which then would be used in the promotion suffix or choice command printed by the engine.
This can also be used in Kyoto Shogi: define the Knight as ^G=N in the pieceToChar string, to tell XBoard it is a promoted Gold, and still be able to use the 'n' as promotion suffix. The definition ^G would define the Knight ID as '+', and at the same time would associate it with G, so that on capture a Knight would demote to Gold. And thus also no space in the holdings would be reserved for N.
The only problem is then to promote on drops. I would have to check if the notation G@e2+would work to drop a Knight; it could be that XBoard doesnot test forpromotion suffixes on drop moves. +G@e2 would probably be rejected because there is no N in the holdings. Which is a pity, because it would parse in the same way as N@e2, which is a nicer notation. I guess the MakeMove and legality testing could be changed here to interpret dropping of a piece with ID '+' as promotion on drop (i.e. decrease the holdings count for the demoted type, rather than the piece itself). And then the problem still exists of how the user should enter such a move.
It is a bit annoying that this would only work for engines that highlight. I could make XBoard pay attention to a 'choice' command on every square, when no 'highlight' is received. (I.e. treat every to-square like it is blue or purple, depending on the length of the choice string.) But this would be problematic if the promotion depends on where you land. In Kyoto Shogi that is fine, but in micro-Shogi it would depend on whether you capture or not. (And there could be games with non-standard promotion zones.) Perhaps an engine should be allowed to send "choice ?" in response to 'lift' to invoke the promotion procedure on landing (i.e. virtually turning all squares blue), so that XBoard would send an extra 'put' when the piece lands, put does not consider the move entry completed before it received another 'choice' command with a real piece.
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Kyoto Shogi (Sjaak?)
No, it wasn't - but turning it off doesn't actually change behaviour.hgm wrote:There are several reasons why it would not work this way. But just to be sure, was legality checking off, here?
No, it didn't.It is strange XBoard would ignore the "choice R" here; landing on a blue square should otherwise always pay attention to a "choice" command, and even wait for one if the engine had not yet sent it. So on input it should have understood e1e2r, which makes it strange it only sends e1e2 to the engine. What happened in the display? did the Pawn indeed change into a Rook?
That's another issue for sure. I'm not sure what the best way to fix this is. In fact, I'm not sure why the holding size is reported as 4, given that there are more piece types defined. Probably because they're all demoted and an (unpromoted, promoted) pair is counted only once - except in this case they should arguably be counted twice because the promotion goes both ways.A problem is that the pieceToChar string defines 9 piece types, while the holdings make only room for 4. As there is no indication what is a promoted version of what, XBoard will assume everthing that does not fit is a promoted Pawn, and demote accordingly.
How does this work, exactly? Do I replace "N" in the PtC string with "^G=N"?XBoard already does have a feature that might come in handy, though: there is a secondary pieceToCharTable set by the -pieceNicknames option, which is consulted first when converting IDs to pieces (such as it would when interpreting a promotion suffix). Originally I added that to allow reading of non-compliant FENs. But I made it configurable through the setup command by allowing writing X=Y for an ID in the pieceToChar string, where X would then go into the pieceToCharTable, but Y would become the pieceNickName for the same piece. I did this as preparation for Maka Dai Dai Shogi, where pieces sometimes must promote to the piece they capture, rather than to their own promoted type. As the contageous pieces can also (or only?) be promoted pieces, a notation for forcing this would be cumbersome, or even ambiguous, like e1xe2=+D or e1e2+d. To avoid that I planned to define nicknames for the +D, which then would be used in the promotion suffix or choice command printed by the engine.
This can also be used in Kyoto Shogi: define the Knight as ^G=N in the pieceToChar string, to tell XBoard it is a promoted Gold, and still be able to use the 'n' as promotion suffix. The definition ^G would define the Knight ID as '+', and at the same time would associate it with G, so that on capture a Knight would demote to Gold. And thus also no space in the holdings would be reserved for N.
Indeed. Perhaps having something similar to the drag promotion, where you can drag backward to cycle through the possible choices for the piece to drop (which would be just 2 choices, of course)?The only problem is then to promote on drops. I would have to check if the notation G@e2+would work to drop a Knight; it could be that XBoard doesnot test forpromotion suffixes on drop moves. +G@e2 would probably be rejected because there is no N in the holdings. Which is a pity, because it would parse in the same way as N@e2, which is a nicer notation. I guess the MakeMove and legality testing could be changed here to interpret dropping of a piece with ID '+' as promotion on drop (i.e. decrease the holdings count for the demoted type, rather than the piece itself). And then the problem still exists of how the user should enter such a move.
Having a well-defined "lift" for holdings would be useful, but I don't think having the whole board light up in response to highlight would be very nice. Perhaps a variation where you only visibly highlight if the drop zone doesn't equal every available square? Or the highlight could be made translucent, so you can still see the board texture beneath it. That would also be less intrusive.It is a bit annoying that this would only work for engines that highlight. I could make XBoard pay attention to a 'choice' command on every square, when no 'highlight' is received. (I.e. treat every to-square like it is blue or purple, depending on the length of the choice string.) But this would be problematic if the promotion depends on where you land. In Kyoto Shogi that is fine, but in micro-Shogi it would depend on whether you capture or not. (And there could be games with non-standard promotion zones.) Perhaps an engine should be allowed to send "choice ?" in response to 'lift' to invoke the promotion procedure on landing (i.e. virtually turning all squares blue), so that XBoard would send an extra 'put' when the piece lands, put does not consider the move entry completed before it received another 'choice' command with a real piece.
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Kyoto Shogi (Sjaak?)
Code: Select all
Variant: Kyoto Shogi
Board: 5x5
XBoard pieces: "P^G^S^P.....GS.......^T...TKp^g^s^p.....gs.......^t...tk"
XBoard parent: shogi
FEN: "pgkst/5/5/5/TSKGP w 0 1"
Piece: King
Move: leap (0,1)|(1,1)
Symbol: "K", "K,k"
Flags: royal
Piece: Pawn
Symbol: "P", "P,p"
Move: step N
Promotion: all, all, "+"
Optional promotion: empty, empty
Piece: Rook
Symbol: "+P", "+P,+p"
Move: slide (H,V)
Promotion: all, all, "P"
Demotion: "P"
Optional promotion: empty, empty
Piece: Tokin
Symbol: "T", "T,t"
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Promotion: all, all, "+"
Optional promotion: empty, empty
Piece: Lance
Symbol: "+T", "+T,+t"
Move: step 5N
Promotion: all, all, "T"
Demotion: "T"
Optional promotion: empty, empty
Piece: Silver general
Symbol: "S", "S,s"
Move: aleap (0,1)|(1,1)|(1,-1)|(-1,-1)|(-1,1)
Promotion: all, all, "+"
Optional promotion: empty, empty
Piece: Bishop
Symbol: "^S", "^S,^s"
Move: slide (D,A)
Promotion: all, all, "S"
Demotion: "S"
Optional promotion: empty, empty
Piece: Gold general
Symbol: "G", "G,g"
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Promotion: all, all, "+"
Optional promotion: empty, empty
# Define the pieces
Piece: Knight
Symbol: "+G", "+G,+g"
Move: aleap (1,2)|(-1,2)
Promotion: all, all, "G"
Demotion: "G"
Optional promotion: empty, empty
Rule: keep capture, allow drops, promote drop
Rule: repeat4 = draw
Rule: perpetual = loss
The problem with holdings size seems to have exacerbated though, since SjaakII now reports a holding size of 1, which is clearly wrong. Not sure why it does that, but I'll investigate.
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Kyoto Shogi (Sjaak?)
Ok, I fixed the issue with reporting the required holding size. Twice, in fact, since it now recognises the situation demotion[demotion[piece]] == piece as a single holding slot, but I also removed the demotion on one of the piece types (the primary piece). This is mainly so you get consistent holdings after capturing a Gold or a Knight (the first would give you a Knight in holdings, the second a Gold, which is just confusing).
Entering the moves using the mouse still does not work (relevant animation options are enabled) but entering them by typing them does work:
Promotion suffices on drop moves are ignored.
Entering the moves using the mouse still does not work (relevant animation options are enabled) but entering them by typing them does work:
Code: Select all
948 <first : setup (P^G^S^P.....GS.......^T...TKp^g^s^p.....gs.......^t...tk) 5x5+4_shogi pgkst/5/5/5/TSKGP w 0 1
recognized 'shogi' (-1) as variant kyoto_shogi
shuffleOpenings = 0
1075 <first : piece K& K
1075 <first : piece P& fW@4
1075 <first : piece +P& R
1075 <first : piece T& WfF
1075 <first : piece +T& fR@4
1075 <first : piece S& FfW
1075 <first : piece +S& B
1075 <first : piece G& WfF
1075 <first : piece +G& ffN@3
1075 <first : pong 1
3855 >first : lift e1
3858 <first : highlight 5/5/5/4B/5
3859 <first : choice +P
7987 >first : put e2
SHOGI promoChar = -
SHOGI promoChar = -
nps: w=-1, b=-1
nps: w=-1, b=-1
7987 >first : time 1000
7987 >first : otim 1000
book hit = (NULL)
7987 >first : e1e2
7994 <first : choice +P
7994 <first : Error (Illegal move or unknown command): e1e2
38842 >first : lift e1
38843 <first : highlight 5/5/5/4B/5
38844 <first : choice +P
42263 >first : put e2
SHOGI promoChar = -
SHOGI promoChar = -
42263 >first : time 999
42263 >first : otim 1
book hit = (NULL)
42263 >first : e1e2
42327 <first : choice +P
42328 <first : Error (Illegal move or unknown command): e1e2
44218 >first : lift e1
44218 <first : highlight 5/5/5/4B/5
44219 <first : choice +P
45019 >first : put e2
SHOGI promoChar = -
SHOGI promoChar = -
45019 >first : time 992
45019 >first : otim 1
book hit = (NULL)
45019 >first : e1e2
45084 <first : choice +P
45084 <first : Error (Illegal move or unknown command): e1e2
47260 >first : lift e1
47261 <first : highlight 5/5/5/4B/5
47262 <first : choice +P
SHOGI promoChar = +
SHOGI promoChar = +
SHOGI promoChar = +
SHOGI promoChar = +
56252 >first : time 986
56252 >first : otim 1
book hit = (NULL)
56252 >first : e1e2+
56312 <first : # Begin iterative deepening loop for position "pgkst/5/5/4+P/TSKG1[-] b 0 1"
56312 <first : 2 7 0 658 1. ... Pa4+ 2. Sb2+ Sd4+ 3. +Sxd4+ Txd4+
56312 <first : 3 7 0 1738 1. ... Pa4+ 2. Sb2+ Sd4+ 3. +Sxd4+ Txd4+
56312 <first : 4 7 2 5863 1. ... Pa4+ 2. Sb2+ Sd4+ 3. +Sxd4+ Txd4+
56364 <first : 5 0 7 22989 1. ... Pa4+ 2. Tb2+ Td4+ 3. +Tb3+ +Td3+ 4. Sb2+ Sd4+
56520 <first : 6 -10 26 114842 1. ...
Impossible move a5a4+, type = 0
56520 <first : move a5a4+
SHOGI promoChar = +
SHOGI promoChar = +
SHOGI promoChar = +
SHOGI promoChar = +
SHOGI promoChar = +
70689 >first : time 959
70689 >first : otim 1
book hit = (NULL)
70689 >first : e2e5+
-
hgm
- Posts: 27790
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Kyoto Shogi (Sjaak?)
The problem is that the highlight protocol does provide a way to apply colors without affecting legality (by using lower case), but not the reverse. Except for the color T, but that just implies legality, not promotion. Perhaps I should define new letters for transparent promotion markers.
As for entering promotion drops, one way to do it could be to allow the user to toggle a piece in the holdings between base and promoted type by clicking it a second time after selection. (As XBoard does already for on-board pieces in Edit Position mode.) The question is when to allow this; I wouldn't want it to be possible to attempt dropping promoted pieces in regular Shogi, even if legality checking would reject it later.
There is a lot to be said for telling the GUI once and for all that this is possible, rather than having to coach it on demand basis by the engine. Perhaps this whole business of promotion on move, capture or drop should be delegated to the configuring at the begiing of the game? I never got to implementing the planned '@' atom in the Betza notation of the 'piece' commands, which could restrict where a piece can be dropped. But if it existed, it could also take care of this: when the piece command for +X would contain a drop specifier, it would imply promotion on drops is possble, as by definition +X pieces demote on capture, and thus cannot be in the holdings. The GUI can then always (and automatically) invoke the promotion procedure when a piece of type X is dropped
Similarly, (Shogi-style) promotion on move or capture could be made a standard feature in the GUI, switched on through the 'piece' commands. E.g. using c+ as modality could be made to mean 'forced promotion on capture'. Only problem is that it looks ugly, because the eye is trained to parse '+' as a binary infix operator. So I would prefer c' as notation for this over c+. (Well, arguably Betza definitions always look ugly...) Optional promotion on capture can be indicated with cc' or c'c. All Kyoto pieces (except King) would then need m'c' modifiers on their moves, and the micro-Shogi pieces mc'. Perhaps it is then more logical to indicate the (optional) promotion on drop as mm'@ on the base piece only.
As for entering promotion drops, one way to do it could be to allow the user to toggle a piece in the holdings between base and promoted type by clicking it a second time after selection. (As XBoard does already for on-board pieces in Edit Position mode.) The question is when to allow this; I wouldn't want it to be possible to attempt dropping promoted pieces in regular Shogi, even if legality checking would reject it later.
There is a lot to be said for telling the GUI once and for all that this is possible, rather than having to coach it on demand basis by the engine. Perhaps this whole business of promotion on move, capture or drop should be delegated to the configuring at the begiing of the game? I never got to implementing the planned '@' atom in the Betza notation of the 'piece' commands, which could restrict where a piece can be dropped. But if it existed, it could also take care of this: when the piece command for +X would contain a drop specifier, it would imply promotion on drops is possble, as by definition +X pieces demote on capture, and thus cannot be in the holdings. The GUI can then always (and automatically) invoke the promotion procedure when a piece of type X is dropped
Similarly, (Shogi-style) promotion on move or capture could be made a standard feature in the GUI, switched on through the 'piece' commands. E.g. using c+ as modality could be made to mean 'forced promotion on capture'. Only problem is that it looks ugly, because the eye is trained to parse '+' as a binary infix operator. So I would prefer c' as notation for this over c+. (Well, arguably Betza definitions always look ugly...) Optional promotion on capture can be indicated with cc' or c'c. All Kyoto pieces (except King) would then need m'c' modifiers on their moves, and the micro-Shogi pieces mc'. Perhaps it is then more logical to indicate the (optional) promotion on drop as mm'@ on the base piece only.
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Kyoto Shogi (Sjaak?)
In a way, it's not up to the engine to specify what colours to use. I would simply allow the user to tweak the highlight colours, and include transparent (alpha) in the mix.hgm wrote:The problem is that the highlight protocol does provide a way to apply colors without affecting legality (by using lower case), but not the reverse. Except for the color T, but that just implies legality, not promotion. Perhaps I should define new letters for transparent promotion markers.
indeed.There is a lot to be said for telling the GUI once and for all that this is possible, rather than having to coach it on demand basis by the engine.
Quite frankly I'm not a big fan of expanding Betza notation to include promotion. I think it would be cleaner if this was a separate option, and Betza would simply be used to indicate how pieces move.Perhaps this whole business of promotion on move, capture or drop should be delegated to the configuring at the begiing of the game? I never got to implementing the planned '@' atom in the Betza notation of the 'piece' commands, which could restrict where a piece can be dropped. But if it existed, it could also take care of this: when the piece command for +X would contain a drop specifier, it would imply promotion on drops is possble, as by definition +X pieces demote on capture, and thus cannot be in the holdings. The GUI can then always (and automatically) invoke the promotion procedure when a piece of type X is dropped
Similarly, (Shogi-style) promotion on move or capture could be made a standard feature in the GUI, switched on through the 'piece' commands. E.g. using c+ as modality could be made to mean 'forced promotion on capture'. Only problem is that it looks ugly, because the eye is trained to parse '+' as a binary infix operator. So I would prefer c' as notation for this over c+. (Well, arguably Betza definitions always look ugly...) Optional promotion on capture can be indicated with cc' or c'c. All Kyoto pieces (except King) would then need m'c' modifiers on their moves, and the micro-Shogi pieces mc'. Perhaps it is then more logical to indicate the (optional) promotion on drop as mm'@ on the base piece only.
Having said that, including it would allow for specification of the promotion move in Sittuyin: this is equivalent to the pawn promoting to Ferz on the spot, and then moving the Ferz or passing.
Anyway, I'll add Kyoto to the next release for SjaakII; I think the current behaviour (shogi-style promotions and piece names, demote on capture, + suffix on drop moves for promoted type) is how the engine communication side of things will work out?
-
hgm
- Posts: 27790
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Kyoto Shogi (Sjaak?)
Normally I would not be in favor of making promotion (as a result of reaching a zone) part of Betza notation. OTOH, as soon as promotion would depend on whether you make a move, and what move, or whether it is a capture, it could be considered as an intrinsic part of the move. E.g. you can have pieces that promote on capture, but not on non-capture (micro-Shogi), and you could have pieces that promote when moving as Ferz, but not when moving as Wazir. All this could be seen as having a different set of moves when promotig from when not promoting. And this would be the domain of Betza notation.
Of course we could introduce a different syntax to write this kind of divergence in the piece commands:
piece <ID> <NONPROMOTINGMOVE> + <PROMOTINGMOVE>
where absence of the + implies that the moves are the same. Then the Sittuyin Pawn could be
piece P& fmWfcF + OF
Of course we could introduce a different syntax to write this kind of divergence in the piece commands:
piece <ID> <NONPROMOTINGMOVE> + <PROMOTINGMOVE>
where absence of the + implies that the moves are the same. Then the Sittuyin Pawn could be
piece P& fmWfcF + OF