Stockfish: Variant selection

[HGMuller]

As a GUI developer, I have a complaint about the way the various variants have to be selected through UCI_xxx check options. This is a truly awful method, because there is no way for the interface to know if such an option represents a variant, or is just some other novel UCI standard option it does not know about.

Using a general UCI_Variant combo option with the variant names as possible values, as used by some other multi-variant UCI engines, would be a much cleaner solution.

I realize that SMK started this madness himself by introducing the UCI_Chess960 standard option as a checkbox. But Chess960 is not really a variant, and this option is not so much a variant selector, as a protocol modifier (forcing different notation of castling moves and the castling field in FENs), which in principle is orthogonal to the actual variant. (E.g. one could also play Atomic as a shuffle game with Fischer castling, requiring the same protocol modifications.)

[Edit] Note that it would not cause any problems to support a UCI_Variant combo option next to all the checkbox options you have now. You could only pay attention to the combobox setting if none of the checkboxes is ticked (and use normal Chess as default value for the combo option). Interfaces can then simply ignore the checkboxes, and pick the desired combo setting.

[ddugovic]

@HGMuller Thanks very much for your input and I'm flattered to have gained your interest! In hindsight I entirely agree with your advice, and I agree that Chess960 is not really a variant. (By now it is painfully obvious that not only are "hybrid" variants infeasible, I'm the only person even remotely interested in them.)

Pinging fishnet author @niklasf : do I have the freedom to change this?

[niklasf]

Sure. In a transition phase I'll set both kinds of options and will just ignore when I get No such option: ...

[ddugovic]

Great! The option name will be UCI_Variant and acceptable values will be lower-case strings atomic etc. (I think the full variant names are desirable)

UCI documentation provides an example of how to use a combo option:

"option name Style type combo default Normal var Solid var Normal var Risky\n"

[ddugovic]

Ah, now I recall why I coded how I did... when your only instrument is a hammer, everything starts to look like a nail.

I don't see how to define a combo option in ucioption.cpp. It appears I'll need to create a new data type and ensure it doesn't cause problems with existing types.

[HGMuller]

Thanks for adding the UCI_Variant option! Sorry that I have to be back
for some nitpicking:

I have implemented the UCI_Variant option in UCI2WB now, but there still
is the issue to translate the combobox values, in so far they correspond
to standard variants of WB protocol. When you say 'antichess', would
that correspond to 'suicide', 'giveaway' or 'losers', in FICS/ICC terms?
(I.e. can the King be captured, and how is the game result decided in
case of stalemate?)

You seem to use "standard" for orthodox Chess, while Sjaak II uses
"chess" (while WB protocol has always defined this a "normal"). Now it
will probably be a hopeless endeavor to have all engines agree on the
names of all variants they have in common, but for this one, which they
likely will all have, it would surely be nice if we could achieve that.
It is not my intention to force WinBoard conventions on the UCI
community, but if UCI2WB must do name conversion, it would sure be nice
if it could be 1-to-1 in both directions. I have no strong preference
for either "chess" or "standard"; "fide" would also be pretty clear.

I am happy that at least "atomic" and "crazyhouse" are the same as in WB
protocol. "horde", "racingkings" and "kingofthehill" are not standard
variants in WB protocol, but Sjaak II plays the latter, and fortunately
uses exactly the same name for it. (Fairy-Max also does KOTH, but
unfortunately used hyphens in it. But I can change that in the next
release.)

WinBoard implements the concept of "engine-defined variants". So in
principle any name would be fine for variants it does not know anyway.
But for those to work, the engine should supply the initial position
when the variant gets selected. (And board size and piece set, but for
the variants you implemented so far these are always as in Chess.) Would
it be possible for you to introduce something similar in UCI, e.g.
responding to "setoption name UCI_Variant value xxx" with something like
"info startpos " or "info string startpos "? Then the GUI
could automatically set up the position from this, instead of being
dependent on the user to configure it for variants the GUI does not
know. UCI2WB could simply relay the FEN together with a request for an
8x8 board and normal piece set, in a WB "setup" command.

Regards, H.G.

Op 9/24/2016 om 4:24 PM schreef Daniel Dugovic:

Closed #61 https://github.com/ddugovic/Stockfish/issues/61.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ddugovic/Stockfish/issues/61#event-801265524, or
mute the thread
https://github.com/notifications/unsubscribe-auth/AVNwNi_34-1vvi6fEAABwBsOSP3D9X5uks5qtTK7gaJpZM4KEyLR.

[ddugovic]

Thanks for the informative feedback - I hadn't considered these factors. Given that standard is also used to mean a time control (and can otherwise be ambiguous) I'm open to changing it, and the WinBoard/Sjaak normal makes sense (esp. since UCI does not yet have a competing standard).

