Shogi

[PK]

never thought about tokin-gold difference in terms of elephantiasis, but it actually makes a lot of sense. suppose that enemy general marches towards your castle supported by a rook: you exchange it, rook moves closer, you drop and unless there is some easy tactical shot (piece drop from the other side, promoted rook pinning a defender and simultaneously allowing a drop with check) the rook retreats, you survive and even get a tempo. but in case of a supported tokin march you just die.

[hgm]

This means that the trade is bad for me, even if +P > G, as long as (G - P) >> (G - +P), which is of course the case.

Indeed. Especially since the right-hand side is actually NEGATIVE under these conditions.

The evaluation will get that right though, if I don't set the piece values too crazy. My SEE routine is another matter.

Should be no problem if you adapt the piece values you use in SEE. Basically whatever you capture should be counted for double its nominal value, because the opponent loses it, and you get it. To be more precise, what you capture should be counted as boardValue + handValue of the captured piece. For unpromoted pieces the hand value would be larger, but for promoted pieces the hand value will in general be lower, as it is the hadValue of the demoted piece.

[hgm]

There was a compatibility problem with SAN, however, where a '+' suffix outside Shogi means check. So in SAN Shogi promotions outside Shogi are written with an =+ suffix.

Hmm… not sure how that would work in Sjaak. I think it always ignores = as optional for promotions, but it may now get confused when it gets a + and assume that it indicates promotion.

This is correct: Ra8=+ in XBoard's SAN for a non-Shogi game would mean "Rook promotes to +R". Ra8+ would mean "Rook checks", Ra8=++ would mean "Rook promotes to +R and the latter checks". Ra8= would not be valid (to prevent disambiguity). In Shogi the latter would mean "Rook defers", but it seems no one actually uses that. Checks are never indicated in Shogi.

I made an attempt to make XBoard's Shogi SAN look like PSN, which I now regret. It is really a design flaw of PSN that you cannot indicate checks. I should have used another sign in stead of the '+' to indicate promotion, e.g. ^.

The advantage of the current notation is that XBoard can read PSN just as easily as PGN.

Well, theoretically at least both engines should (for non-standard variants) send a pieceToCharTable as well as a startup FEN string. That should allow XBoard to do the translation.

This is indeed a better idea than having an external option for it. It should match the initial positions both engines send to map the pieces IDs of one to the other. (And then hope it is not a shuffle variant...) It would be problematic if there are pieces that are not in the initial setup, as I did in Team-Mate Chess.

Of course a major other point is that they might actually not even agree on the name of the variant.

[Evert]

This is correct: Ra8=+ in XBoard's SAN for a non-Shogi game would mean "Rook promotes to +R". Ra8+ would mean "Rook checks", Ra8=++ would mean "Rook promotes to +R and the latter checks". Ra8= would not be valid (to prevent disambiguity). In Shogi the latter would mean "Rook defers", but it seems no one actually uses that. Checks are never indicated in Shogi.

Well, Sjaak's parser works like this:

Code: Select all

generate all legal moves

Is the move a drop?
    Look for the indicated drop in the move list.
    If found -> return
    If not found -> illegal move

Does the move string match "square1square2"?
   Throw away all moves that do not go from square1 to square2.
   Is there exactly one move left in the list? -> return
   Is the move a promotion?
      Throw away all non-promotions
      Is there exactly one move left in the list? -> return
      Throw away all moves for which the piece does not match the indicated promotion piece.
      Is there exactly one move left in the list? -> return
   -> illegal or ambiguous move

Is the first character a capital letter or a +?
   Does the string start with O-O?
      -> Castling
    Find the piece corresponding to the first piece
    Throw away all moves by other pieces
    Find the destination square in the move string.
    Throw away all moves that do not go to the destination square
    Is there exactly one move left in the list? -> return
    Is there a file disambiguation character?
        Throw away all moves that do not start on the indicated file
        Is there exactly one move left in the list? -> return
    Is there a rank disambiguation character?
        Throw away all moves that do not start on the indicated rank
        Is there exactly one move left in the list? -> return
    Is the move a promotion?
       Throw away all non-promotions
       Is there exactly one move left in the list? -> return
       Throw away all moves for which the piece does not match the indicated promotion piece.
       Is there exactly one move left in the list? -> return
    -> illegal or ambiguous move

Is the first character a lower-case letter?
   Set piece-type to pawn, and follow the same steps as for a piece

-> illegal or ambiguous move

Pretty complicated, but it handles long-algebraic and SAN (and simplified things like 1. e4 d5 2. d5 as a side-effect). I think it is robust against possible duplicate meanings of "+" in that it only looks at the "+" if it has to.

Sjaak now actually "speaks" XBoard, UCI and USI (although I haven't tested if USI actually works in a GUI), so it has to handle the different notation used by USI as well. It does that by matching against strings for each square, which are re-calculated for USI. Because I could, I added a (totally useless because of lacking GUI support) UCI/USI option that lets you select a variant to play.

Well, theoretically at least both engines should (for non-standard variants) send a pieceToCharTable as well as a startup FEN string. That should allow XBoard to do the translation.

This is indeed a better idea than having an external option for it. It should match the initial positions both engines send to map the pieces IDs of one to the other. (And then hope it is not a shuffle variant...) It would be problematic if there are pieces that are not in the initial setup, as I did in Team-Mate Chess.

Well, if they're not standard pieces, then the engines should send a pieceToChar as well, so even pieces that don't show up in the FEN could be matched up.
I suppose all the GUI can do is offer a way to make it work, but it's still up to the engine developer to write their engines in such a way that they can actually take advantage of that.

Of course a major other point is that they might actually not even agree on the name of the variant.

I suppose there's InBetween (which I've never used), but it would be nice if the GUI could be used to match up variants between engines. It's not something that could be done automatically though...

