King of the Hill programs?

[hgm]

Indeed, through Google I could finally find a page on Lichess that described the rules concisely. (It did not seem reachable from their home page in any way.) This also made it clear that having your King on the hill does not unconditionally decide the game, but is equivalent to delivering check: you are not allowed to do it if it exposes your own King to capture. So the engine has to test it before it moves, rather than after it, to give the opponent the opportunity to prove the move was illegal by FIDE standards.

This improved version of Fairy-Max triggers the hill-test and extra King-centralization eval term by piece #3 in the rule description in fmax.ini having a piece value of -2 (in stead of the usual -1 to indicate royalty). That makes it in principle possible to configure any other variant also for playing with hill rules, by copying its description, giving it another name, altering the King value to -2, and sorting the pieces such that the King is third (if that isn't already the case). Perhaps I should put a checkbox amongst the engine options, 'Hill victory condition', so that people would just have to tick that to play, say, Capablanca Chess with a hill.

[Evert]

It could also be used to group variants in groups that can be opened and closed like a tree widget, as you can do with egines and themes. (But the engine would have to define the groups somehow in its variants feature, requiring new protocol.)

How about grouping them by the "parent variant", if specified? If not specified, could just default to "normal" or "fairy".

And you, Daniel and (perhaps I) are likely the only 3 persons in the World forwhich the current 9 reserved buttons are not enough!

For people writing engines, that's probably true. For people playing variants against the computer? I'm not so sure. I get the impression that there's still a (niche) community of people that play chess variants through Zillions of Games, which could benefit from having more than 9 extra buttons.

Another quick work-around is a "more…" button that opens up a new dialog box that lists the variants it couldn't fit in. Might be the same amount of hassle and less elegant though. I do agree that it's nice to show the variants that the engine doesn't support, so people can become aware of them, that's a good point.

Either way, it's clear that this requires some careful thought.

Adding 9 additional radio buttons would be pretty trivial, though. Would that be enough for you?

Short answer: no.
Long answer: Sjaak currently has 21 built-in variants (but some of those are recognised variants) and 20 more variants specified in its configuration file (not all of which work correctly at the moment, and one of which just duplicates variant normal), but anyone could add more to it (and I almost certainly will). I have plans to add at least some Shogi variants and probably Korean chess to the mix...

Since this was essentially an experimental feature, I did not want to go over board on it immediately.

Sure. It's not something I'd need yesterday.

I have not decided yet if it is actually desirable to make every possible combination of armies in Chess with Different Armies a separate choice in the New Variant menu. It might be better to give Fairy-Max a single new engine-defined variant CWDA, and equip it with two comboboxes to independently choose army 1 and army 2. It would be an annoyance that you had to set them (and better set them alike!) in both engine 1 and engine 2. But hey, who would ever use that for engine-engine games? Most of this stuff is meant for human-engine, exactly what Guenther is doing now. Fairy-Max is ideal for that, because it does not completely overwhelm humans tactically, although it does have an edge there. But its general strategic ignorance can be exploited by a careful human.

I could argue either way for those. Is it really the same variant if between two games neither army is the same as in the other? If I can select an army from a list, why couldn't I select the Spartan army as well?

[hgm]

Short answer: no.
Long answer: Sjaak currently has 21 built-in variants (but some of those are recognised variants) and 20 more variants specified in its configuration file (not all of which work correctly at the moment, and one of which just duplicates variant normal), but anyone could add more to it (and I almost certainly will). I have plans to add at least some Shogi variants and probably Korean chess to the mix...

Hmm, yes, I see why this would be a problem.

I guess the New Variant dialog needs re-designing anyway. The order of the standard variants is an absolute mess in WinBoard (mostly historic accident). The radio buttons are a poor way to select a variant, because you have to press OK afterwards. In XBoard this works much nicer, there you just press the variant button and the dialog pops down automatically.

Double-clicking on listbox item in Load Engine also does that (both in WinBoard and XBoard). The problem I see with a listbox, though, is that it isn't easy to indicate a variant is disabled (other than not showing it altogether).

Grouping by parent variant might not help too much, as most would likely have parent fairy. I already discovered that 'normal' isn't really a good choice, as this tends to suppress mentioning the variant in many places. And picking a shuffle variant as parent was also a bad idea. (The 'setup' command can specify shuffling through the FEN, and also imply whether Fischer castling should be allowed in the variant. So there is never really a need to start from a shuffle variant.)

In fact there is a steady 'dismantling' of variants going on in XBoard, by taking their distinctive traits, and making them generally available. There are hardly any variants that still offer something you could not get in another way, (and get it through the protocol from the engine rather than through options).

[Evert]

I guess the New Variant dialog needs re-designing anyway. The order of the standard variants is an absolute mess in WinBoard (mostly historic accident). The radio buttons are a poor way to select a variant, because you have to press OK afterwards. In XBoard this works much nicer, there you just press the variant button and the dialog pops down automatically.