By antichess I refer to the antichess ruleset which seems to be the same ruleset as giveaway chess. I will replace antichess with giveaway and hope I am reading things correctly.

Would it be possible for you to introduce something similar in UCI, e.g. responding to "setoption name UCI_Variant value xxx" with something like "info startpos " or "info string startpos "?

I'll have to take a look into compatibility issues for other GUIs (for variants with the default start position) although this seems like a reasonable thing to do, it also sounds complicated to do correctly.

[ddugovic]

You're correct, chess and fide are more specific than normal. Sorry for changing my mind; I'm not committing to following FIDE rules (as they change) so I prefer chess as a descriptor. (In any event, Stockfish accepts any variant string and assumes any non-matching value is plain chess.)

(The other thing that started me thinking about this is that xiangqi and shogi are also considered "normal"; chess best describes western chess.)

[ianfab]

I think antichess, suicide, giveaway and losers are four different variants. There are 3 situations where the rulesets differ: check/checkmate, castling, and stalemate. E.g. in giveaway castling is allowed, whereas in antichess it is not. And in suicide the game result can be different from antichess in the case of stalemate. However, I think that we can easily implement antichess, suicide and giveaway, since there are only very slight differences.

[ddugovic]

@ianfab It seems that other than the start position (castling rights) antichess and giveaway chess are the same. I think Stockfish allows castling in this variant but lichess specifies a FEN which disables castling? Let's see...

setoption name UCI_Variant value giveaway
position startpos
d

 +---+---+---+---+---+---+---+---+
 | r | n | b | q | k | b | n | r |
 +---+---+---+---+---+---+---+---+
 | p | p | p | p | p | p | p | p |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 | P | P | P | P | P | P | P | P |
 +---+---+---+---+---+---+---+---+
 | R | N | B | Q | K | B | N | R |
 +---+---+---+---+---+---+---+---+

Fen: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w - - 0 1

[ianfab]

We skip the castling move generation in antichess. I suggest to "inherit" the variants of antichess from the current antichess implementation. See this commit to get an idea of what I mean, especially have a look at the definition of is_anti. From there we would just have to add code with if(is_giveaway()) etc. to account for differences between the antichess variants. What do you think about it?

[ddugovic]

@ianfab In my opinion Stockfish should implement castling, and lichess/fishnet should use UCI command position rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w - - 0 1 to disable castling rights rather than inventing a new variant type.

[ddugovic]

@ianfab Regarding the suicide chess ruleset I'm not opposed to it being implemented, although does anyone play that variant anymore? I don't know why anyone would bother implementing losers chess although if people still play it, I guess implementing it could be useful.

[ianfab]

I would prefer to have different variants, because I think it is easier to understand for users (in usage via the command line or a GUI) if different variants can be chosen by their name via the UCI_Variant option and not via the modification of an FEN.

[ddugovic]

@ianfab Other than lichess, there isn't a GUI which implements "antichess". Also, increasing the number of variants (currently) increases the number of "if" statements and decreases performance...

Long-term position.h needs to separate int var from bool chess960 (found in official-stockfish/Stockfish), and change int var to Variant var where Variant is an enum, and then use template functions with that enum to maximize performance. At that time there wouldn't be a performance penalty for separating "antichess" from "giveaway".

[ddugovic]

Note that castling in giveaway chess is subject to the caveat that castling rights are bound to the first king on the castling rank (when setting up a position).

[HGMuller]

Op 9/25/2016 om 1:17 AM schreef Daniel Dugovic:

Would it be possible for you to introduce something similar in
UCI, e.g. responding to "setoption name UCI_Variant value xxx"
with something like "info startpos " or "info string startpos "?

I'll have to take a look into compatibility issues for other GUIs (for
variants with the default start position) although this seems like a
reasonable thing to do, it also sounds complicated to do correctly.

If you send it as "info string startpos ..." GUIs that do not implement
it would simply consider it an 'info string', and at worst would display
the info to the user.

Another thing: I noticed that Crazyhouse isnot in the combo option, even
if HOUSE is defined, because there is no corresponding #ifdef in the
'variants' initialization code (although there is in the code that tests
for it). Was this intentional or just an oversight?

Regards, H.G.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ddugovic/Stockfish/issues/61#issuecomment-249392842,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVNwNn6HRpIw-XaXGTC1nNEOulJ78BtEks5qta9xgaJpZM4KEyLR.

[ianfab]

The crazyhouse rules aren't implemented yet. That's why it is not added to the combo option.

[ddugovic]