[Evert]

I was running some test games of Sho Shogi to make sure that things are working correctly, and I ran into a problem in the following position:

5k3/9/l5+E2/p2K3p1/8s/Pg4GP1/3+e5/L8/9 b 10 68

both sides have promoted their elephants, so they both effectively have two kings. For reasons I don't understand, Sjaak wants to play Kf8, which would expose it to +Exf8. XBoard refuses to allow the move and forfeits the game (unless I switch legality testing off).

My understanding of Sho Shogi rules is that as long as you have two kings you can basically ignore check. Is this wrong? Or do I have to switch legality testing off in XBoard to play Sho Shogi?

[hgm]

I guess for the time being Sho Shogi should indeed be played with legality testing off. HaChu plays it as 9x9+0_shogi, defining extra pieces E and +E through the setup command. But XBoard has no idea that these are royal pieces, and even if it had, it would not know that this is extinction royalty rather than absolute royalty.

Logically this problem should disappear if it was played as 9x9+0_chu, as in variant Chu these rules for handling royalty are standard. I am afraid that upto now it never occurred to me to actually implement this, as HaChu was designed to play Chu with legality testing off (it implements the highlight command). So XBoard can do correct pseudo-legal move generation for Chu, but it does not know the more subtle details of the Chu rules (such as that you have to leave the zone after deferral before you can promote again, and initially it also did not implement the restrictions on Lion exchange, although I added that later). The multiple royalty was just one of these 'subtle details'.

When I first wrote HaChu it could play in WB Alien Edition only, and that it uses a completely different set of pieces (all without bitmaps), none of them recognized as royal. This in accordance with the official Chu rules that state the game is won by King capture, rather than mate. (HaChu does apply checking rules, though, to be more user-friendly.) So there the problem did not come up. When I later ported Chu to the standard edition of XBoard,it never occurred to me that the mate test would have to be altered to be able to play it with legality testing on. So currently 9x9+0_chu would not work either.

[Evert]

I suppose there's no reason for XBoard to know that +E is a royal piece, since Shogi doesn't normally have E nor +E. So it does make sense.

What threw me off was that the "variant rules" (for instance http://www.gnu.org/software/xboard/what ... s/Sho.html) do say that legality testing can be on, and +E actually does appear as a king (perhaps by lucky coincidence?).

[hgm]

Indeed, this is wrong. I did not foresee this multiple-royalty problem when I wrote that. I was just thinking of the piece moves.

And no, it wasn't a coincidence it promotes to King. In Shogi the representation of the promoted pieces has always been different than in other variants, because of the multiple Golds that are needed (which otherwise would be Cannons, Nightriders, Grasshoppers...). I just added the King image as a Shogi replacement for the Falcon. The moves for all the pieces is also different in Shogi than in the other variants, and I did add the moves for E and +E in the Shogi move generator to prepare it for Sho.

I guess the logical thing to do is also program multiple-royalty handling in variant Shogi (and Chu). I guess the required code is already there,for the benefit of Spartan Chess. Except that in this case it would have to recognize the +E piece type as royal, ratherthan just looking for two Kings.

[hgm]

Seems I underestimated my own zealousness. XBoard's mate test already contains the following code:

Code: Select all

    if(gameInfo.variant == VariantXiangqi)
        king = flags & F_WHITE_ON_MOVE ? WhiteWazir : BlackWazir;
    if(gameInfo.variant == VariantKnightmate)
        king = flags & F_WHITE_ON_MOVE ? WhiteUnicorn : BlackUnicorn;
    if(gameInfo.variant == VariantChu) { // strictly speaking this is not needed, as Chu officially has no check
        int r, f, k = king, royals=0, prince = flags & F_WHITE_ON_MOVE ? WhiteMonarch : BlackMonarch;
        for&#40;r=0; r<BOARD_HEIGHT; r++) for&#40;f=BOARD_LEFT; f<BOARD_RGHT; f++) &#123;
            if&#40;board&#91;r&#93;&#91;f&#93; == k || board&#91;r&#93;&#91;f&#93; == prince&#41; &#123;
                if&#40;++royals > 1&#41; return FALSE; // no check if we have two royals &#40;ignores double capture by Lion!)
                king = board&#91;r&#93;&#91;f&#93;; // remember which one we had
            &#125;
        &#125;
    &#125;

But playing it as 9x9+0_chu would not work, because the pieces promote different (and the Knight would look like a Leopard, and the Queen would not look like a Lance...).

But I guess I only have to adapt this code to be also executed in VariantShogi, with White/BlackMonarch (Elephant+22) replaced by Falcon (Elephant+11).

[Edit] Pushed the fix.

[Evert]

I've added some special king-safety code for drop variants (having Shogi in mind, but the code is general).

First of all it calculates a shelter score based on the squares surrounding the king that are protected/occupied by friendly pieces. This already helps a lot, but the real improvement seems to come from counting pieces that are "in hand" as attacking the king's position (after all, they can just drop in there). The new version solidly defeats the old version, and play looks much more coordinated.

So far no idea how it measures up against other engines though...