To GUI developers and Linux engine packagers

[gbtami]

In PyChess we use a mixed approach. Auto detect some (hard coded list of) known engines, plus users can add/remove engines in the Edit->Engines dialog.
As I see 99% of existing chess engines has no distro packages at all. So this proposal doesn't help too much solving how GUI clients discover engines IMO.

[kbhearn]

Something related to installing applications in KDE/gnome (don't know if it applies to other desktop environments) :

http://standards.freedesktop.org/deskto ... atest.html

It's used primarily for generating menus and registering applications so they can be used for file association, but it seems like it could be applicable to what you want to do. The engine would install a .desktop file in /usr/share/applications (or equivalent directory based on distribution).

"Implements=..." would include appropriate string(s) for the protocols they implement. This might be a challenge if the protocols do not have associated domains at the moment as the naming standard uses them to ensure a lack of naming conflicts. It's recommended but not required these be d-bus interfaces, i think an engine protocol would be fine though.

"NoDisplay=true" would prevent the engine from getting a menu item in the desktop environment

A gui could then just check each .desktop file for the appropriate implement strings that it's interested in.

[hgm]

In PyChess we use a mixed approach. Auto detect some (hard coded list of) known engines, plus users can add/remove engines in the Edit->Engines dialog.
As I see 99% of existing chess engines has no distro packages at all. So this proposal doesn't help too much solving how GUI clients discover engines IMO.

Such a mixed approach is certainly the way to go. At all times it must remain possible to install unknown or non-standard engines.

What I propose is just to extend the detection of known engines with the detection of unknown, but compliant engines. If people hide unknown engines in non-standard places, there is very little one can do.

I think that at this point we should not worry about the fraction of engines that is packaged. I am sure this will go up as time passes. Linux is on the rise, engine authors are starting to pay attention to its existence, and supply Linux versions of engines even if they developed it on Windows. I think 99% is an exaggeration anyway; there aren't more than 1000 engines, and I am pretty sure there must more than 10 engine packages.

If there is a good reason to make a real engine package, rather than just providing a tar ball of the executable, (like that it is automatically insatlled and will display a logo with it in most GUIs), I am sure this would provide an incentive for people to do it. It doesn't have to be the original authors. Other people could jump in as maintainers to create large number of Debian packages complete with logos, and host them on their websites. It isn't very difficult, and once you know how to make one, you can make hundreds with almost no effort.

And finally, when developing standards, it is wise to stay ahead of the developments, rather than trailing behind them. If all engines would already have been available in packages, people might be reluctant to redo the work to comply with a standard that came later.

So I do hope that PyChess also wants to consider extending the automatic install to unknown engines that comply with an auto-install standard, if we can agree on one here.

[hgm]

A gui could then just check each .desktop file for the appropriate implement strings that it's interested in.

Yes, I am aware of the .desktop format (we supply some desktop files with XBoard). But it strikes me more as a GUI thing, defining the icon to be displayed for it, and the name that should be displayed with that in many languages, whether a terminal should be opened on starting the program, etc. So it is very much tailored to desktop managers.

If we were to use it for engines, my guess is that we would need to extend the standard for the things it can specify a lot, to really get an advanced system (which would also list known common protocol non-compliancies of the engine, etc., so a GUI could specify work-around options for those with the engine, if it has such options available).

[gbtami]

So I do hope that PyChess also wants to consider extending the automatic install to unknown engines that comply with an auto-install standard, if we can agree on one here.

PyChess will implement this standard for sure. I'm just a bit pessimistic about engine packagers side.

[hgm]

I put the following code I am going to use in XBoard to perform the auto-install in the public domain:

Code: Select all

#include <dirent.h>
#include <sys/stat.h>

static void
InstallFromDir &#40;char *dirName, char *protocol, char *settingsFile&#41;
&#123;   // scan system for new plugin specs in given directory
    DIR *dir;
    struct dirent *dp;
    struct stat statBuf;
    time_t lastSaved = 0;
    char buf&#91;1024&#93;, *p;

    if&#40;!stat&#40;settingsFile, &statBuf&#41;) lastSaved = statBuf.st_mtime;
    snprintf&#40;buf, 1024, "%s/%s", dirName, protocol&#41;;

    if&#40;!&#40;dir = opendir&#40;buf&#41;)) return;
    while&#40; &#40;dp = readdir&#40;dir&#41;)) &#123;
        time_t installed = 0;
        if&#40;!strstr&#40;dp->d_name, ".eng")) continue; // to suppress . and ..
        snprintf&#40;buf, 1024, "%s/%s/%s", dirName, protocol, dp->d_name&#41;;
        if&#40;!stat&#40;buf, &statBuf&#41;) installed = statBuf.st_mtime;
        if&#40;lastSaved == 0 || &#40;int&#41; &#40;installed - lastSaved&#41; > 0&#41; &#123; // first time we see it
            FILE *f = fopen&#40;buf, "r");
            if&#40;f&#41; &#123; // read the plugin-specs
                char engineCommand&#91;1024&#93;, engineDir&#91;1024&#93;, variants&#91;1024&#93;;
                char bad=0, dummy, *engineCom = engineCommand;
                int major, minor;
                if&#40;fscanf&#40;f, "plugin spec %d.%d%c", &major, &minor, &dummy&#41; != 3 ||
                   fscanf&#40;f, "%&#91;^\n&#93;%c", engineCommand, &dummy&#41; != 2 ||
                   fscanf&#40;f, "%&#91;^\n&#93;%c", variants, &dummy&#41; != 2&#41; bad = 1;
                fclose&#40;f&#41;;
                if&#40;bad&#41; continue;
                // uncomment following two lines for chess-only installs
//              if&#40;!&#40;p = strstr&#40;variants, "chess")) ||
//                   p != variants && p&#91;-1&#93; != ',' || p&#91;5&#93; && p&#91;5&#93; != ',') continue;
                // split off engine working directory &#40;if any&#41;
                strcpy&#40;engineDir, "");
                if&#40;sscanf&#40;engineCommand, "cd %&#91;^;&#93;;%c", engineDir, &dummy&#41; == 2&#41;
                    engineCom = engineCommand + strlen&#40;engineDir&#41; + 4;
                InstallNewEngine&#40;engineCom, engineDir, variants, protocol&#41;;
            &#125;
        &#125;
    &#125;
    closedir&#40;dir&#41;;
&#125;

static void
AutoInstallProtocol &#40;char *settingsFile, char *protocol&#41;
&#123;   // install new engines for given protocol &#40;both from package and source&#41;
    InstallFromDir&#40;"/usr/local/share/games/plugins", protocol, settingsFile&#41;;
    InstallFromDir&#40;"/usr/share/games/plugins", protocol, settingsFile&#41;;
&#125;

void
AutoInstall &#40;char *settingsFile&#41;
&#123;   // install all new XBoard and UCI engines
    AutoInstallProtocol&#40;settingsFile, "xboard");
    AutoInstallProtocol&#40;settingsFile, "uci");
&#125;

[hgm]

After some thinking on how to extend this standard further, I decided that it would probably be best not to name each and every variant that the engine supports specifically, but instead group the rarer variants that are similar in spirit into groups with commonly accepted names. So rather than mentioning Knightmate, Spartan Chess, Nightrider Chess all separately, there will be just one category 'fairychess', which will be mentioned when the engine plays any of these. And in stead of Chu Shogi, Tori Shogi, mini-Shogi, Maka Dai Dai Shogi etc. there will be just one category 'shogivariants'. Variants like Losers, Suicide, Giveaway would all fall under 'antichess'. If a GUI would want to know which variants an engine plays exactly, it can just start up the engine, and look to the features/options it reports.

For the variants that enjoy above-average popularity, there will be separate names, as it is quite likely there will be people that are interested in that, and only that variant (or game). In this case it is also more likely there exists a commonly agreed-upon name. (Although... Reversi/Othello).

So I propose the following standard names, that could be written in a comma-separated list on the third line of the plugin-spec file:

chess
chess960 (FRC)
seirawan
capablanca (all 10x8 variants employing FIDE pieces + BN and RN compounds)
fairychess
antichess (win by getting rid of material, with mandatory capture)
shatranj (historic forms like Shatranj, Courier, Tamerlane)
blindfold (incomplete information, like Kriegsspiel or DarkChess)
xiangqi
shogi
shogivariants
asean (includes Makruk, Cambodian, Makruk variants)
ultima (Baroque and Roccoco)
checkers (8x8 and variants)
draughts (10x10 and variants)
reversi
go
amazons

I am in doubt if I should make a seperate category 'asymmetricchess', where white and black have different armies, or that this is just like any other fairychess. Did I forget anything important?

[gbtami]

Wildcastle, nocastle, atomic, crazyhouse, bughouse? Telling the truth I don't see why group names are more useful than individual variant names from GUI program point of view.

[hgm]

Nocastle and wildcastle are just chess. Bughouse deserves a category of its own, being a 4-player game. I imagined Atomic, 3Check, TwoKings and even Crazyhouse to all map to the fairychess category, although I am not sure of the latter one. I did consider a category 'exoticchess', and things like Atomic and Crazyhouse would fit there quite well, I think.

Why grouping?

Well, basically to make it possible to get complete coverage with finite effort. The way I imagine this info to be used, is by XBoard (or other GUIs) supplying an option with which the user can filter what the GUI should auto-install in his engine list. If I have absolutely no interest in anything but Chess, it would be annoying to see Shogi engines appear there. So I would configure XBoard with an option -autoInstall "chess", and it would protect me from all that nonsense.

But now suppose I am interested in western Chess variants, but Asian variants are too weird for me. It would be hard to make an exhaustive listing of everything that would qualify. In particular because I would not only have to take account of standard variants supported by existing engines, but of everything that future engines might support (e.g. as engine-defined variant). OTOH, when I can configure -autoInstall "fairychess,capablanca,exoticchess,shatranj" it would serve my needs in a simple way. Newly invented variants that I am likely to be interested in would be classified by their authors in one of these categories, and the Shogi and Xiangqi stuff I purposely left out will stay away from me.

So my aim would be to pick the categories in such a way that it will be very unlikely that if I like variant X in category C, it will be very likely I like other varinats in that category too, because they are very similar in spirit. That sort of forces the orthodox games (chess, shogi, draughts) to be in a category of their own, as most people playing those are often very hostile towards any kind of heresy.

[gbtami]

In PyChess we handle this in a different way. PyChess provides automatic discovery of known engines and its supported variants, and don't expect the user to know what groups or individual variants exists at all. The user can choose any variant the GUI supports (and there is at least one engine exist and installed supporting that variant) in the GUI. When the user choose a variant to play, the GUI provides only engines which supports that variant in a dropdown. This way beginners can discover new variants they not know at all before.

Your proposal will help us to discover more engines, not just the hardwired ones, but the grouping part seems a bit ad hoc to me.