New serialization

[nmlorg]

In addition to supporting FEN/X-FEN, I want to simplify the visual serialization format. Right now, every piece's move count is stored, which can (or at least, I believe, should) be able to be used to support both en passant and castling availability (as well as calculating the fullmove number). However—inspired by FEN—I would like to simplify this to just storing explicit en passant and castling information. Rather than storing them separately from the board, however, I'm thinking I might be able to introduce two new characters, so an en passant move can be represented by perhaps x and a castle-able rook can perhaps be represented by c/C. The standard starting layout would change from:

r n b q k b n r
p p p p p p p p
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
P P P P P P P P
R N B Q K B N R

to:

c n b q k b n c
p p p p p p p p
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
P P P P P P P P
C N B Q K B N C

and the move 1.a4 would change from:

r  n  b  q  k  b  n  r
p  p  p  p  p  p  p  p
.  .  .  .  .  .  .  .
.  .  .  .  .  .  .  .
P1 .  .  .  .  .  .  .
.  .  .  .  .  .  .  .
.  P  P  P  P  P  P  P
R  N  B  Q  K  B  N  R

to:

c n b q k b n c
p p p p p p p p
. . . . . . . .
. . . . . . . .
P . . . . . . .
x . . . . . . .
. P P P P P P P
C N B Q K B N C

(so, among other things, the exact dimensions of the grid will always be the same/there will always be one space between pieces).

The game 1.a4 a5 2.a2 a7 3.a1 a8 would be:

c n b q k b n c    c n b q k b n c    c n b q k b n c    . n b q k b n c    . n b q k b n c    r n b q k b n c
p p p p p p p p    . p p p p p p p    . p p p p p p p    r p p p p p p p    r p p p p p p p    . p p p p p p p
. . . . . . . .    x . . . . . . .    . . . . . . . .    . . . . . . . .    . . . . . . . .    . . . . . . . .
. . . . . . . .    p . . . . . . .    p . . . . . . .    p . . . . . . .    p . . . . . . .    p . . . . . . .
P . . . . . . .    P . . . . . . .    P . . . . . . .    P . . . . . . .    P . . . . . . .    P . . . . . . .
x . . . . . . .    . . . . . . . .    . . . . . . . .    . . . . . . . .    . . . . . . . .    . . . . . . . .
. P P P P P P P    . P P P P P P P    R P P P P P P P    R P P P P P P P    . P P P P P P P    . P P P P P P P
C N B Q K B N C    C N B Q K B N C    . N B Q K B N C    . N B Q K B N C    R N B Q K B N C    R N B Q K B N C

(showing that, even though the queen-side rooks are [back] in their castle-able positions, they've lost their castle-ability).

Note that if the king moves it can no longer castle (and so neither can either of its rooks). I would like to keep castle-ability strictly relative to the rook, but that would require marking it on the king somehow. I considered using a separate marker, showing either castle-ability or castle-inability, like Rc N  B  Q  Kc B  N  Rc, but I thought it would be tedious to keep using the marker either from the very beginning or once either a king or rook had moved.

This also would make the board not strictly serializable using Unicode characters (there is no code point for a castle-able rook, nor an en passant space; however, there are symbols for things like U+1FA0B WHITE CHESS ROOK ROTATED NINETY DEGREES that could represent "tapped" pieces).

Also note that pawns promoted to rooks would start off castle-unable.

I am not sure if/how to represent the fullmove or halfmove numbers. It might end up making the most sense to keep these as attributes of a Game rather than a Board (so exporting/importing using FEN would be implemented by the Game object), since they don't actually affect what moves are valid from a given board layout.