Re: [Gnushogi-devel] gnushogi xboard support

[h . g . muller]

Op Wo, 23 oktober, 2013 10:40 pm schreef Yann Dirson:

> I'd say using a default search path, which may include several dirs
> including ".", when there is no "/" in the name, and if there is one just
> look for a relative path, would be OK.

Well, that i basically what I have done now: first search ".", then search
$(datadir)/games/xboard/themes/conf . I could extend that to searching
~/.xboard in between, if you think that is useful. (I don't know if there
is any Debian standard for where applications should store user-specific
settings.)
>
> Could be good as well - even better would be providing bash/zsh
> completion scripts to propose those settings.
>
I have no idea how that would work. You should realize my Linux knowledge
is limited, and I almost exclusively use Windows myself. On Cygwin I
basically only use gcc, make, grep and ed.
>
> Hm, while "@shogi @mini" is shomething that some people could get used
> to, you'd have to expect the "@mini @shogi" mistake to be a common one, and
> "@chu @sho" is not very intuitive either.  What about causing
> minishogi.ini to start with @shogi, and similar for sho ?

Because apart from an almost negligible number of die hards, I really
don't expect that anyone would want to play mini-Shogi with kanji pieces.
(Just to put this in perspective: the Dutch Shogi Association has 36
members in a country of 17 million, and most of those would not be
interested in mini-Shogi.) So most players that would play mini-Shogi
through XBoard would be Chess players curious to try what the other
variants would do, and using @shogi would immediately turn them away.

But this is just a temporary problem anyway. The need for @mini would go
away if the engine supporting it would use "mini" as engine-defined
variant in its variants feature, and send a setup command in response to
"variant mini" that provides the information now supplied by @mini.

Perhaps I should make XBoard such that if the engine does explicitly say
it does not support variant normal, by sending a variants feature that
omits it from the list, it should automatically switch to a variant that
it does play? I cannot quickly think of an argument against that. It
certainly seems better than exiting XBoard with a fatal error, as it would
now. If the user explicitly specified a -variant in the command line, it
is a different matter, because it is more likely he erred in the engine
than in the variant. Could be, though, that there are many Chess engines
that (non-compliantly) leave out "normal" from the variants list when they
only play normal + fischerandom. But I could make an exception for that
(justified by the fact that normal i in fact just one of the Chess960
initial positions). Then "xboard -fcp gnushogi" would automatically switch
to -variant shogi. And if mini-Shogi would be played by the same binary,
it would appear in the menu, and people could select it from there.

> Btw, I'm not
> sure using just "sho" and "chu" for names is a good idea, few people will
> understand before looking, that they are shogi variants.

Actually the problem seems bigger than that. How would they even know that
these files existed? They won't go to /usr/hare/games/xboard/themes/conf
to give it a good look, and no one ever reads manuals. Wondering what they
do seems a minor problem compared to that. I am sure that people who do no
Chu Shogi would immediately realize what 'chu' means. And if they don't,
they probably won't care whether it is a shogi variant or makruk.

> Nothing's impossible, and I guess that one is not so hard.  Basically
> lots of global constants to move under the umbrella of a single struct, to
> be exchanged at will to change the variant.
>
> * availability of lance and knight are easy to turn dynamic, kinda
> replace some ifndefs with if (game->has_knight); those [NO_PIECES] arrays
> will need some thought, but once for all; once for loops on piecetype
> index too; a number of #ifdef that are just here because those pieces were
> suppressed for simplicity, will just vanish

There should be no need for explicitly removing those pieces from the
program. I don't do that in Shokidoki either. It just starts from an
initial position where they are not on the board or in the hand, and they
won't ever appear from out of nothing. (In Chess they could, when a Pawn
promotes!)

>
> * board-size changes are easy too, some hardcoded strings could even
> be generated, some silly ones like direc and max_steps *should have* been
> generated in the beginning; many static arrays to calloc instead

In Shokidoki I don't really change the size of the board, but just use a
smaller part of it. I used a board with a rim of 'edge guards' around it
that made off-board squares inaccessible, and just put two more rings of
edge guards inside the 9x9 area. Note that this also gets the promotion
zone right for mini-Shogi. I don't know if a similar thing could be done
with GNU Shogi; I never looked at its data structures.

> I have read about Judkins Shogi on wikipedia, but forgot since then.
> Yes, looks pretty straightforward to add now, but I'd prefer to wait
> until runtime selection is there :)

Sure, this is something for later. Judkins Shogi is not very popular in
Japan anyway. (Judkins was not Japanese...)

> "quit" is important too.  With well-behaved engines should there
> should never be a need for kill() :)
>
Well, the unfortunate practice is that many engines are not well-behaved,
and GUIs have to deal with that to remain useful. :-(

H.G.