Chess

[Chris]

Jan 2, 2014 7:40:35 GMT -8 Wormopolis said:

I saw that format in wikipedia, but I dont know enough about chess to incorporate things like castling and en passante in there. I COULD write it though, so that if you surrounded your example with curly braces, my function would still be able to read it.

The additional fields can be ignored for now and that EPD string treated just like an FEN (just split at the first space). However it is merely the state of the game after each move so displaying those stats adds immensely to the understanding of what is occurring during game play and requires no knowledge if all that is being done is displaying them on each move so keep that in mind for the future.

The point I was making though is a PGN game file might have 50 of those EPD lines so instead of just copying the moves and inserting it in a post between the tags to follow the game visually one would have to first add 50 pairs of curly braces around each line when they are not necessary for parsing. Each line maps exactly 64 squares (occupied and unoccupied) so no need for  delimiters identifying beginning and end. A simple copy and paste operation (without having to edit each line) would be quite marvelous.

It's an ambitious project but if you support the standards (PGN, EPD) from the get-go the possibilities are endless. This could possibly generate a chess enthusiast following on Proboards rivaling the vaunted RPG community

[Wormopolis]

so use \n as my separator then.. I can give that a shot. I was using curly braces because I thought it might blend too much into the next line.

I get your point on cutting and pasting though.

[Chris]

Yes a LF would be the ticket, if memory serves that's exactly how an EPD file separates each line. The process would be to download an industry standard PGN file (can contain several games) then use a convertor to convert one of those games in the file into raw EPD moves (I recall numerous opensource convertors) then finally copy and paste the contents of the EPD file into the post and surround it with your chess tags (no manual editing necessary).

You can download EPD game files in some cases but it is relatively rare compared to the annotated PGN format. Directly parsing the contents of a PGN is a bit more involved since you would basically need to create code capable of determining legal moves then create an FEN/EPD string on the fly after each move in order to build the board

Edit: amended my previous statement to say the moves list in a PGN file first needs to be converted to EPD (kinda lost that step in the fog of time). Although I've seen one or two PGNs with EPD lines in the commentary it is not generally the rule. The good news is there are numerous freeware PGN2EPD or PGN2FEN convertors. It's like a rite of passage to write one in your first programming language and I even recall writing one back in the days.

[Wormopolis]

Im looking at the PGN stuff.. how does one know WHICH piece does the move? like when it puts Nf3, how does it know which of the player's knights is moving there? Im guessing I have to run some sort of function to determine all valid moves for each piece to see if the one in the PGN file is listed?

the EPD game file I think I have but I need to get more samples to run it with

[Chris]

Jan 4, 2014 21:59:57 GMT -8 Wormopolis said:

Im looking at the PGN stuff.. how does one know WHICH piece does the move? like when it puts Nf3, how does it know which of the player's knights is moving there? Im guessing I have to run some sort of function to determine all valid moves for each piece to see if the one in the PGN file is listed?

the EPD game file I think I have but I need to get more samples to run it with

The piece is determined by the destination square but in the event of conflict where more than one piece can legally move to that square then the rank and/or file (file as well if rank is not enough) of the originating piece will be used to disambiguate. This of course would be a worry for PGN creators because the onus to disambiguate would be upon them, those that simply read and use the data contained within the PGN should not have to worry about this except to know that such disambiguation may exist and to be prepared should it be encountered.

And yes, a procedure that is familiar with the legal moves of each piece would determine which of those Knights for example given the destination square would be eligible to move. It's been awhile since I tackled this and as you know my memory is sometimes a sieve so I'll pull the HD out of my old, dead, now paperweight laptop (been meaning to anyway) and see what I can pull off it. I can't quite remember how much of the algorithms I had transferred to javascript and how much was left in in another language. I also recall downloading somewhere in the neighborhood of 150 PGN files while studying the format before writing my own pgn2epd converter. So if those are available will send along with their EPD file conversions as well
(likely on Tuesday this week)

Thanks for doing this Wormo, it was on my list of priorities until life got in the way...

[Wormopolis]

I was working on a converter but ran into that issue when trying to figure out how to convert a move when either rook or knight or any piece promoted from a pawn can now suddenly go the same destination as others. I have been looking at a bunch of papers on the web and they are talking about using the file of the piece as designator. which is great except what file would you use for a promoted piece? I already changed it to start adding data to each piece on the board when a fresh game is started to keep track of file.

the whole en passant thing is confusing as well since some example show it one way and other show it another.

