Enter Your Reply

I think we should clearly separate communication needs from storage needs.
PGN as it exists is a great standard for Chess variants for storing games.
And indeed it is what WinBoad uses. But the current standard heavily leans
on Standard Algebraic Notation (SAN) for the moves. And SAN is designed to
be convenient in games with many different pieces, so that the combination
(Piece, ToSquare) hardly ever needs disambiguation. SAN has the
disadvantage that it is non-trivial to parse, and the semantics can only
be extracted in the context of the current position. This forces all
entities converting SAN to an explicit move to keep track of game state.

All this is a consequence of SAN being designed for use by Humans. For
communication between computers, Chess moves are much more efficiently
encoded as (FromSquare, ToSquare), and indeed this is what WinBoard
protocol does. For games like Checkers, where all pieces are identical,
this is more convenient than SAN anyway. Side efects in Chess are rare,
(limited to castling and e.p. capture), and fortunately the moves with
side effects can be recognized from the base move of Pawn or King. In
Chess960 castling this is not always true, and castlings need a
conventional, rather than descriptive, notation. Next to the O-O and
O-O-O, the King-captures-own-Rook convenstion can be used for this. But
all these trcks critically depends on the communicating entities having
knowledge about the variant, so that when they encounter a Pawn capture to
an empty square, or a double sideway King step, or a King that captures its
own Rook, they do not take the move at face value, but know what is meant
by it. Furthermore, for Humans, (FromSquare,ToSquare) is more difficult to
read than SAN.

If you want to have a system of describing moves that would work for any
variant, you cannot rely on the communicating entities to recognize moves
that imply side effects. There is no limit to the number of cells that
change state, there is no conservation law on the number of pieces on the
board. You ould have to spell out everything. e.g. in Go you would have to
tell which stones have to be removed, although this is fully implied by the
drop coordinates. But there might be Go varints where not all these stones
re removed, and where the mover has to chose a subset of those. So the
move format will have to be able to specify this. This makes the format
too cumbersome to use for Humans, who prefer compactness rather than
explicit mentioning of side-effects that were already fully implied.

In my Live Chess-Game Viewer (see
http://home.hccnet.nl/h.g.muller/goths.html for a short demo) I opted for
a completely dumb system. The JavaScript code that manages the page nows
nothing about chess, and interprets the moves it fetches from the server
as simple cut/paste instructions which copy the contents of one square to
another and then make the source square empty. Which is quite efficient,
because it is exactly what the archetypal Chess move does. The viewer does
not even care who's turn it is. But to make sure that castlings, e.p.
captures and promotions can be viewed, the entity sending the moves must
slip in extra moves for the side effects. So an e.p. capture is
transmitted as two steps, e.g. e4-f4 and f4-f5, while for castling the
Rook move has to be explicitly added. To define the promotion piece,
another move format is added.