What's the role of the GUI?

[Guetti]

But what if one wanted to support a common opening book format, like i.e. book files created with polyglot. He would have to type in the book code himself, using Fruit/polyglot functions as a reference?

Easy: Just implement support for Polyglot (or whatever) books in the public version of your program for the benefit of your users, but use something else in tournaments.

Tord

But what's the sense of this? In my opinion it would be enough to just use a own/different book file in the tournament. I don't see a problem in using the same book code, as long as the book (and the moves played) are different?
By using the same book code I ensure compatibility with a common book format.

[wgarvin]

You are mixing two entirely unrelated things here. How tasks are divided between the UI and the engine part of a chess program is a purely technical design decision by the author, and is completely irrelevant with regard to computer chess events. To what extent a program should be allowed to use code written by other people than the author(s) to select its moves is an entirely different question.

Tord

I'm not mixing things at all. 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.

GUI does _not_ imply all of those things. A user interface is simply an interface that sits between a user and some application, in this case a chess engine. The interface "connects" the two, no more, no less. Xboard/Winboard is a classic example. It does nothing but relay moves between the user and the engine, and display the board... That is a traditional GUI.

Right. There have been two issues brought up in this thread, which do not really seem related:

(1) Credit for original work vs. clone engines. If you take code, opening books, etc. written by others for other chess engines and use it in your own engine, you end up with a bunch of engines that play the same (as Bob says, he doesn't want to play against 10 opponents that are all clones of each other). Also, there is the issue of how much credit the author deserves for creating his engine and for the quality of its play. If the style, strength, etc. of its play are largely influenced by code, opening books, etc. that were taken straight from other engines, in my view that diminishes the amount of credit deserved by the author, and might be reason enough to exclude that engine from competitions like tournaments (I'm no judge of that though). On the other hand, if you write it all yourself then I think you deserve all of the credit for producing a quality engine (even if you got a big head start by using the ideas that have been well-developed and demonstrated by others; share and share alike).

(2) How to divide labor between engine and GUI. I think this is simple... Functionality for playing chess should be in the engine, and only User Interface things should be in the GUI. They should talk using a protocol such as the Winboard protocol, that is understood by other engines and other GUIs. Then we can mix and match them and do interesting things. I think there is no defensible reason, technical or political, for putting chess-playing functionality into the GUI part instead of the engine part. There's one clear right way of doing this, and a bunch of wrong ways. I believe strongly that Tord's way (the Shredder way) is the wrong way. I think it is less flexible for users and destroys the benefits of having the GUI and the engine be separate, modular components. I don't believe there are any benefits of doing that, which can not be had in better, cleaner ways.

To be clearer about (2): If there is something you would like the user to be able to do through the GUI, for example, fiddle with engine configuration settings, or request that it move immediately or that it analyse a position or play a position from the opening book, or behave according to a certain time control---those are all things that the engine should do, after the user's request is passed along to it through the GUI.

This principle is used in other programming domains where the GUI is a separate program, as well. Some examples that come to mind are version control systems like Perforce, which have a bunch of command-line tools which do work, and a nice GUI which makes it easy to interact with the command line tools and draws them all together. There is nothing you can do with the GUI that can't be done by the command-line tools, though! They are the workhorse, and the GUI is just the container for the nice presentation and interaction. Another example is the debugger gdb, a command-line debugger for which various graphical front-ends have been made. These front ends might have some nifty features to make the presentation or interaction better, but ultimately everything they do is done by talking to the command-line gdb underneath. Thus you can always stop using the colorful GUI thing and just use the command-line program underneath, if you want. Or you can connect a different front-end program to it which can speak the same command-line protocol. Just like Winboard users can do with Winboard engines.

The GUI should exist only to give a nice presentation to users, and let the users interact with the engine--request actions or information, and see the results displayed, and see the game played out. I really wish SMK had never put a bunch of gameplay-related responsibilities into the Shredder GUI, I think he did the world of computer chess a major disservice by doing that. Sigh...