Thanks H.G. I'll find a way to make Stockfish print info string startpos .... (And @ianfab is correct, 99% of crazyhouse rules aren't yet implemented in this fork.)

[ddugovic]

@HGMuller Would instead be acceptable info variant [name] startpos [fen]? Currently Stockfish silently ignores when setoption name variant ... provides an unrecognized variant name.

I'll very soon separate Chess960 from the variant specifier...

[CPagador]

According to: http://sjeng.org/indexold.html

_Suicide is a form of chess where the goal is to lose all your pieces. If you can capture, you must. The king can be captured just like a normal piece and you can promote a pawn to a king. In case of a stalemate the player with the least pieces wins. You cannot castle.

Giveaway is very similar to suicide, but you can castle and in case of a stalemate the stalemated player wins.

Losers is also similar to suicide and giveaway, but the king works like it does in normal chess. It cannot be captured, you cannot a promote a piece to a king and if you are in check you must get out. You win by losing all your pieces or by being checkmated._

Engines that play Suicide: Losing Chess Wizard, Sjeng, KKFChess, Nebiyu, Pulsar.
Engines that play Losers: Sjeng, Gerbil, Pulsar, Olithink, KKFChess.

[ddugovic]

Ah, I was more referring to, "Does any person still play Losers?" According to ficsgames.org the answer is surprisingly yes, about 5% of variant games (which are about 1.5% of all games) are Losers.

[HGMuller]

OK, I see. I hoped it was just an oversight, because when variant
selection was still through check options, there was a checkbox for it.

Too bad. Ferdinand Mosca is planning a Crazyhouse Computer World
Championship, and I had hoped Stockfish variant could participate.

Regards, H.G.

Op 9/25/2016 om 1:49 PM schreef Fabian Fichter:

The crazyhouse rules aren't implemented yet. That's why it is not
added to the combo option.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ddugovic/Stockfish/issues/61#issuecomment-249417282,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVNwNvSqQsEnfLEWRAoaZqDDIVJlzIuMks5qtl-ygaJpZM4KEyLR.

[HGMuller]

Hi Daniel,

What variant name would you want to send back to the GUI? The one the
GUI just selected? That seems pointless from the point of view of the
GUI, and I don't see how it would be useful to the engine to print one
thing or another. But it is never harmful to send redundant information.

Note that a GUI should never send a setting for a combo option that was
not specified by the engine as possible 'var' in the corresponding
'option' command.

The issue is what should happen when the user (through the GUI) selects,
say, 'racingkings' from the combo menu, when the GUI hasn't the
slightest idea what 'racingkings' is. It then needs (at least) to get
the start position from the engine (from which the board size follows
anyway).

How does the variant selection in Stockfish work anyway? Would the
setting only take effect after a 'ucinewgame', or can these commands
come in either order? If 'ucinewgame' always has to be sent after a
variant change, the FEN could also be sent to the GUI in response to
'ucinewgame'.

Regards, H.G.

Op 9/25/2016 om 2:35 PM schreef Daniel Dugovic:

@HGMuller https://github.com/HGMuller Would instead be acceptable
|info variant [name] startpos [fen]|? Currently Stockfish silently
ignores when |setoption name variant ...| provides an unrecognized
variant name.

I'll very soon separate Chess960 from the variant specifier...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ddugovic/Stockfish/issues/61#issuecomment-249419503,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVNwNqRRlScuhaLC1bPLwMEmYZwv8xsVks5qtmqvgaJpZM4KEyLR.

[ddugovic]

Hi H.G.,

Stockfish validates the position while setting up the board in response to the position ... command, so it is best to first call setoption UCI_Variant....

Yes, I was thinking of sending back the variant name (if valid) to the GUI (or server process) both to help troubleshoot when consumers of Stockfish send commands in the wrong order, and to hint to new consumers that setting the variant first subtly affects setup (for example, setting the variant to threecheck before providing a FEN including the number of checks each player has already given is important).

Apparently ucinewgame has no effect on setoption UCI_Variant ... or on setoption UCI_Chess960 .... I suppose that starting a new game requires (steps 2 & 3 can occur in either order):

1. ucinewgame
2. setoption UCI_Chess960 ...
3. setoption UCI_Variant ...
4. position ...

[ddugovic]

Currently Stockfish (changes ported from SCIDB, then fixed numerous bugs) prints (and can parse) a FEN showing the number of checks given:

