A while back, I attempted to write a chess site that let you paste in chess games in PGN text format, and then step through them. What I found was pretty shocking: the PGN format looks simple, but is remarkably difficult for a computer to parse.
The reason is that the PGN format only specifies the piece type and destination square of each move. Ne4: a knight moves to e4, and it's up to the parser to figure out which knight. So to parse PGN, you have to teach your parser how the pieces move.
That by itself is not too bad, but it gets worse. What if both knights can move to e4? Then the format disambiguates. Nge4: the knight on the g file moves to square e4. But "can move" is a tricky notion in chess. This knight cannot move because it is pinned to the king. That pawn can capture en passant this turn, but not next turn. So to write a PGN parser, you must build a chess engine capable of analyzing a board sufficiently to determine legal moves.
One might hope that reasonable PGN text would be nice and disambiguate whenever two pieces attack the same square, and not require legal move analysis. Alas, it is not so. The "two knights attack a square but one is pinned" case is specifically called out as NOT requiring disambiguation in the spec at http://www.saremba.de/chessgml/standards/pgn/pgn-complete.ht... .
A further consequence is that it is not possible to make a "generic PGN" parser that can handle chess variants, like suicide chess. The rules of chess are baked into the format itself, and the parser must have knowledge of the rules used to play the game that it is presenting.
This is a great write-up and is exactly the reason that ChessBoard is "just a board".
Proper PGN parsing and legal move validation is a complex and independent problem that nicely fits into it's own library and should be separate from any display logic.
PGN isn't a format designed for parsing convenience. PGN is the exact notation any chess player uses for writing down games. I would never write down 1.e2-e4 for instance when simply 1.e4 is totally apparent. I find it very confusing when too much information is presented in this case. In the same vein, whenever you are presenting chess notation to a human it is preferable to not show the long notation. So any time you would want to display the notation of a chess game(which is pretty much everytime) you would need to parse the game with a program that understands the rules to produce the shorter notation.
I've found that the rules can be expressed quite elegantly and compactly in a language that supports pattern matching. I have a Haskell implementation [1] which is just under 300 lines of code including the parsing of SAN moves (standard algebraic notation) which is used in PGN files.
True, it would be tricky to get all the rules of chess into a JS file (sounds like a worthwhile open source challenge to me!), but it wouldn't be so hard to expose the features of a chess program like Crafty through an API and do the check via AJAX.
"it would be tricky to get all the rules of chess into a JS file"
Check out chess.js, https://github.com/jhlywa/chess.js, it does a pretty excellent job. The combination of chessboard.js and chess.js would result in a pretty sweet browser-based chess game.
I'd be interested to hear your progress against this 1024 byte chess game. It could make an interesting blog post - each game you play, with some analysis of what you do to try to win and whether that works or not. :-)
how do they do this ?
do they write it in normal JS and optimze the hell out of it in terms of size? Is it some kind of special compiler or all done by hand ?
A combination, I suppose. First optimize the code so that the number of instructions are kept to a minimum and then use a minifier tool to shorten variable names and such. http://compressorrater.thruhere.net/
It seems to me it is not a "real" AI. I began a game, and after complete development on my side (about 5-6 moves), the opponent AI did only developed pawns, which shows off its limits.
I am not a javascript expert. but given the size of the code, I doubt there is a great IA underluying. Actually I've browsed the mignified code in order to find the AI implementation. The only clue I spot was a call to the Random() function. I won't state it for sure, because I wasn't able to understand the whole code. But I highly guessed it is the basis of the AI implementation. :-)
Play a full game and you'll be surprised, the AI is actually surprisingly good and gets better as the game progresses, especially given the size of the code.
On a less painful note, these types of scripts that do so much with so little are exactly the type of problem that interest me. I don't even care that I was beaten; I just love the fact that something like this exists.
Just goes to show how algorithmic chess can be. And code, no matter how "primitive" will trump neurons when it comes to algorithms.
In American English, slang for an insult is a "burn".
e.g.
"You got burned" = "You were insulted"
The poster was making a joke that the OP had been insulted because this other JavaScript board is superior or something, hence, he directed him to treatment centers for a "burn".
Yeah, probably, I took a look at the code, it seems easy to extract positions with few jquery lines, and I guess there is probably an API for resolving chess mates problems!
Not much to see here. Why is this JS? Usually JS requires some interaction. Even lightbox flew around and did something. This would be even easier as a chessboard PNG rendering REST service.
I initially based it off a wild idea my coworker and I had about a chess variant where any piece that captures another piece has the option of becoming that piece. I then expanded it with several other chess rule variants, including vanilla chess.
One thing worth mentioning is that the rules for chess are deceptively complex. Especially when it comes to valid moves avoiding check and moving out of check. See:
The reason is that the PGN format only specifies the piece type and destination square of each move. Ne4: a knight moves to e4, and it's up to the parser to figure out which knight. So to parse PGN, you have to teach your parser how the pieces move.
That by itself is not too bad, but it gets worse. What if both knights can move to e4? Then the format disambiguates. Nge4: the knight on the g file moves to square e4. But "can move" is a tricky notion in chess. This knight cannot move because it is pinned to the king. That pawn can capture en passant this turn, but not next turn. So to write a PGN parser, you must build a chess engine capable of analyzing a board sufficiently to determine legal moves.
One might hope that reasonable PGN text would be nice and disambiguate whenever two pieces attack the same square, and not require legal move analysis. Alas, it is not so. The "two knights attack a square but one is pinned" case is specifically called out as NOT requiring disambiguation in the spec at http://www.saremba.de/chessgml/standards/pgn/pgn-complete.ht... .
A further consequence is that it is not possible to make a "generic PGN" parser that can handle chess variants, like suicide chess. The rules of chess are baked into the format itself, and the parser must have knowledge of the rules used to play the game that it is presenting.