[Dann Corbit]

You are mixing two entirely unrelated things here. How tasks are divided between the UI and the engine part of a chess program is a purely technical design decision by the author, and is completely irrelevant with regard to computer chess events. To what extent a program should be allowed to use code written by other people than the author(s) to select its moves is an entirely different question.

Tord

I'm not mixing things at all. 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.

GUI does _not_ imply all of those things. A user interface is simply an interface that sits between a user and some application, in this case a chess engine. The interface "connects" the two, no more, no less. Xboard/Winboard is a classic example. It does nothing but relay moves between the user and the engine, and display the board... That is a traditional GUI.

Right. There have been two issues brought up in this thread, which do not really seem related:

(1) Credit for original work vs. clone engines. If you take code, opening books, etc. written by others for other chess engines and use it in your own engine, you end up with a bunch of engines that play the same (as Bob says, he doesn't want to play against 10 opponents that are all clones of each other). Also, there is the issue of how much credit the author deserves for creating his engine and for the quality of its play. If the style, strength, etc. of its play are largely influenced by code, opening books, etc. that were taken straight from other engines, in my view that diminishes the amount of credit deserved by the author, and might be reason enough to exclude that engine from competitions like tournaments (I'm no judge of that though). On the other hand, if you write it all yourself then I think you deserve all of the credit for producing a quality engine (even if you got a big head start by using the ideas that have been well-developed and demonstrated by others; share and share alike).

(2) How to divide labor between engine and GUI. I think this is simple... Functionality for playing chess should be in the engine, and only User Interface things should be in the GUI. They should talk using a protocol such as the Winboard protocol, that is understood by other engines and other GUIs. Then we can mix and match them and do interesting things. I think there is no defensible reason, technical or political, for putting chess-playing functionality into the GUI part instead of the engine part. There's one clear right way of doing this, and a bunch of wrong ways. I believe strongly that Tord's way (the Shredder way) is the wrong way. I think it is less flexible for users and destroys the benefits of having the GUI and the engine be separate, modular components. I don't believe there are any benefits of doing that, which can not be had in better, cleaner ways.

To be clearer about (2): If there is something you would like the user to be able to do through the GUI, for example, fiddle with engine configuration settings, or request that it move immediately or that it analyse a position or play a position from the opening book, or behave according to a certain time control---those are all things that the engine should do, after the user's request is passed along to it through the GUI.

This principle is used in other programming domains where the GUI is a separate program, as well. Some examples that come to mind are version control systems like Perforce, which have a bunch of command-line tools which do work, and a nice GUI which makes it easy to interact with the command line tools and draws them all together. There is nothing you can do with the GUI that can't be done by the command-line tools, though! They are the workhorse, and the GUI is just the container for the nice presentation and interaction. Another example is the debugger gdb, a command-line debugger for which various graphical front-ends have been made. These front ends might have some nifty features to make the presentation or interaction better, but ultimately everything they do is done by talking to the command-line gdb underneath. Thus you can always stop using the colorful GUI thing and just use the command-line program underneath, if you want. Or you can connect a different front-end program to it which can speak the same command-line protocol. Just like Winboard users can do with Winboard engines.

The GUI should exist only to give a nice presentation to users, and let the users interact with the engine--request actions or information, and see the results displayed, and see the game played out. I really wish SMK had never put a bunch of gameplay-related responsibilities into the Shredder GUI, I think he did the world of computer chess a major disservice by doing that. Sigh...

You are thinking about the chess program authors and your desire to have a particular set of ideological parameters for tournaments.

SMK was thinking about making things better for his customers.

My number one rule of software design:
1. Make the customer prosper.

If we do that then our software is a success. As far as we miss that ideal, our software is a failure.

[wgarvin]

You are thinking about the chess program authors and your desire to have a particular set of ideological parameters for tournaments.

SMK was thinking about making things better for his customers.

My number one rule of software design:
1. Make the customer prosper.

