To GUI developers and Linux engine packagers

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

[hgm]

Your system is a good one for the user, but it seems a nightmare for the GUI maintainer. You would have to remain aware of every engine, and update each time there is a new one. (OK, that is probably just adding it to some list, but you would still have to update the package.) I am just way too lazy for that!

A much more tricky matter is to encode common non-compliancies, so that the GUI could use work-around options with the engine. I wanted to reserve the 4th line of the .eng file for that (and it could be dependent on the protocol). Some work-arounds I regularly use in XBoard are:

for WB protocol:
Correct the sign of the score on engines that report from white POV
Convert the PV to SAN because the engine uses long algebraic
Overrule the engine's variants feature (e.g. because it forgets to mention a variant it plays, typically "normal")
Tell the GUI it is a WB v1 engine (to prevent needless waiting for feature commands)

for UCI/USI
Delay commands after 'stop' until engine has sent 'bestmove'
Refrain from using 'isready' after the one time at startup
Use 'byoyomi' in stead of 'inc' (for USI)
Prevent use of 'searchmoves' on engines that do not support it
Force pondering, although the engine does not say it can
The engine has a Hash option, but does not report it

It might also be good to list if the engine comes with an own book.