Polyglot keys for chess variants.

[hgm]

I cannot understand anything, how can I dictate something?

You let the technical problem (that some non-ThreeChecks supporting applications might choke on some FEN) dictate what you do.

[gcramer]

About the FEN, is this a realistic concern or just a hypothetical one? Which other application do you have in mind that you would like to feed ThreeChecks FEN's to even though they don't support ThreeChecks? If an application is liberal, it would not make a fuss if a FEN cuts off early. If it is pedantic, it would complain that there is stuff after the full-move counter anyway.

Scidb's syntax for Three-chess chess FEN's is the result of some years experience, thus it's impossible that it is 'ill-thought'.

Scidb provides a special Three-check Chess support, which is quite comfortable:

• 1. Tagging the check sign with a check count in the game editor.
  2. Detection of game over (no moves after third check possible).
  3. A very strong analysis engine (I've extended Stockfish).

The effort isn't very high, because technically this variant is relatively near to standard chess. It's not a problem to store and analyze Three-check games in any other chess database applications, e.g. Scid vs PC, although this application does not have a special support, such a support is not mandatory for this variant. With my first FEN format I couldn't exchange games between Scid vs PC and Scidb, because if Scidb writes the PGN

Code: Select all

[Event "Private chess session"]
[Site "At home"]
[White "It's me"]
[Black "It's my best friend"]
[FEN "r1bq1b1r/pppp1kpp/2n2n2/4p3/4P3/2N5/PPPP1PPP/R1BQK1NR/+1+0 w KQ - 0 5"]
[Date "2012.12.31"]
[Result "1-0"]
[Variant "Three-Check"]

{Checks given: +1+0} 5.Qh5+! Nxh5 6.Nf3 Ke8 7.Nd5 1-0

Scid vs PC fails to parse the whole game (other chess applications, too), the FEN is illegal. The thing changes if I use the extension at the end:

Code: Select all

[Event "Private chess session"]
[Site "At home"]
[White "It's me"]
[Black "It's my opponent"]
[FEN "r1bq1b1r/pppp1kpp/2n2n2/4p3/4P3/2N5/PPPP1PPP/R1BQK1NR w KQ - 0 5 +1+0"]
[Date "2012.12.31"]
[Result "1-0"]
[Variant "Three-Check"]

{Checks given: +1+0} 5.Qh5+! Nxh5 6.Nf3 Ke8 7.Nd5 1-0

Everything is working fine in Scid vs PC, although this application is skipping the extension.

Now about Scidb's PGN parser. Parsing PGN is difficult even with standard chess games, because many, many PGN archives are lousy. It's quite more difficult if the application is supporting other chess variants. Many chess games in PGN do not use the "Variant" tag, so I have to detect the chess variant on the fly. In case of Three-check Chess the FEN is the only criteria which I have to detect the variant - if the variant tag is not given - and this is important, because Scidb is strongly separating databases between chess variants, it's not possible in Scidb's format to build a database with mixed variants, due to good reasons. So I'm using the appended check counter "+x+y" for the detection.

• 1. From the parser's point of view "+x+y" is symmetric, "x+y" is asymmetric.
  
  2. As an appendix "+x+y" is much more clearer than "x+y", "x+y" looks more than random data following the FEN as "+x+y". For Scidb it's important that the detection works, this is quite more important than sparing one character.
  
  3. Even for a human, not knowing the extended FEN format, +x+y gives a better information about the meaning.

I'm developing Scidb since five years, and it's the first chess database application which supports chess variants. I will not give up this format, which is the result of many years experience, as long as the proposed alternative is not well probed. Bad that this format is not qualified for use in XBoard, but it is qualified for use in Scidb.

About the "Variant" tag in PGN. The current de facto standard for the variant tag is awkward. Chess960 positions will be stored as a chess variant:

Code: Select all

...
[Variant "Chess960"]
[FEN "..."]
[Setup "1"]
...

But this isn't a variant, it's standard chess with a Chess960 start position. In Scidb every variant can start with a Chess960 start position (even Shuffle Chess positions are supported). For Bughouse Chess960 start positions are important. Due to the strategy in Bughouse the opening phase is very restricted, Chess960 positions makes Bughouse quite more interesting. I've stumbled in the Internet over some articles about this. With a clear PGN standard a standard chess game with a Chess960 start position would be written in the following way:

Code: Select all

...
[Variant "Standard"]
[Position "381"]
[FEN "nrkbrnbq/pppppppp/8/8/8/8/PPPPPPPP/NRKBRNBQ w KQkq - 0 1"]
[Setup "1"]
...

But following the current de facto standard my writer is producing:

Code: Select all

...
[Variant "Chess960"]
[FEN "nrkbrnbq/pppppppp/8/8/8/8/PPPPPPPP/NRKBRNBQ w KQkq - 0 1"]
[Setup "1"]
...

And if I write a Crazyhouse game with a Chess960 start position, I'm using the clear way:

Code: Select all

...
[Variant "Crazyhouse"]
[Position "381"]
[FEN "nrkbrnbq/pppppppp/8/8/8/8/PPPPPPPP/NRKBRNBQ w KQkq - 0 1"]
[Setup "1"]
...

Possibly I should use the clear way even for standard chess with Chess960 start positions, but I don't how other chess applications will react if I do this.

[hgm]

Scidb's syntax for Three-chess chess FEN's is the result of some years experience, thus it's impossible that it is 'ill-thought'.

Funny argument. As if time automatically repairs all defects.

With my first FEN format I couldn't exchange games between Scid vs PC and Scidb, ...

Relying on such undocumented behavior is risky. Future versions of Scid vs. PC might decide to do more strict FEN parsing, and abort the game also when a double quote doesn't immediately follow the move number. It would be better to define an optimal FEN format and ask the developer of Scid vs. PC to adapt his FEN parser such that it doesn't choke on it. I assume Scidb is a Scid derivative, so you must know pretty well what has to be changed. But I think the original format is even worse; putting non-board-stuff as extra board ranks is just awful, and completely against the design of standard FEN. To me, 0+0 looks more symmetric than +0+0, but this isn't really worth arguing about. Counting checks given rather than checks left is a fatal flaw, IMO, though. So I would never use the Scidb format in XBoard. Which also means I'd better use something that looks completely different as the Scidb format.

Now about Scidb's PGN parser. Parsing PGN is difficult even with standard chess games, because many, many PGN archives are lousy. It's quite more difficult if the application is supporting other chess variants. Many chess games in PGN do not use the "Variant" tag, so I have to detect the chess variant on the fly. In case of Three-check Chess the FEN is the only criteria which I have to detect the variant - if the variant tag is not given - and this is important, because Scidb is strongly separating databases between chess variants, it's not possible in Scidb's format to build a database with mixed variants, due to good reasons. So I'm using the appended check counter "+x+y" for the detection.

This seems a pretty hopeless endeavor to me. In general, a variant cannot be recognized from the FEN. The checks-field you introduced could be used as a kludge to recognize ThreeChecks, but how would you recognize Suicide, Losers Shatranj or Atomic? It is also not clear to me how this solves anything. Surely absence of a FEN tag is even more common than absence of the Variant tag. And there seems no point in it either. Scidb, being designed to handle variants, must surely always include Variant tags in the PGN it generates. So you will only run into this problem when dealing with PGN archives generated by other applications. Which certainly won't have a checks field in their FEN tag.

An additional problem is that applications written for orthodox Chess-only could be 'pedantic', and reject any form of modified FEN, even if it is just suffixed. The proper way to do it if you care about such backward compatibility is to not touch the FEN tag at all, but put the additional information that is needed in separate tags. I think the FEN standard explicitly allows the use of arbitrary tags; tags that are not known must simply be ignored. You could put a 'CheckQuota' tag in ThreeChecks games, like [CheckQuota "3:3"] (to use the same design as the TimeControl tag). This is a nice orthogonal design, as the tag could be included with every existing Chess variant to alter its winning condition to any desired number of checks. In fact, it seems to me that it would make ThreeChecks really the same variant as orthodox Chess, the only difference being that the CheckQuota in the initial position is somewhat lower. Applications that respect the PGN standard should always accept that, and in the worst case completely ignore it. Similarly you could have a Holdings tag for the crazyhouse holdings, etc. (I admit I don't do that in XBoard, but processing Crazyhouse games with orthodox-Chess applications seems doomed to failure anyway, because of the drops.)

I'm developing Scidb since five years, and it's the first chess database application which supports chess variants.

That could be, but does it have any users, other than you? I am all for providing better infrastructure for Chess variants, but the capabilities of Scidb seem limited to just a few variants of little importance. (I.e. no Xiangqi, no Shogi, no Makruk...) So it is hardly the solution to all variant databases, meaning that XBoard should offer complete database support anyway.

About the "Variant" tag in PGN. The current de facto standard for the variant tag is awkward. Chess960 positions will be stored as a chess variant:

Code: Select all

...
[Variant "Chess960"]
[FEN "..."]
[Setup "1"]
...

But this isn't a variant, it's standard chess with a Chess960 start position. In Scidb every variant can start with a Chess960 start position (even Shuffle Chess positions are supported).

Well, I agree that Chess960 isn't truly a variant. Not sure what you perceive as awkward here (except that the Setup tag is of course redundant, and should never have been invented). That Chess960 and Standard are sort of synonyms? Also not sure what you mean by 'start with a Chess960 start position', or why you mention Chess960 and Scidb here. I would think that Chess960 start positions are just a sub-set of all conceivable Chess positions, and that any application handling PGN format would allow the games (of any variant, if it is variant aware) to start from a completely arbitrary position (e.g. for the purpose of material-odds games, which are not Chess960 start positions, or for thematic tournaments, or some of the ICC and FICS 'wild' boards).

With a clear PGN standard a standard chess game with a Chess960 start position would be written in the following way:
...
Possibly I should use the clear way even for standard chess with Chess960 start positions, but I don't how other chess applications will react if I do this.

The 'clear way' is fully compliant with the standard, isn't it? I am not sure what you mean by 'standard Chess with a Chess960 start position'. How is this different from Chess960? I assume that you are talking about positions with K and R in the usual place, or they could not have castling rights in orthodox Chess (and if they hadn't, these would not be Chess960 start positions).

I think asking that applications would be smart enough to deduce from the presence of castling rights incompatible with piece placement implies Chess960 is asking for too much. But otherwise I don't see how there could be any problems. If you want to support games like 'Crazyhouse960' without introducing new variant names, it would be useful to have a CastlingType PGN tag (with possible values "standard", "fischer", "free", or perhaps even some descriptive format like "eghf,ecad") that could be tagged orthogonally on any game.

[gcramer]

Sorry, this is verbiage, no answer. Time to stop.