If we do that then our software is a success. As far as we miss that ideal, our software is a failure.

Fair enough. I don't know much about the Shredder GUI (I've never used it) but I can't imagine anything it can do, which couldn't have been put into the engine instead (or a shared DLL, or ...).

Maybe it was commercially expedient for him to do things that way. Maybe it was less painful, or easier, or something. I still think its a bad design. Even if it made practical sense for Shredder or some other commercial engine, I don't think its a design that should be emulated, when a better model is clearly available to be emulated.

[Dann Corbit]

You are thinking about the chess program authors and your desire to have a particular set of ideological parameters for tournaments.

SMK was thinking about making things better for his customers.

My number one rule of software design:
1. Make the customer prosper.

If we do that then our software is a success. As far as we miss that ideal, our software is a failure.

Fair enough. I don't know much about the Shredder GUI (I've never used it) but I can't imagine anything it can do, which couldn't have been put into the engine instead (or a shared DLL, or ...).

Maybe it was commercially expedient for him to do things that way. Maybe it was less painful, or easier, or something. I still think its a bad design. Even if it made practical sense for Shredder or some other commercial engine, I don't think its a design that should be emulated, when a better model is clearly available to be emulated.

I think the burning question here is:
"Better for who?"

Now, that introduces another question:
"Who am I building this engine for?"

If the answer is "Myself" and you are the only intended customer, then it does not matter how difficult it is to get it to do things that other customers would want because they are irrelevant. Such is the case for private engines, for instance.

As I see it, there are two chess interfaces which are the most friendly to the customer:
Shredder and ChessAssistant.
Furthermore, both of these companies listen to the customers and follow their feedback and incorporate customer demands into their tool sets.

I don't think that we see these features by accident. They are the features that the customer wants.

When I do a chess tournament, I want to end the game as a draw if both engines have tablebase files and we are in a drawn position. I think it is positively stupid to bluff on for another four hours and a total waste of my computer time.

I want to say the game is over if some engine is down 6 pawns or more for 3 moves in a row. It is true that some engines might come back if given enough time and even that I would miss a brilliancy because of my impatience. But I want it to do what I want it to do, whether the programmer likes it or not. I want to get my hands on the data, and I don't want to wait one second longer than I have to to get it.

Now, a chess program author may be strongly at odds with this. They may hope that the other program has a bug in it's tablebase handling code and therefore might lose or might lose on time. But that would be bad to me, because I want to know about something that is formally proven a draw and I do not want to continue pounding away on that particular data point because I am done with it.
The chess programmer may abhor the 1/10000th of a point they will lose because some tournament manger declares a loss after both engines agree that one side is down 600 centipawns for 3 consecutive moves. But this is another case where "it's all over but the shouting/crying" and I don't need to see any more.

So the tool vendors are listening to what I want. I also think that their choices are better for the general population (but I agree that chess programmers may not like it).

[wgarvin]

When I do a chess tournament, I want to end the game as a draw if both engines have tablebase files and we are in a drawn position. I think it is positively stupid to bluff on for another four hours and a total waste of my computer time.

I want to say the game is over if some engine is down 6 pawns or more for 3 moves in a row. It is true that some engines might come back if given enough time and even that I would miss a brilliancy because of my impatience. But I want it to do what I want it to do, whether the programmer likes it or not. I want to get my hands on the data, and I don't want to wait one second longer than I have to to get it.

Now, a chess program author may be strongly at odds with this. They may hope that the other program has a bug in it's tablebase handling code and therefore might lose or might lose on time. But that would be bad to me, because I want to know about something that is formally proven a draw and I do not want to continue pounding away on that particular data point because I am done with it.
The chess programmer may abhor the 1/10000th of a point they will lose because some tournament manger declares a loss after both engines agree that one side is down 600 centipawns for 3 consecutive moves. But this is another case where "it's all over but the shouting/crying" and I don't need to see any more.

So the tool vendors are listening to what I want. I also think that their choices are better for the general population (but I agree that chess programmers may not like it).

