brhfl.com

SCorCh - Simple Correspondence Chess

This is an old post from an old blog; assets may be missing, links may be broken, and my opinions may differ considerably by this point… Notably, this became FENipulator.

I've thought a lot in the past about correspondence chess, and the current state of such. There are a number of online solutions, most of them not so great. Twitter-based ChessTweets is my current favorite solution (anyone who wants a fight, @brhfl) although the constant barrage of DMs from the system does get somewhat irritating. I use the somewhat clumsy XBoard with a variety of engines for the sake of analysis, but using it for correspondence is far from ideal. This task seems the perfect opportunity to demonstrate that less is more, and create a CLI interface which acts as a somewhat dumb client for displaying a board and interpreting moves. While I will probably never actually code this, I hope that perhaps I will some day, and I will call it scorch for Simple Correspondence Chess.

My original plan was that the program would basically just watch a PGN file, turn it into a more easily visualized representation, take input, and append the input to the PGN file. An 'easily visualized representation' would be something like…

┌────────┐ │ KR•QB•R│ │PP• PP•P│ │ •PPBNN•│ │• • • P │ │b• •p• •│ │bpn qn• │ │p•pp ppp│ │•kr • •r│ └────────┘  hgfedcba

…with spaces representing white spaces, dots representing black spaces, uppercase letters representing white pieces, and lowercase letters representing black pieces. Those exact details, the spacing, etc. could easily be changed, but that's the general idea. So, the scenario then would be that both players would be running the piece of software. Notations like PGN and FEN are good for keeping a record, but they're not visual. You either follow along, moving pieces on a real board, or you feed the data into some software. This software would just be a very simple visualizer, essentially, which would also handle some basic I/O tasks. The file could be sent over email, or synched over something like DropBox for the sake of simplicity.

But, my friend Alex said to me, 'but I wouldn't be able to play at work,' which is certainly true, as in the above scenario both players still either need to be running the software or manipulating chess boards. At first, I thought, 'who cares?' but then I mulled over it while showering, and I realized that I do care. Solving that would actually be a good break for correspondence chess, in my opinion. So, I have a new idea. The idea is basically centered around a human-readable file format, with the software still being a middle-man. The new method would basically work the same way, except that the output would be human-readable, and have a friendly means of parsing input from a text file as well.

As far as input, the file would only need to read two things - the FEN of the last state of the board, and the next player's move (in algebraic notation). Thus, an input file could look something like…

r4rk1/ppp1pp1p/2nq1npb/3p3b/1P6/1NNBPP2/P1PP2PP/R1BQ1RK1 w - - 5 10
White to move: Nxd5

…keeping the file easily readable, easily parsed. The first line would always be the prior FEN state, and the next move would respond to a few different inputs, 'White to move: ,' 'White: ,' 'W: .' But, the output would be decidedly more complex. For readability and simplicity, I would like to assume a comment character of space. Thus, when white is presented with the file (as it has been output from scorch), it would look something like…

r4rk1/ppp1pp1p/2nq1npb/3p3b/1P6/1NNBPP2/P1PP2PP/R1BQ1RK1 w - - 5 10

 ┌────────┐
 │ KR•QB•R│1
 │PP• PP•P│2
 │ •PPBNN•│3
 │• • • P │4
 │b• •p• •│5
 │bpn qn• │6
 │p•pp ppp│7
 │•kr • •r│8
 └────────┘
  hgfedcba

 
 Black's move: Qd6
 
White to move:

…thus, easily readable by anyone who can read the file, and just as easily parsed by the machine. At this point, only one person needs to be running scorch (which still just relies on the FEN and the last move to generate the board) since one instance handles movement for both payers, as well as generating a file containing a human-readable representation of the board. In fact, if allowed to run as a daemon somewhere, neither player would necessarily need to be on a machine running scorch. All either player would need access to is any program capable of reading and writing plaintext, and access to the file at hand. If scorch read backward through the file, subsequent moves could simply be appended, creating a game log of sorts (ideally, a future version would keep a PGN log. But since I don't even know if there will be a version one, that's really looking to the future…).

I don't have the energy or time right now to actually implement this. But, I write this as a note of something that I think would be a handy, elegant, simple solution to (digital) correspondence chess. The program would basically just need to turn FEN into a game board, and turn FEN plus a move into more FEN. It shouldn't be too terribly complicated, so perhaps I will tackle it some day. For now, however, just a reference for a future implementation - scorch.