Ah, I hadn't realised this is different in Windows.

Double-clicking on listbox item in Load Engine also does that (both in WinBoard and XBoard). The problem I see with a listbox, though, is that it isn't easy to indicate a variant is disabled (other than not showing it altogether).

What I had in the back of my mind is how the OS X file selection dialog box works: it will show all files, but the ones that cannot be selected (because the program can't open them) are greyed out. I seem to recall that something like that is/was possible for regular listboxes in Windows as well, but this is a memory from more than 15 (close to 20, yikes) years ago and even if it can be done, it may not be so easy through GTK (I don't know).

Grouping by parent variant might not help too much, as most would likely have parent fairy. I already discovered that 'normal' isn't really a good choice, as this tends to suppress mentioning the variant in many places. And picking a shuffle variant as parent was also a bad idea. (The 'setup' command can specify shuffling through the FEN, and also imply whether Fischer castling should be allowed in the variant. So there is never really a need to start from a shuffle variant.)

Hmm… I guess that's true. Anything with unorthodox pieces would be "fairy". Say I replace the Queen with a Chancellor. I'd probably want it listed with "normal" rather than being lumped in with everything else under "fairy"...

In fact there is a steady 'dismantling' of variants going on in XBoard, by taking their distinctive traits, and making them generally available. There are hardly any variants that still offer something you could not get in another way, (and get it through the protocol from the engine rather than through options).

That's a very good thing!

[hgm]

What I had in the back of my mind is how the OS X file selection dialog box works: it will show all files, but the ones that cannot be selected (because the program can't open them) are greyed out. I seem to recall that something like that is/was possible for regular listboxes in Windows as well, but this is a memory from more than 15 (close to 20, yikes) years ago and even if it can be done, it may not be so easy through GTK (I don't know).

Oh, I didn't know this was possible in Windows listboxes. (Never seen it.) Of course it is easy enough to make that nothing happens when you click something, but it would be nice if there was some visible cue. If only so that things that will work stand out better.

Even if it is just printing the unavailable choices in italics. The currnet variant could be printed in boldface. (That was the second problem with listboxes I wanted to mention, but then slipped my mind again: to show what is currently selected.)

Hmm… I guess that's true. Anything with unorthodox pieces would be "fairy". Say I replace the Queen with a Chancellor. I'd probably want it listed with "normal" rather than being lumped in with everything else under "fairy"...

Why is that? I would say Chancellor Chess is the archetypal fairy variant: Chess according to regular rules with some pieces that move in unorthodox ways. In the current XBoard version 'normal' as parent variant does not work satisfactorily. (E.g. there would not be a Variant tag in the PGN, so that you would never see what the engine-defined name was.)

That's a very good thing!

Yes, I think so too, that's why I am doing it. It would be great if the few remaining unique proparties of some variants (explosive capture, seirawan gating, stalemate result, promotion to captured, promotion-zone depth, royal piece, delocalized royalty) could also all be configured by the engine (or through command-line options). Then everything would be the same variant, just with different flag settings. The whole concept of 'parent variant' would become meaningless.

That reminds me: Now that the 'piece' commands can configure XBoard's move generator, there should perhaps be options that can do that too.

[Evert]

Oh, I didn't know this was possible in Windows listboxes. (Never seen it.) Of course it is easy enough to make that nothing happens when you click something, but it would be nice if there was some visible cue. If only so that things that will work stand out better.

Well, do remember that I'm quoting from memory of something that dates back to when 16 bits was the norm, and I haven't touched Windows in more than 10 years. So I may remember wrong, but it's worth checking.

Even if it is just printing the unavailable choices in italics. The currnet variant could be printed in boldface. (That was the second problem with listboxes I wanted to mention, but then slipped my mind again: to show what is currently selected.)

Shouldn't that one be printed inverted in the list?

Why is that? I would say Chancellor Chess is the archetypal fairy variant: Chess according to regular rules with some pieces that move in unorthodox ways.

Maybe. When I hear "fairy" I tend to think of something more exotic than just swapping out one piece for another, but I guess that would go under "alien".
But of course this only reinforces the point that if you leave it up to engine authors to classify varients, you will end up with a mess in the end.

Yes, I think so too, that's why I am doing it. It would be great if the few remaining unique proparties of some variants (explosive capture, seirawan gating, stalemate result, promotion to captured, promotion-zone depth, royal piece, delocalized royalty) could also all be configured by the engine (or through command-line options). Then everything would be the same variant, just with different flag settings. The whole concept of 'parent variant' would become meaningless.

That reminds me: Now that the 'piece' commands can configure XBoard's move generator, there should perhaps be options that can do that too.