Now, those are not things I disagree with. I think hgm mentioned it earlier, too---users want to be able to adjudicate games, and there is nothing wrong with GUIs knowing how to do that. What I think is wrong is GUIs that contain logic for playing the games (choosing opening book moves, etc). That logic belongs in the engine. If you have it in the engine, you don't need it in the GUI. If you *don't* have it in the engine, then you've crippled your engine unless it is used with this particular GUI. Far better to put that logic where it belongs: in the engine, not the GUI.

I think there's nothing wrong with GUIs knowing how to adjudicate drawn or almost-certainly-lost games, though. I also think there's nothing wrong with GUIs helping users to analyse positions, or suggest book moves or tablebase solutions when the users want them to. Meta-analysis of an ongoing game seems perfectly fine, as long as it doesn't affect the game itself. I just think the engine should have to play the game without relying on hints or other assistance from the GUI. Anything the engine needs to know (tablebase lookups, book evaluations, etc.) should have been built into it, so that it can be used without the GUI and still be fully effective.

An engine which can't play openings or endings when disconnected from its GUI seems ridiculous to me. Why would you take a problem (playing chess) which doesn't require a GUI *at all*, and build a solution for most of it in a command-line application, and build a *separate* GUI application that talks to it, and then put critical parts of the overall solution into the GUI part? That just makes no sense to me.

Anyway, I've probably said more than enough on this topic (which you can probably tell, I feel strongly about).

I hope I haven't offended anybody too much. I respect everybody's right to do things the way they want to, even if its a clumsy and wrong-headed way!

[Dann Corbit]

When I do a chess tournament, I want to end the game as a draw if both engines have tablebase files and we are in a drawn position. I think it is positively stupid to bluff on for another four hours and a total waste of my computer time.

I want to say the game is over if some engine is down 6 pawns or more for 3 moves in a row. It is true that some engines might come back if given enough time and even that I would miss a brilliancy because of my impatience. But I want it to do what I want it to do, whether the programmer likes it or not. I want to get my hands on the data, and I don't want to wait one second longer than I have to to get it.

Now, a chess program author may be strongly at odds with this. They may hope that the other program has a bug in it's tablebase handling code and therefore might lose or might lose on time. But that would be bad to me, because I want to know about something that is formally proven a draw and I do not want to continue pounding away on that particular data point because I am done with it.
The chess programmer may abhor the 1/10000th of a point they will lose because some tournament manger declares a loss after both engines agree that one side is down 600 centipawns for 3 consecutive moves. But this is another case where "it's all over but the shouting/crying" and I don't need to see any more.

So the tool vendors are listening to what I want. I also think that their choices are better for the general population (but I agree that chess programmers may not like it).

Now, those are not things I disagree with. I think hgm mentioned it earlier, too---users want to be able to adjudicate games, and there is nothing wrong with GUIs knowing how to do that. What I think is wrong is GUIs that contain logic for playing the games (choosing opening book moves, etc). That logic belongs in the engine. If you have it in the engine, you don't need it in the GUI. If you *don't* have it in the engine, then you've crippled your engine unless it is used with this particular GUI. Far better to put that logic where it belongs: in the engine, not the GUI.

I think there's nothing wrong with GUIs knowing how to adjudicate drawn or almost-certainly-lost games, though. I also think there's nothing wrong with GUIs helping users to analyse positions, or suggest book moves or tablebase solutions when the users want them to. Meta-analysis of an ongoing game seems perfectly fine, as long as it doesn't affect the game itself. I just think the engine should have to play the game without relying on hints or other assistance from the GUI. Anything the engine needs to know (tablebase lookups, book evaluations, etc.) should have been built into it, so that it can be used without the GUI and still be fully effective.

An engine which can't play openings or endings when disconnected from its GUI seems ridiculous to me. Why would you take a problem (playing chess) which doesn't require a GUI *at all*, and build a solution for most of it in a command-line application, and build a *separate* GUI application that talks to it, and then put critical parts of the overall solution into the GUI part? That just makes no sense to me.

