Comments by rescharn

Thank you, Harm, for your explanations. Concerning X-FEN I would prefer to
have piece letters being unique and compatible to nearly established
Archbishop and Chancellor. I do not want to change used letters with the
variants playing them.

Smirf unfortunately cannot be extended to handle all those four super
pieces because of its piece codes' bit encoding their properies. But in
Octopus there will be a more flexible bit encoding, so that a lot more of
gait combinations might be possible in Octopus, e.g.: Q+N, K+N, K+B, K+R.

When I read Superchess documents correctly, a promotion to Q+N is not
permitted. The union of all usable pieces seems to be constant, thus it
might be unnecessary to have the unused pieces listed seperately inside of
an X-FEN. Nevertheless it is not obvious, that it would be a notation from
Superchess. To have a unique X-FEN method I intend to do following:
instead of a []-list of captured pieces (which I am not yet able to
support, but maybe later ...) there could be an optional separated tag '
:' followed directly by forbidden pieces' symbols (if any). By default
at 8x8 NBRQ and at 10x8 NBRACQ are promotable pieces. For e.g. Janus Chess
thus ' :C' would symbolize, that a Chancellor would not be allowed to be
selected for promotion in this situation. Extending this to Superchess'
piece set there could be a representing symbol '*'. So ':*G' could
symbolize that any available castling piece has to be selected within the
unused super pieces set and that the (G = Giant) Q+N piece is not allowed
to be promoted in.

Well, Harm, I intend to seperate the variant depending renaming of piece
types from FEN, because this should be a feature of the GUI and maybe
become customizable at least. It might be accompanied by a commenting PGN
token like: [Variant='Janus Chess, J:=A']. That would give to it an
importance like a kind of comment. But the X-FEN as a communication
vehicle for engines should use merely unified and thus constant piece
letters. This should also be true for move notations (in PGN / Algebraic),
where protocols e.g. like UCI demand for one-char-letter piece symbols.

Of course this approach is not at all able to cover all piece types. But
that goal would need a much bigger approach than what I intend this
moment. (Octopus would not be able to cover every piece type, too.) And a
later extension e.g. done as proposed in your posting would not at all be
made impossible by my idea. But it would be a simple and compatible ad hoc
extension into the right direction.

Promoting possibilities should not differ through different incarnations
of the same piece type. Thus having pawns with different promotion
abilities does not make sense to me. Thus it has to be related to a given
board situation in total.

Indeed, I am always trying to separate variant- and piece naming from FEN
representation. In SMIRF I made a first approach to that using X-FEN as
published. But including Janus or Optimized Chess produced a lot of
encoding problems, just by having different piece type letters. I learned,
that this was an unnecessary complication, which should be avoided. Think
on different piece names and abbreviating letters in different countries
for traditional chess. Those are part of the PRESENTATION of the game,
thus belonging to the GUI. Piece letters on the surface simply are a
comment to the underlying pieces, thus not being absolute. But a
calculating engine has no need to communicate multi language wise, it
simply has to use well introduced unique international (english) letters
PNBRQK. That is, why I have not yet included SMIRF's current
representation of Janus or Optimized Chess into the X-FEN concept, because
that has been the wrong approach. X-FEN has to be extended to include a lot
of variants in a generic and universal way. Variant names are only
comments, even though I know, that Winboard handles it as a definition.
But have a look at Chess, Chess960 and castlingless random chess. Having
X-FEN will cover all of them doubtlessly, thus avoiding any need to
explain more than X-FEN to fully describe a position. Chess960 as a
variant title then therefore merely is a comment. A lot of variants
include each other, e.g. think of CRC. Sometimes it is not to be decided
to which variant a position belongs, and there is in fact no need to.
Moreover this would not make any sense, as in Shredder FEN that is
creating confusion encoding identical positions by different FEN strings.
All Chess positions e.g. could be regarded as Chess960 positions.

It is not my intention to represent every variant position by X-FEN. I
would be happy to cover a lot of variants having gait combinations in
their pieces strongly related to traditional chess. Maybe you noticed
SMIRF naming itself a FullChess engine. SMIRF does it covering dual
combinations of N, B and R. Coming Octopus is intended to cover some
additional combinations, too. 

FEN stems from traditional Chess. Thus I am convinced that using X-FEN
makes sense the more the variants it supports would be related to chess.
My X-FEN approach therefore is not thought to be a base for Zillion
positions. 

As long as X-FEN belongs to that idea, the handling of variant names and
pieces names as a kind of comment will work best. Thus I will remain in
the neighbourhood of Chess.

Harm, FullChess games have moves defined by TWO seperatedly to be clicked
squares. Those fields are encoded within the algebraic move encoding sent
by the engine before. In doubt, e.g. at promotings, the GUI is prompting
possible moves to be selected by the user. After any move the engine is
sending the current X-FEN position to be interpreted and displayed by the
SMIRF GUI. The GUI is absolutely unable to generate any Chess move by
itself or to modify the board position by its own means.

Go is defining its moves by exactly ONE to be clicked square. Thus Go
belongs to a different family of board games, for which a similar approach
would be possible.

to a): there seems to be no need for a special swap move. Instead move the King / Queen to the Bishop of opposite colour, which seems to be an impossible exchange, which should be skipped then. 

Initial exchange moves (of traditional sequence: White starts) could be integrated into traditional game notations by starting a game at a negative move count (here e.g. -2 half moves), supplied by an appropriate FEN. But I am not yet convinced that an intended relocation would be better than a randomized one.

Omar: thank you very much for your reaction here!

To 'Also please see the Arimaa Public License: http://arimaa.com/arimaa/license/ ': well, I am not a native English speaker, as a lot of chess and variants programmers would not be, too. Thus I do not understand every implication of the license's details. If those rules would be valid also e.g. for the country of Germany, where I am living in, it would be fine to have a German language translation at hands. This is, because I am not a lawyer, and I had experienced a lot of difficulties around an unspeakable 10x8 chess variant targeting a bunch of priorly very interested people.

To: 'For personal, educational and research use, Arimaa is freely available.': I occasionally used to publish my (still amateur level) combined 8x8 and 10x8 chess multi variant engine SMIRF and GUI at my homesite http://www.chessbox.de/Compu/schachsmirf_e.html, very rarely from time to time gathering by it some voluntary donations to support that programming work, which needs casually to be enhanced e.g. buying some updates of development tools. 

Within SMIRF I therefore had to disable that unspeakable 10x8 variant to prevent it from general use. Moreover nevertheless I always regarded myself to be only a small step away from jail. Such feelings are not of that kind, which might increase motivation and creativity to deepen an understanding especially of patented variants. It seems, that there would be no chance to legally publish any Arimaa® enabled program or GUI at a personal web site, so why should I start an Arimaa® development at all, when only earning of trouble seems to be certain already e.g. by giving away some program copies mainly for testing purposes?

SMIRF is no longer available. People enjoy playing clone programs.
Multivariant engines are out of focus. Maybe situation will be changing
after some years ...