Check out Glinski's Hexagonal Chess, our featured variant for May, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Single Comment

[Subject Thread] [Add Response]
H. G. Muller wrote on Fri, Apr 3, 2009 09:48 AM UTC:
The WinBoard move parser actually does accept a very wide range of move
notations, and Xa1-b2 is one of those. This is fine in 'perfect' Chess
variants like Shatranj, Xiangqi, and Shogi, where the only capture is
replacement capture, and moves never have side effects. But in FIDE Chess
there ae already problems with castling and e.p. capture: somewhere along
the line from PGN to display it should be known that Ke1-g1 means that a
Rook should be moved as well, and that on e5xf6 a Pawn should be removed
from f5.

In the ChessLive! viewer I solved those problems by recording such moves
in the intermediate format as multiple move: in general a move can consist
of multiple (fromSquare,toSquare) pairs, and for 0-0 I write, say,
e1g1h1f1, and for e5xf6 e.p. I write e5f5f5f6 (or f5f6e5e6). This can keep
the viewer totally dumb.

But you can't expect that information to be present in the original PGN.
it seems that you have a different concept of PGN from what it really is
already: you would not find a move like Xa1-b2 in any PGN file, as PGN is
supposed to use Standard Algebraic Notation (SAN), which would list the
move as Xb2. Or, if there are multiple X on the board that could move to
b2, like (preferably) Xab2 or X1b2. I guess in theory Xa1b2 could occur, if
there are three pieces of type X, located on the intersections of two files
and two ranks (e.g. Na1, Nc1, Na5) that could all go to the same square
(b3). So it could occur even in FIDE Chess. But I have never seen it
happen. So in SAN normally a full specification of the from-square is
absent, even if the instance gnerating the SAN is totally unaware of how
the pieces move, so that it has to add a disambiguating rank or file
indicator for every move with a piece of which there are multiple copies on
the board. This puts the burden on the SAN parser to keep track of the
board state, so that it knows where each piece of a given type is located.

Anyway, the sitution in WinBoard is that it currently supports 22
different piece types (for both black and white), that you can assign any
letter to. If you switch legality testing off, the pieces can move any way
you want. (With legality testing on, it has a pre-programmed notion of how
every piece should move.) Each piece has a standard pictogram
representation on the screen, but this can be overruled as well by
user-provided graphics. Board size is adjustable, but in practice the SAN
parser does not work beyond 12x10 yet (e.g. it does not understand
double-digit rank indicators).

PGN defines a variant tag (e.g. [Variant 'xiangqi']). The WinBoard
convention for variant naming is such that you can use non-standard board
sizes by prefixing them to the variant name, and that a catchall name
'fairy' is defined, where every piece can partcipate. So you could
specify 6x6_fairy for a mini-variant on a 6x6 board including Elephants and
Achbishops, or even 6x6+4_fairy if it was a Shogi-like variant with piece
drops and holdings for 4 piece types.