[Chris]

Jan 5, 2014 13:27:53 GMT -8 Wormopolis said:

I was working on a converter but ran into that issue when trying to figure out how to convert a move when either rook or knight or any piece promoted from a pawn can now suddenly go the same destination as others. I have been looking at a bunch of papers on the web and they are talking about using the file of the piece as designator. which is great except what file would you use for a promoted piece? I already changed it to start adding data to each piece on the board when a fresh game is started to keep track of file.

the whole en passant thing is confusing as well since some example show it one way and other show it another.

Once a pawn has been promoted it is irrelevant whether or not it was a pawn in a former life, for all intents and purposes it is now a queen, knight,  (or whatever it was promoted to). I'll need to check this to verify but if you have Nf3 (knight moves to f3) but you have a knight on e1 and a second on g5 (both eligible to occupy that new square) then file would be used to disambiguate (e.g. Nef3 - the knight on the e file moves to f3). Now suppose the second knight was at e5 instead of g5 then using just file would obviously be inadequate to disambiguate, the PGN creator would therefore also need to specify rank (.e.g. Ne1f3 - the knight on e1 moves to f3)

I recall seeing discrepancies on a few things but en passant was not one of them, it's pretty straightforward: on it's very first move a pawn has the option of moving 2 squares instead of 1 but it cannot use this maneuver to avoid capture by an opposing pawn. If it were to move forward 1 square and risk being captured by an opposing pawn then moving forward 2 squares in order to avoid that capture will not work, the enemy pawn can still capture him "in passing". The en passant flag in the EPD string is basically a boolean holding the square that was just jumped and indicating that an en passant capture is now valid for that square. If the enemy has no pawn in place to do the capture or if he opts to make another move rather than the capture then he forfeits the right to make that en passant capture (it must be made on the very next move after the double square move) and that en passant flag is set back to false.

[Wormopolis]

in some of the example there was a e.p. after the move and some there wasnt, so that was what confused me on how to tell.

I get what you are saying on the designation mor multiple piece move. its going to make it a little more complicated, but if its been done in the past, it can be done again

[Chris]

The algebraic notation for en passant captures is the same as for any other capture ("x") if I'm remembering correctly so if you were seeing an "e.p." it would most likely be an annotative comment. A semicolon would be equiv to the "//" in js (comment continues to end of the line) while the "{" and "}" would be equiv to the "/*" and "*/" respectively.

ETA: actually I just looked it up on wikipedia and it says the order is file then rank then file+rank (in that specific order) which means the example I gave before would resolve to the numeric rank rather than the file+rank that I gave. I however have no recollection of a move that used just rank number and from an interpretation perspective it would be unimportant to the reader if it was the rank or file+rank format if they both accomplished the disambiguation. The only thing it might affect is adding unnecessary bytes (and transmission time) to the length of the file when transmitting over a 900 baud dialup modem (screeeech!)

[mistermoonlight]

OT, but I just LOVE watching you guys work, Eton and Worm. Bravo!

[Chris]

Sorry Wormopolis but wouldn't you know it! I pulled the drive from the old laptop, hooked it up to a SATA2USB convertor and after it is detected I am asked if I wish to format because it doesn't recognize there is already a formatted drive in the primary partition but does recognizes the recovery partition with no problem (oy vey iz mir!).
I had collected quite a few documents on the subject (no longer available on the internet except maybe through archives.org) plus a ton of PGN and EPD files with edge cases that I wanted to send your way. I'll try it on the second lappie when it gets here and keep my fingers crossed

[Wormopolis]

If you dont then dont invest too much into it. I can work with just a few and I guess if someone finds one down the line that wont convert then I can blame it on being a Beta version.

[Wormopolis]

so currently working on a function to highlight paths that each piece are allowed to move to. so when you hover over a piece, it hilights green every square on the board that that piece is allowed to go. 3 hurdles:

1. en passant. have to devise a way to tell if a pawn is attackable because it moved 2 spaces out next to an opposing pawn.

2. castling. have to devise a way to figure out if king hasnt moved yet, as well as whatever rook its attempting to castle and effectively move two pieces at once.

3. king in check. moving the king is easy.. figuring out if any other opposing piece on the board could capture it if it moved to a spot requires looping through every other dang piece and collecting a list of friggin squares it can move to. which is tedious.

otherwise.. I have all the pieces able to highlight their paths including a pawn attacking diagonal. the goal is to make all this work so I can move to playable games where each person goes to make their move and it shows them what their options are.

