Elements of the ULTIMATE Chess GUI?

[modolief]

Thanks for the excellent question.

I've been playing with chess programs since the 1980s and have seen a lot of interesting ideas over time. I've also tried the big majority of chess programs out there on DOS, Windows, Mac, Linux, iOS. I often find myself wanting more and better so I think there's a lot that can still be done in this space.

How do we learn from the engines? Watching their analysis is too passive, I think we have to play them. But engine personalities? ... Maybe.

Larry Kaufman has been a big proponent of odds games and I really like this idea. That way the engine is exactly what it is and the programmer doesn't have to somehow "make it human".

Aquarium and the newest Fritz UIs offer ways to do a new game with a particular material handicap to start the game. These programs have about 15 or 20 different ways to start an odds game. I'd like to see an expanded version of this. I'd like to see user specified odds, e.g. what if (playing White) I want black's Bishops and one Knight removed and one of my Rooks and one Pawn removed (BBN vs RP). And I'd like to see an option to have that opening position randomized, like chess 960, or a full shuffle of both sides.

Related to this I'd like rather granular time control options. So once I've set some odds, I'd like to play a bunch of games. I've found that I like a time control of say 3'2" vs 1'1". In fact, I think I'd prefer 3'2" vs 15"1" -- most engines take a long time in unfamiliar start positions; I don't want the program to be really slow at the start as it disrupts the rhythm. In fact, if I'm playing the same exact start position again, I'd like the program to remember some of its analysis from the last time so it doesn't play the same ... or maybe I DO want it to play the same way so I might be able to find a winning path against predictable play -- I'd like the option. Basically I want highly configurable handicap games.

[gbtami]

"Perhaps your method can be adapted by sending 'xboard' and 'protover 2' first, and then, if there is no quick response, try if 'uci' evokes one."

Whis is this better than the opposite?

I can't speak for the general case. For SjaakII, CECP should be preferred to UCI, both because it receives more testing, but also because it has better variant support. However, to fully benefit from that the GUI should also support CECP custom variants.

It is a useful thing that the "uci"/"uciok" handshake exists. It is a shame that there is no "xboard"/"xboardok" equivalent that works reliably. As such, you can detect reliably whether an engine claims to support UCI, but you can only guess if an engine seems to support CECP...

Multi protocol variant engines are rather rare and if the GUI doesn't provide a default protocol user have to chose anyhow. If he knows that CECP will be better for a particular engine he can change from UCI to CECP. It's not much work then selecting if there was nothing there as default.

[hgm]

I think you missed my point. In Xboard/Winboard if a user ...

I think this would always happen if you picked the wrong default; a WB engine would hang if you installed it as UCI.

But I see your point; it is nasty that this is only detected in such a late stage. I am starting to wonder now why this is. Compliant WB v1 egines should also quickly respond to the "protover 2" command (with an error message), so if an engine remains silent it is a strong indication that it is UCI. And even if it is a non-compliant WB v1 (not giving any error message), it does not seem very harmful to probe it with 'uci'. (After all, the "protover" was also a non-compliant command in WB v1.)

I think I would always prefer to make auto-detection optional, however. E.g. through a combobox "protocol", with the choices 'automatic' (default), WB, UCI, and USI/UCCI/Arena960.

[gbtami]

I think you missed my point. In Xboard/Winboard if a user ...

I think this would always happen if you picked the wrong default

No. I not picked any protocol at all. I just pushed ..., selected stockfish, then pushed Ok. Xboard was not complaining to select any protocol. It started the new human-engine game.
I think Xboard selected the wrong protocol (or enabled to go on with undefined protocol)!

[hgm]

CECP is the default protocol for WinBoard, so if you don't tick any of the 'foreign' protocols, it implicitly selects CECP. But what I meant was that ticking UCI with a WB engine would give you the same effect; the engine would just appear dead, because it would not recognize any of the commands intended to make it do something.

The sequence

> xboard
> protover 2
< unknown command: xboard ? => UCI
< feature ... ? => WB v2
< Error (unknown command); protover ? => WB v1
wait 1 sec
> uci
< uciok ? => UCI
wait 1 sec
WB v1

seems a reasonably reliable protocol determination, and could be made default. In any case ignoring engine complaints like "unknown command: xboard", which is apparently what Stockfish (non-compliantly?) would say, seems a missed opportunity.

[gbtami]

"CECP is the default protocol for WinBoard, so if you don't tick any of the 'foreign' protocols, it implicitly selects CECP."

This seems a bug for me.

"But what I meant was that ticking UCI with a WB engine would give you the same effect; the engine would just appear dead, because it would not recognize any of the commands intended to make it do something."

This is obvious, and can be avoided if you introspect new engines for UCI and disable selecting it if engine doesn't support it.

Your protocol detection suggestion seems reasonable.

[hgm]

Why would that be a bug? It seems quite logical to me that WinBoard would use WB protocol if not explicitly instructed to use something else.

[gbtami]

Why would that be a bug? It seems quite logical to me that WinBoard would use WB protocol if not explicitly instructed to use something else.

Using a protocol by default when you don't know if engine supports it or not is not logical at all for me. I just described the steps how one can add a new engine which can't start in a new human-engine game without any error/warning.

[hgm]

Sure, but that assumes that you do autodetection of the protocol. Because of the bad reputation this had I never bothered to try that in WinBoard. People always told me that it was better if they could select the protocol themselves.

[Evert]

CECP is the default protocol for WinBoard, so if you don't tick any of the 'foreign' protocols, it implicitly selects CECP. But what I meant was that ticking UCI with a WB engine would give you the same effect; the engine would just appear dead, because it would not recognize any of the commands intended to make it do something.

The sequence

> xboard
> protover 2
< unknown command: xboard ? => UCI
< feature ... ? => WB v2
< Error (unknown command); protover ? => WB v1
wait 1 sec
> uci
< uciok ? => UCI
wait 1 sec
WB v1

seems a reasonably reliable protocol determination, and could be made default. In any case ignoring engine complaints like "unknown command: xboard", which is apparently what Stockfish (non-compliantly?) would say, seems a missed opportunity.

Doesn't the UCI spec say engines should ignore unknown input? In other words, the engine would not respond at all to xboard/protover.

I know people are bitching about having options, but I would prefer an option to configure X/WinBoard to use autodetect/cecp/uci by default...