That would be great. In particular if the promotion zone could be something more complicated than simply the back ranks (for something like Sittuyin, say).

[hgm]

Shouldn't that one be printed inverted in the list?

The problem is that that is 'volatile', and can be changed by single clicks or arrow keys. So it indicates the variant you would get if you press OK, but not the variant you keep if you press Cancel.

That would be great. In particular if the promotion zone could be something more complicated than simply the back ranks (for something like Sittuyin, say).

Well, for the time being the 'highlight' protocol can be used to solve that: highlight promotions in magenta, and XBoard will know they are promotions even if they are extrazonal.

[Thorn123]

On lichess.org it is possible to challenge a modified Stockfish to a game of King of the Hill as well as analyze played games using this engine

[hgm]

Well, probably even an unmodified Stockfish would crush Fairy-Max at it, simply because it overwhelms Fairy-Max tactically, and checkmates it long before the board has thinned out enough that there is any chance that a King could survive in the center.

[Evert]

Ok, the development version of Sjaak now plays this as well. Here's a test game:

[pgn]
[Event "Computer Chess Game"]
[Site "vivaine.local"]
[Date "2014.10.23"]
[Round "4"]
[White "Sjaak II "]
[Black "Sjaak II "]
[Result "0-1"]
[TimeControl "40/10"]
[VariantMen "P:fmWfceFifmW2;N:N;B:B;R:R;Q:Q;K:KisO2"]
[FEN "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1"]
[SetUp "1"]

{--------------
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
white to play
--------------}
1. c4 {+0.11/8} d5 {+0.03/7 0.1} 2. Nc3 {+0.10/7 0.1} dxc4 {+0.08/7 0.1} 3.
Qa4+ {-0.12/8 0.3} Nc6 {+0.04/7 0.1} 4. Qxc4 {-0.03/8 0.2} Be6
{-0.05/7 0.3} 5. Qb5 {+0.16/8 0.3} Rb8 {-0.16/7 0.2} 6. Nf3 {+0.18/7 0.1}
Nf6 {-0.07/7 0.3} 7. Ng5 {+0.41/6 0.1} Qd6 {-0.16/6 0.2} 8. Nxe6
{+0.24/8 0.5} fxe6 {-0.23/7 0.2} 9. e3 {+0.26/7 0.2} a6 {-0.28/7 0.3} 10.
Qd3 {+0.27/7 0.2} Nb4 {-0.21/7 0.2} 11. Qxd6 {+0.10/7 0.2} cxd6
{-0.20/8 0.2} 12. Kd1 {+0.16/8 0.2} Rc8 {-0.13/8 0.3} 13. Be2 {+0.25/8 0.4}
g5 {-0.13/8 0.2} 14. f4 {+0.10/7 0.2} gxf4 {+0.19/8 0.2} 15. exf4
{+0.13/8 0.2} Bh6 {+0.05/7 0.2} 16. d4 {+0.13/6 0.2} Bg7 {-0.25/7 0.3} 17.
h4 {+0.29/7 0.3} b5 {-0.04/6 0.1} 18. a4 {+0.17/7 0.3} Nd7 {-0.44/7 0.2}
19. axb5 {+0.39/8 0.3} Bxd4 {-0.52/7 0.2} 20. bxa6 {+1.20/7 0.2} Nc6
{-1.13/6 0.2} 21. Nb5 {+1.30/7 0.3} Bb6 {-1.42/7 0.2} 22. Bh5+
{+1.42/7 0.2} Kd8 {-1.43/7 0.2} 23. Bf3 {+1.32/7 0.2} d5 {-1.21/8 0.3} 24.
f5 {+1.57/8 0.2} exf5 {-1.37/8 0.3} 25. a7 {+2.07/8 0.2} Ra8 {-2.08/8 0.2}
26. Bxd5 {+2.09/9 0.2} Nxa7 {-2.06/8 0.3} 27. Bxa8 {+2.06/7 0.2} Nxb5
{-2.04/8 0.2} 28. Be4 {+2.83/8 0.2} fxe4 {+1.60/8 0.3} 29. Ra8+ {
+3.55/10 0.2} Kc7 {+7.06/9 0.2} 30. Rxh8 {+3.65/10 0.2} Kd6
{+159.97/3 0.1} 31. Rxh7 {+3.75/9 0.2} Kd5 {+159.99/2 0.1} 32. Rxe7
{+4.68/9 0.2}
{Black captures the flag} 0-1
[/pgn]
What is really bizarre though is that White completely seems to miss what is going on and misses the black King walking into the centre (it also misses the fact that it's lost the game, so White still plays a move and then Black claims the victory). What's double-odd is that if I feed the position to the engine and hit "go", Sjaak immediately responds with "0-1 {Black captures the flag}" and doesn't start thinking.

So getting there, but not quite there yet...