Elements of the ULTIMATE Chess GUI?

[hgm]

Take a breath and calm yourself.
No one ever talked about intelligence or the lack of it.
We are talking about knowledge, and in particular knowledge that users do not WANT to be forced to learn (about chess protocols, about how your program works internally, why some engines need parameters or a directory, etc.).

Not wanting to learn all that should not really conflict with the presence of an extra facility for people that do want to learn. (Well, it requires them to learn how to read, so they can understand a "hands off" sign...).

I agree it is very unfortunate there do exist engines that need command-line parameters, or interpreters that need the engine source as command-line parameter, just as it is very unfortunate that UCI (and even more so USI, and all those other crimes against humanity) exist but it is a fact of life that they do exist. So users must decide where their priorities lie: either they 'learn' that README files are actually intended for reading before you start blundering around, or they should just stay away from those engines. I should not make that choice for them, and I would never sacrifice the interests of the group that is prepared to learn how to use the more difficult engines to indulge the group that is not prepared to make any effort whatsoever.

I still don't see how it would harm the interest of the ignorant bunch in any way if the dialog they use to select a new engine from contains one or two controls only useful for the 'expert user', as long as it is clearly indicated they are optional and should not be used unless a README file requested it. People that are so intolerant that they object to my menu card having pork on it because they only like beef are not welcome in my restaurant!

[hgm]

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...

Well, "protover 2" / "feature done=1" is the CECP equivalent. The problem is WB v1, and in particular poorly implemented WB v1, because fully compliant WB v1 engines are expected to answer to "protover 2" with "Error (unknown command): protover". If WB protocol is so poorly implemented, it would be likely preferable to run such engines under UCI, if they can. (Which, as I said, seems extremely unlikely.)

[gbtami]

The argument for not wanting a UCI/WB choice was that the user should not be bothered to know about UCI or WB. To have him change it later would need him actively go hunting for a dialog where he can change this. Which would require him to know for this particular engine that it is both WB and UCI, or why else would he even try?

I would prefer CECP as a first choice because it is more functional. It seems wrong to automatically start dual-protocol engines in the inferior mode that limits their capabilitieis by default. It is true that WB v1 engines would not respond to the 'protover 2' probe, but it is very unlikely that any dual-protocol engine would not support WB v2. (And there is really no excuse for doing that.)

I think you missed my point. In Xboard/Winboard if a user downloads a new engine (for example the latest Stockfish) and he wants to play with it he can select it pressing ... on "Load New 1st Engine" dialog, select the binary then push Ok. Then he takes hes first move. And he is waiting... Forever because Stockfish doesn't starts to play. Because Xboard expects to click UCI. But user knows nothing about this.

My point is why not provide useful default (UCI clicked in this case) if we can introspect engines for supported protocol. (If it support both UCI and Xboard you can select Xboard as the default if you think UCI is inferior.)

[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.