Anyway, I've probably said more than enough on this topic (which you can probably tell, I feel strongly about).

I hope I haven't offended anybody too much. I respect everybody's right to do things the way they want to, even if its a clumsy and wrong-headed way!

I would like the GUI to be able to set up one consistent opening book for all engines if that is what I want to perform for a particular contest.

Consider (for instance) thematic tournaments. I {for example} have caught the unfortunate "I love the orangutan" disease. I have therfore run hundreds of computer/computer orangutan games. Now, sensible engines know not to touch that opening with a ten foot pole. But my dire need to see that evil monkey causes me to wrench control away from them and tell them do do my bidding!

[CThinker]

I think the burning question here is:
"Better for who?"

Now, that introduces another question:
"Who am I building this engine for?"

If the answer is "Myself" and you are the only intended customer, then it does not matter how difficult it is to get it to do things that other customers would want because they are irrelevant. Such is the case for private engines, for instance.

As I see it, there are two chess interfaces which are the most friendly to the customer:
Shredder and ChessAssistant.
Furthermore, both of these companies listen to the customers and follow their feedback and incorporate customer demands into their tool sets.

I don't think that we see these features by accident. They are the features that the customer wants.

If the benchmark is customer base, then I think both Shredder and ChessAssistant pale in comparison to ChessMaster as far as being friendly to customers.

And, as far as GUI vs Engine separation goes, ChessMaster is engineered better. The ChessMaster GUI runs engines by giving them full autonomy. There is a clear delineation between GUI (display) and engine (game logic).

I, as a programmer, am happy with this design, and the ChessMaster users out there are happy with what they get.

So there you go. Friendly to customers, and friendly to programmers.

And since you have mentioned your number 1 software development rule, please allow me to mention one that is also important: "Modelling the real world as closely as possible".

In the human world, you have the wooden board/pieces (dumb display), and you have the human players (game logic). You model that with a GUI and engines.

That is something you can explain even to the most non-technical chess player. Changing the engine is equivalent to changing your human opponent. That to me is better than having to explain that you are not really changing your opponent, just portions of it, because some chess logic is actually on the GUI (the wooden board; shock).

ChessMaster is really very good at this. They associate the engine personalities with well-known human players. And users get that. There is the wooden chess board (which in CM looks like real 3D wooden board), and then there is this choice of engine personalities.

Again, I agree with making customers happy. I also believe that it can be done without sacrificing good engineering designs.

[Dann Corbit]

I think the burning question here is:
"Better for who?"

Now, that introduces another question:
"Who am I building this engine for?"

If the answer is "Myself" and you are the only intended customer, then it does not matter how difficult it is to get it to do things that other customers would want because they are irrelevant. Such is the case for private engines, for instance.

As I see it, there are two chess interfaces which are the most friendly to the customer:
Shredder and ChessAssistant.
Furthermore, both of these companies listen to the customers and follow their feedback and incorporate customer demands into their tool sets.

I don't think that we see these features by accident. They are the features that the customer wants.

If the benchmark is customer base, then I think both Shredder and ChessAssistant pale in comparison to ChessMaster as far as being friendly to customers.

And, as far as GUI vs Engine separation goes, ChessMaster is engineered better. The ChessMaster GUI runs engines by giving them full autonomy. There is a clear delineation between GUI (display) and engine (game logic).

I, as a programmer, am happy with this design, and the ChessMaster users out there are happy with what they get.

So there you go. Friendly to customers, and friendly to programmers.

And since you have mentioned your number 1 software development rule, please allow me to mention one that is also important: "Modelling the real world as closely as possible".

In the human world, you have the wooden board/pieces (dumb display), and you have the human players (game logic). You model that with a GUI and engines.

That is something you can explain even to the most non-technical chess player. Changing the engine is equivalent to changing your human opponent. That to me is better than having to explain that you are not really changing your opponent, just portions of it, because some chess logic is actually on the GUI (the wooden board; shock).

