Need help in Chess 960 support!

[Edsel Apostol]

I am having to choose between implementing SMP and Chess960 and it seems that the latter choice is much easier so I will try to add that first to my engine.

Anyone of you here has idea what are the things that needs to be changed in my engine in order to support it? What are supposed to be the difference between normal chess and chess 960?

I'm thinking that I need to revise my data structure for castling status and update the code that interacts with this, I'm also thinking of modifying my move parser to take special Chess 960 castling status, and I will add some special Chess 960 evaluation code. Is there anything else?

By the way, my engine has UCI support.

[hgm]

I am just in the process of doing the same thing for Joker80.

The only difference between Chess960 and normal Chess is the castilng rule. And of course your engine will have to be able to accept an initial position from the GUI through the 'setboard' or 'edit' command.

There are 2 issues in the WB interface: make sure you understand the notation for castling rights in the FEN (naming the file of the Rooks that can castkle, like HAha, rather than KQkq). The second is that in the input move you have to understand O-O and O-O-O as castlings. And you would have to write your own castlings that way too.

In the move generator, the easiest thing seems to be to make the castling code entirely table-driven. The way I do it, is I have 4 move codes reserved for castling (two for white, two for black), in my case recognized by 4 different off-board toSquares. In MakeMove these are intercepted before making the normal move, and then used as index in a table that contains:

1) true King toSquare
2) Rook fromSquare
3) Rook toSquare
4) leftMost square that has to be 'Empty'
5) rightMost square that has to be 'Empty'
6) leftmost square that should not be in check
7) rightmost square that should not be in check

Note that 'Empty' here means that it could possibly contain the King or Rook that castle, so in doing the empty test you should skip the squares those are on.

When setting up the position, you can initialize the table for all castlings that are possible in the given initial setup. (All squares the King or Rook pass oversshould be empty, except for pssibly themselves, and the King should not pass over any square that is in check.)

I don't have to do anything special to account for castling rights: if I move or capture a piece, the castling right flags are OR'ed with a 'castling spoiler' for that piece. Just like in normal Chess the two original Rooks and the King will have non-zero castling spoilers. If you would do the same not by piece, but by square, you would of course have to put the spoilers on different squares, depending on the setup.

If your engine uses WB protocol version 2, be sure to have "fischerandom" as one of the variants in the feature command, e.g.

feature variants="normal,fischerandom,xiangqi"

(note the quotes; they are essential).

[Roman Hartmann]

My Engine plays (or tries to) Chess960 since version 0.037.

The main problem related to Chess960 I have is not the data-structure but the communication with the GUI.

I assumed that Shredder would set the Chess960 "standard" and implemented it the same way and now my engine works just nicely in the Shredder GUI but probably only there as other GUIs seem to define their own standard.

Shredder and Chess960/FRC:
Fen: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w HAha - 0 1
(note the HAha, instead of QKqk)

castle move defined by: king captures own rook

All of that is easy to implement and makes sense imo but some other GUIs work different.

best regards
Roman

PS: there is some information regarding chess960 in the winboard-forum as well.

[hgm]

The king-captures-own-rook format is a violation of WinBoard protocol as defined on Tim Mann's pages, and thus would not work under WinBoard. So I guess Shredder does not qualify as WB compatible, then.

WinBoard does understand the HAha notation in FENs, and uses it in the FEN send to the engine as well, in variant fischerandom.

[Roman Hartmann]

The king-captures-own-rook format is a violation of WinBoard protocol as defined on Tim Mann's pages, and thus would not work under WinBoard. So I guess Shredder does not qualify as WB compatible, then.

WinBoard does understand the HAha notation in FENs, and uses it in the FEN send to the engine as well, in variant fischerandom.

I was mainly adressing the UCI-protocol as Twisted Logic is using the UCI-proctol as well. You're probably right regarding the winboard-protocol and 'king captures own rook'-thing but then it would be not big deal to just adjust input/output to adapt the engine to this issue.

The problem is that some of the GUIs that support Chess960 in UCI-mode are handling this not the same way.

Roman

[hgm]

Oh well, who cares about UCI mode. I am pretty sure Polyglot implements FRC, so it is easy enough for UCI engines to play under WinBoard protocol. So it doesn't hurt too much to be an UCI engine.

[Roman Hartmann]

Oh well, who cares about UCI mode. I am pretty sure Polyglot implements FRC, so it is easy enough for UCI engines to play under WinBoard protocol. So it doesn't hurt too much to be an UCI engine.

An author of an engine that supports only the UCI-protocol might care about that
But polyglot does support FRC, so an UCI-only-engine should be able to play FRC-chess in any case.

best regards
Roman

PS: I just tried to play an FRC-game with the combination winboard_x+polyglot but for some reasons winboard or polyglot sends always the standard-starting position even though it shows an FRC-position and sends also the castling rights in the FEN with HAha to the engine. Odd ...

[hgm]

FRC is defective in WinBoard_x. You should try WinBoard 4.3.13 or later.

An alpha version of WinBoard 4.3.14 can be downloded here. (You would have to rename it to winboard.exe.)

[Roman Hartmann]

FRC is defective in WinBoard_x. You should try WinBoard 4.3.13 or later.

An alpha version of WinBoard 4.3.14 can be downloded here. (You would have to rename it to winboard.exe.)

Ok, this works much better now as this version sends now not only the castling rights but also the right position.

Stupid question but how do I set up a different FRC-startingposition?

Edit: ok, I guess I figured it out. Entering -1 in the 'new shuffle game' menu will set up a random FRC-position.

Additional question, is this version stable enough to play FRC on ICC?

In any case thanks for your work on winboard!

Roman

[hgm]

I think it is; it is derived from a version that Olivier used to operate Glaurung in the FRC qualifier ofor Mainz on ICC, last month. But I am changing it all the time, in particular the ICS part. There were still some issues with observing ICS games , in particular being able to scroll back to the beginning of the games, when you entered it in the middle, and with observing games of variants that the engine did not know. But I think this version sollves them all.

If you go online with Roce, I will put DanaSah frc online under the handle JokerX, and we could try it out in a few unrated games.