setoption name UCI_Variant value threecheck
position startpos moves e2e4 d7d5 f1b5
info string variant threecheck startpos rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 +0+0
d

 +---+---+---+---+---+---+---+---+
 | r | n | b | q | k | b | n | r |
 +---+---+---+---+---+---+---+---+
 | p | p | p |   | p | p | p | p |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   | B |   | p |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   | P |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 | P | P | P | P |   | P | P | P |
 +---+---+---+---+---+---+---+---+
 | R | N | B | Q | K |   | N | R |
 +---+---+---+---+---+---+---+---+

Fen: rnbqkbnr/ppp1pppp/8/1B1p4/4P3/8/PPPP1PPP/RNBQK1NR b KQkq - 1 2 +1+0
Key: 2B2AA0A63EE831D2
Checkers: b5 

For variants with piece drops WinBoard currently uses a system where the pieces in hand are bracketed with [] and written immediately behind the board position.

Noted, if/when I implement crazyhouse I'll follow this standard (or whatever standard WinBoard and crazyhouse engines follow at time of implementation).

(Lichess invented their own convention: after 1. e4 e5 2. Nf3 Nc6 3. Bc4 Bc5 4. O-O Nf6 5. b4 Bxb4 their FEN is: r1bqk2r/pppp1ppp/2n2n2/4p3/1bB1P3/5N2/P1PP1PPP/RNBQ1RK1/p w kq - 10 6)

[HGMuller]

Op 9/27/2016 om 9:15 AM schreef Daniel Dugovic:

Currently Stockfish (changes ported from SCIDB
http://scidb.sourceforge.net/links.html, then fixed numerous bugs)
prints (and can parse) a FEN showing the number of checks given:

|setoption name UCI_Variant value threecheck position startpos moves
e2e4 d7d5 f1b5 info string variant threecheck startpos
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 +0+0|
|The problem with this is that the number of checks given makes the
meaning of this field dependent on the variant that is being played.
E.g. FENs for game-theoretically identical positions in 'fourcheck' and
'threecheck' would get different FENs. The FEN would not convey all
information, and you would have to send the winning number of checks
separately. (Which of course would be implied by the variant name, but
only to GUIs that know it.) So it is not very suitable as a general
extension of the FEN standard that would work in any variant. In
WinBoard I try to avoid any variant-depedent standards. Putting the
field behind reversible-ply and full-move counter also seems a very bad
idea, as EPDs lack these fields, so that it would break the
compatibility between FEN and EPD parsing.

This is really only an issue when the user wants to set up positions,
though. Normally the GUI would use either "position startpos ..." or
would echo the FEN string it obtained from the "info string variant ...
startpos ...". But I can have UCI2WB convert any A+B field into
+(3-A)+(3-B) and place that at the end.

BTW, the possible ambiguity also remains in this format: if the board
position does show the side to move to be in check, is this check
already counted in the checks-given field of the FEN? And do the numbers
represent the checks delivered by the players or received by the players?

|
|

Noted, if/when I implement crazyhouse I'll follow this standard (or
whatever standard WinBoard and crazyhouse engines follow at time of
implementation).

(Lichess invented their own convention: after 1. e4 e5 2. Nf3 Nc6 3.
Bc4 Bc5 4. O-O Nf6 5. b4 Bxb4 their FEN is:
|r1bqk2r/pppp1ppp/2n2n2/4p3/1bB1P3/5N2/P1PP1PPP/RNBQ1RK1/p w kq - 10 6|)

I think this is based on the "bFEN standard" (e.g.
http://bughousechess.wz.cz/CompleteBughouseChessRules.htm ; I am not
sure that was invented by Lichess, although I am also not sure how
'standard' this actually is). They probably also use Q~ for a Pawn
promoted to Queen. WinBoard understands this format on reading, and
follows it as closely as possible on writing. But using a slash as
separator between board and holdings could cause ambiguity with 8x9
boards. So on writing it replaces that / by [, and closes that with ]
behind the holdings. It of course understands that also on reading, even
if there is extra whitespace in front of the [. Empty holdings are
written as [-] . (In bFEN these are just omitted, including the slash
separator.)

Regards, H.G.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ddugovic/Stockfish/issues/61#issuecomment-249785062,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVNwNlkNZfa2EqS_MEystMZaDzmHE74fks5quMKjgaJpZM4KEyLR.

[ddugovic]

Now I understand and agree. I suggest that after 1. e4 d5 2. Bb5+ the FEN string should be:
rnbqkbnr/ppp1pppp/8/1B1p4/4P3/8/PPPP1PPP/RNBQK1NR b KQkq - 3+2 1 2

That is, the check has already been played, so White needs to play 2 more checks to win (and Black needs to play 3 more checks to win).

You are correct that lichess uses bFEN for crazyhouse; however, they have not yet integrated a crazyhouse engine so I see no problem following the well-established WinBoard-FEN standard.