What's the role of the GUI?

[bob]

I'm not mixing things at all.

Yes, you are!

This has been discussed ad nauseum in the past, with no real resolution. If a GUI is going to participate in the game itself, rather than just being a "User Interface" (the UI part) then only one such instance should be allowed in a tournament. Time allocation is a tricky and interesting part of the game. Programmers should not be able to use an existing piece of code to handle that. Ditto for opening book move selection which is another very tricky and complex issue.

Absolutely. I agree completely. But once again: This is not an argument against letting the GUI doing some of the work in selecting the moves, but only against allowing the use of code written by others in selecting the moves.

I don't understand why this is so hard to understand. I'll try to explain once more, before I give up and go to bed:

Copying book and EGTB code from other programs is not OK. Using a GUI written by somebody else to select some of the game moves is not OK. These two are equivalent, apart from technical matters which are unimportant except to the programmer.

Writing an engine entirely by yourself which does all the work of selecting the moves, including book moves and EGTB access, is OK. Writing an engine which relies on a GUI written by yourself to select some of your moves is OK. These two are equivalent, apart from technical matters which are unimportant except to the programmer.

Tord

That is all I have been saying. None of the other stuff about progrmming design decisions matters to me at all. You can break the "system" into two parts or 200 parts and it doesn't matter to me. I only care about the stuff that gets shared in tournaments, and this has gotten quite out of hand at ICGA tournaments over the past 10+ years...

[Uri]

GUI = Graphical user interface

It's main task is to display the board. The calculation is left to the engines. Though some GUI protocols take over some roles such as time-management (+pondering), opening moves selection or endgame tablebase usage.

The most popular protocols used to communicate between the GUI and the engine are today: xboard and uci

So what is the difference between a GUI and a GUI protocol?

[bob]

I know what you are saying. Maybe it is because you are a high-level language guy, and I'm a low level language guy.

I'm not sure it's only that. Even if I were sufficiently masochistic to write my interface in plain C, I would prefer to let my engine do nothing more than computing the moves. It's just a far cleaner design, IMHO. I want to keep my engine code as simple and uncluttered as possible (although pressure from users has unfortunately forced me to pollute it with a few things like book code and a benchmark function).

Really, I just like having as much control as possible over the strength of my engine, whether it's a good thing or not. I like to have my own book formats, book-move selection algorithms, resigning, drawing, etc.

So do I, and I have just as much control over it when I do it from the GUI. In a certain sense, I have even more control, because both the development time and the risk of bugs are an order of magnitude smaller.

I also would like to someday implement a specialized pondering algorithm and a "swindle mode".

So would I, but again, driving it from the GUI would work just as well.

Keeping track of clocks and loading PGNs, that's something else. I have those implemented in my engine firstly as a programming exercise--it's fun--and because I normally use my engine (when not running tournaments) on the command line.

I do that, to -- more specifically from the Lisp prompt, with various functions for interacting with the engine and instructing it to do different tasks. The main difference compared to interacting directly with the engine is that instead of just having access to the few lame commands I have implemented in the engine, I have access to a full, powerful interactive programming language, extended with functions for running matches, tournaments and test suites, for pretty-printing PVs, for reading and writing PGN games, for opening a window with a graphical chess board, and so on.

I don't like my engine to require a GUI to play with.

Neither do I, but it doesn't.

Tord

The problem is that "the way of the future" is to use automated testing. Yes, we can do this on ICC today and let everyone use their custom GUI, and it works well. But most want to use an arena-like approach and that means that an engine whose GUI does a lot of the work is not going to play properly when it has no book and no guidance for pondering and such. The GUI is just in the way for automated tournaments, and requiring one makes life more complicated.

But that is your design decision. I am thinking way more generically to the case where several use the ChessBase (Fritz) GUI, and as a side-product they get the Fritz book, endgame tables at the root, etc, all for absolutely no effort. And as more "stuff" is put into the GUI, they get more "stuff" written and debugged by others, again for free. If you study tournament chess, opening book handling is as important as any other part of the game, since often games will see 1/2 (or more) of the total moves played come from the opening book. That's what I (and others) don't want to see shared.

Bruce Moreland raised the issue once at an ICGA tournament by phrasing the rhetorical question "Do I really have to play against Alex Kure's book three times in the same tournament?" Alex is an outstanding book preparation person, and for that event I think it was probably Fritz, Rebel, ChessTiger that shared a book he developed (I am not certain about the programs, but the idea is the same)...

So for a "single-use" application, the division between GUI and engine is irrelevant to anyone other than the author. But if others plan on using the GUI part, then the GUI ought to be just a "GUI" and not participate in any game decisions whatsoever...