Sjaak II question

[hgm]

I'm not sure I follow. What should the GUI expect from the engine? I would think "f1e1,a1f1". If there's no standard for this yet, I think there should be a simple syntax like that for moving multiple pieces (for Marsellais Chess for example.)

Indeed, that is the syntax for multi-moves we defined for the WinBoard Alien Edition, some years ago. There is one complication, though: for engine to GUI such moves have to be sent in separate 'move' commands, a comma in the place of the promotion suffix indicating that more is to follow. Like

move f1e1,
move a1f1

True promotion suffixes only need to appear on the last leg. For GUI->engine alllegs are sent as a single command:

usermove f1e1,a1f1

The current regular edition of WinBoard only understand this for two very specific cases, however: non-promoting locust capture (for Chu-Shogi Lion) where the to-square of the first leg is equal to the from square of the second leg, and castlings where the Rook ends up next to the King. For any other case the results are undefined. In the upcoming WinBoard 4.9 the locust capability is extended to 3 legs (to handle the Maka-Dai-Dai Lion Dog), and locust captures can be promotions.

The SAN for locust captures differs from the protocol notation, however: e4f5,f5g5 would be L'xf5-g5 (if g5 was empty) or L'xf5xg5 if it was a double-capture (and L' the ID for Lion; in Chu Shogi the ID is actually N). For non-standard castling there isn't a special SAN form yet, so it would be treated as if it iwere a locust capture. (That also applies to non-royal castling,like Omega Chess 'guarding'.)

[Greg Strong]

Ok, got it. Thanks!

[Evert]

You could call that rule 'simple check', to stay in line with 'duple check'.

I think I named the option something like "check any king". I'm not married to the name though, I just ouldn't think of something witty or catchy, so I figured I'd just go for something descriptive.

The King + Rook move should work in the latest XBoard. I suppose it would write it in SAN as Kf1xa1-e1, though, as the internal representation would be f1e1, with 'kill square' a1. This is also how the move would have to be entered with the mouse.

Eeeeeeew. Fortunately I don't really need to communicate in SAN so it shouldn't matter much. Although it probably does mess up XBoard's ability to walk the PV line...

For the next release, I would like to make the final tweak needed to support Wildebeest Chess. That should be fairly easy. SjaakII also hangs when I run a search under Wine that I would like to fix (it happens with the Windows builds that work under Windows too, so it's not an issue with the MinGW builds). I also rewrote the code that does the colour output so it doesn't spit out ANSI escape codes on Windows, but I would also like some confirmation that it actually works as intended. Hopefully I can get the next release out before easter.

[Evert]

Ok, looking at the latest discussion in that thread, making pieces "iron" is not sufficient (although still of some use, so I'll keep the option) and a full-blown list of who is allowed to kill whom is needed.

This is considerably more complicated, especially since this could apply to royals as well: some pieces could be designated as not being able to capture a king and thus not being able to check, and that could be meaningful. As opposed to designating a royal piece as "iron" (which would be silently ignored).

It does add a potentially interesting "rock beats scissors beats paper beats rock" mechanic and there is some precedent for a rule like it: the cannon in Janggi (Korean Chess) is not allowed to capture another Cannon (and it also cannot function as a Cannon mount). I don't have the ambition to make Sjaak II play every regional or historic variant out there, but I would like to support more XiangQi-like games (there are very few of these though). Unfortunately even with adding this feature I wouldn't be able to handle Janggi because of the Elephant moves: it moves as a lame Zebra that can be blocked on W and N squares and I can do at most one of those.

Anyway, implementing a list of what is allowed to capture what needs a bit of consideration. Before move generation I simply remove squares that hold iron pieces as valid move targets, but for this I would need to test each capture to see if the capture is allowed, but that can slow down the common case quite badly. I'll see what I can come up with; there are situations where I test for something like this anyway (contagious pieces and endangered pieces).

[Evert]

The King + Rook move should work in the latest XBoard. I suppose it would write it in SAN as Kf1xa1-e1, though, as the internal representation would be f1e1, with 'kill square' a1. This is also how the move would have to be entered with the mouse.

How does that work, then?
If I drag the king to the rook, it castles immediately without allowing me to specify the destination square. I guess I need to do some tweaking to the highlight command (highlight the rook in cyan)?

[Evert]

I guess I need to do some tweaking to the highlight command (highlight the rook in cyan)?

Ok, doing that works.

[hgm]

Right. moving to cyan squares makes XBoard expect another leg. All other colors terminate the move, while moves to non-marked squares are rejected as illegal.

If there is a move that could end on the square (without further leg) as well, (which usually is the case for Lion captures), you should still mark it in cyan. XBoard will then consider another click on that same square then as a 'null-leg', which it will clip off the move.

[Evert]

Ok, I have something implemented that appears to work as suggested: you can specify an "allowed victim" list per piece type, and it's only allowed to capture those pieces. This list currently isn't used by the check test, so all pieces are allowed to check the king (if they have a capture move defined at all). I'll see about a compile for testing; I'll probably make that myself, which means I need to cross-compile it on Linux and so it will be enormous because I need to include the C++ runtime. However, if there are no real issues I'll probably try to release a proper update next week.

The rule definition I used is this (I gave the game the arbitrary name "royalty"):

Code: Select all

Variant: royalty
Board: 8x8
FEN: "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq -"
XBoard pieces: "PNBRQKpnbrqk"
Zone: rank8 = a8,b8,c8,d8,e8,f8,g8,h8
Zone: rank7 = a7,b7,c7,d7,e7,f7,g7,h7
Zone: rank2 = a2,b2,c2,d2,e2,f2,g2,h2
Zone: rank1 = a1,b1,c1,d1,e1,f1,g1,h1

Piece: Knight
Move: leap (2,1)
Symbol: "N", "N,n"
Allowed victims: "K,Q"
Value: 320

Piece: Bishop
Move: slide (D,A)
Symbol: "B", "B,b"
Allowed victims: "K,Q"
Value: 325

Piece: Rook
Move: slide (H,V)
Symbol: "R", "R,r"
Allowed victims: "K,Q"
Value: 500

Piece: Queen
Move: slide (D,A,H,V)
Symbol: "Q", "Q,q"
Flags: royal
Value: 950

Piece: King
Move: leap (0,1)|(1,1)
Symbol: "K", "K,k"
Flags: royal
Castle: white e1-g1 with h1
Castle: white e1-c1 with a1
Castle: black e8-g8 with h8
Castle: black e8-c8 with a8

Piece: Pawn
Move: step N
Capture: step NE,NW
Initial: step 2N
Symbol: " ", "P,p"
Flags: set_ep,take_ep
Promotion: rank8, rank1, "QRBN"
Value: 100
Allowed victims: "K,Q"

Rule: checkmate = win
Rule: stalemate = draw
Rule: repeat3 = draw
Rule: check any king

That said, looking at a few sample games suggests that the game is a dead draw: even giving time odds of 2:1 and a minor down, the disadvantaged side just closes the position and hides the royal pieces on the back rank. With no way to break open the position (no captures), you just shuffle until the 50 move rule kicks in.