a further thing that worries me is pawn promotion and how Im going to implement it.

[Chris]

Jan 12, 2014 21:19:48 GMT -8 Wormopolis said:

so currently working on a function to highlight paths that each piece are allowed to move to. so when you hover over a piece, it hilights green every square on the board that that piece is allowed to go. 3 hurdles:

1. en passant. have to devise a way to tell if a pawn is attackable because it moved 2 spaces out next to an opposing pawn.

2. castling. have to devise a way to figure out if king hasnt moved yet, as well as whatever rook its attempting to castle and effectively move two pieces at once.

3. king in check. moving the king is easy.. figuring out if any other opposing piece on the board could capture it if it moved to a spot requires looping through every other dang piece and collecting a list of friggin squares it can move to. which is tedious.

otherwise.. I have all the pieces able to highlight their paths including a pawn attacking diagonal. the goal is to make all this work so I can move to playable games where each person goes to make their move and it shows them what their options are.

a further thing that worries me is pawn promotion and how Im going to implement it.

Points 1 and 2 are fields in an FEN/EPD field so if you're generating EPD notation then they can be recorded there and keeping track of these would be essential to the accuracy of your move path analysis highlighter. The en passant field in the EPD gets set to the square that was hopped over by a double square pawn move (e.g. "c6") and this is irregardless of whether an opposing pawn is in position to make a capture. If an opposing pawn is in position and wants to attack that (empty) square on the next turn immediately following the hop then he can (and capture the pawn that just passed through that square). If the opposing player opts not to take advantage of that en passant eligibility (makes a different move) then the EPD field is reset to a single dash (or double-dash, I've seen both since the spec is mute here so be prepared). The field merely indicates which square (and therefore which pawn) is "attackable" by this special move.

The castling field similarly enforces the rule that if one or both of the pieces involved in the castling has moved then eligibility to castle those pieces are forfeit. The pieces involved here are: the queen-side rook for queen-side castling and the king-side rook for king-side castling. There are therefore 4 slots making up that field, two for white's King-side and Queen-side and also two for black's (lowercase "k" and "q"). If king-side rook moves (or gets captured) then "K" or "k" is added and same for queen-side ("Q" or "q"). If the king moves then both king and queen sides get set. Once set, then castling on the side that was set is no longer possible (if king moved both sides are set).

You should note that the fields only indicate eligibility, for example in the case of passant whether or not a piece is in position to take advantage has no bearing on whether the field gets set and similarly in castling there is no verification whether a king would be passing through check or if there are pieces blocking the way just that the option to castle still remains in the game.

Promotions are the easiest of them all, the notation is simply an equal sign following the pawn move (e.g. "c8=Q"). Once the promotion occurs you now treat it as the piece to which it was promoted (usually "Q" as in the example, promotions to other pieces are rare) and nothing in the game would require knowledge that this was a pawn in a former life. If you refer to implementing during game play that is rather simple as well, once the pawn reaches the last rank most engines use a popup to ask the player to which piece she wishes to promote this pawn then replaces the pawn with the chosen piece

[Wormopolis]

This is more geared towards actually playing the game in a thread. I put the converter on hold for now whilst I try and get this working. I already have it though taking in a block of linefeed seperated EPD statements and extracting the FEN from them to display. when I can get the play system working, I was going to incorporate a converter system that keeps track of positions and converts to PGN if requested.

an import/export system would be farther in the development.

I have all the king path choices working now, and indeed had to use a loop for it, but I did something clever and just reused my same path function and had it return a list of each pieces available paths. after all opposing piece paths were collected, then a quick for loop for the king to check his paths didnt coincide and if it did, that square wasnt hilighted. special care had to be taken in the case of an opposing king or pawn since a king cant place itself in check, but it has to be collected as a danger square for the OTHER king in order to keep the other king from moving into check. and a pawn cant attack straight, so it had to be also checked for diagonal moves even without pieces to capture in order to make sure the king didnt place itself in check against a pawn.

so now Im working on the castling aspect, which is going to be tricky since I just found the rule that not only can the king not end up in check after castking, but the square it moves THROUGH cant be in check either. also apparently you cant use castling to get out of check, which I didnt know.

I will say Im glad I got the FEN editor working because it makes it really easy to generate test boards in order to test all these move/attack paths.

If you want an editable version Chris let me know. I have it automatically show paths on piece hover for all boards displayed in posts for quick testing.