ChessMaster is really very good at this. They associate the engine personalities with well-known human players. And users get that. There is the wooden chess board (which in CM looks like real 3D wooden board), and then there is this choice of engine personalities.

Again, I agree with making customers happy. I also believe that it can be done without sacrificing good engineering designs.

I am looking at the "Import Winboard Engine" dialog right now.
It has the options:

[x] Use Chessmaster Opening Book
Book Name:
[Select]

Winboard Engine Filename
___________________________
[Browse]

Command Line Parameters
___________________________

[] Pondering [x] Use Endgame Databases

Pressing the select button gives me a jillion opening books to select from

So it seems that ChessMaster does listen to their target audience.

[CThinker]

I think the burning question here is:
"Better for who?"

Now, that introduces another question:
"Who am I building this engine for?"

If the answer is "Myself" and you are the only intended customer, then it does not matter how difficult it is to get it to do things that other customers would want because they are irrelevant. Such is the case for private engines, for instance.

As I see it, there are two chess interfaces which are the most friendly to the customer:
Shredder and ChessAssistant.
Furthermore, both of these companies listen to the customers and follow their feedback and incorporate customer demands into their tool sets.

I don't think that we see these features by accident. They are the features that the customer wants.

If the benchmark is customer base, then I think both Shredder and ChessAssistant pale in comparison to ChessMaster as far as being friendly to customers.

And, as far as GUI vs Engine separation goes, ChessMaster is engineered better. The ChessMaster GUI runs engines by giving them full autonomy. There is a clear delineation between GUI (display) and engine (game logic).

I, as a programmer, am happy with this design, and the ChessMaster users out there are happy with what they get.

So there you go. Friendly to customers, and friendly to programmers.

And since you have mentioned your number 1 software development rule, please allow me to mention one that is also important: "Modelling the real world as closely as possible".

In the human world, you have the wooden board/pieces (dumb display), and you have the human players (game logic). You model that with a GUI and engines.

That is something you can explain even to the most non-technical chess player. Changing the engine is equivalent to changing your human opponent. That to me is better than having to explain that you are not really changing your opponent, just portions of it, because some chess logic is actually on the GUI (the wooden board; shock).

ChessMaster is really very good at this. They associate the engine personalities with well-known human players. And users get that. There is the wooden chess board (which in CM looks like real 3D wooden board), and then there is this choice of engine personalities.

Again, I agree with making customers happy. I also believe that it can be done without sacrificing good engineering designs.

I am looking at the "Import Winboard Engine" dialog right now.
It has the options:

[x] Use Chessmaster Opening Book
Book Name:
[Select]

Winboard Engine Filename
___________________________
[Browse]

Command Line Parameters
___________________________

[] Pondering [x] Use Endgame Databases

Pressing the select button gives me a jillion opening books to select from

So it seems that ChessMaster does listen to their target audience.

Shredder has the same set of options engines. But you think that Shredder listened to the customer, while ChessMaster did not?

I have to disagree on this one. For me, as far as UI is concerned, the Shredder UI is a disorganized mess compared to ChessMaster.

In fact, you won't find non-valid words in the ChessMaster dialogs. In contrast, you find things like "PosLearning" (that's one word) in Shredder. What exactly is that? A misspelling of "Post Learning"?

You can tell that the Shredder UI was designed by a programmer and not a User Experience person. The Shredder menu has 'Command', while the ChessMaster menu has 'Action'. There is no real organization in the Shredder menu, so you get 'Extras' for the bunch of unrelated items. Here is an example of real-world modeling in ChessMaster: you see menu items like, Mentor, Move Advice, Chess Coach. In contrast, Shredder has all sorts of words that are hard to relate to human chess (like, Tripple Brain, Histogram).

I'm guessing that Shredder does not have a dedicated UE team, like you have in big software companies (UbiSoft). And that shows in the quality of the UI.

Cheers...