I imagine it would look closer to the Lichess database, which differs quite drastically from the Masters database. For instance, with the masters e4 is met with c5 in 46% of games, but on lichess c5 only happens in 19% of games.
Chrome can supposedly support 32779 characters in the address bar[0], and a legal chess game should not exceed more than ~5900 moves, due to the 50 move rule. That will be enough to encode any valid game if you don't need to support IE.
Interesting. According to that stackoverflow, Chrome is one of the shortest URL lengths of the modern browsers (firefox/safari/chrome). However, it also notes you have to take CDNs and web servers and search engines into consideration, so the ginormous length limits of safari and firefox probably won't be useful any time soon.
The move order matters, for detecting threefold or fivefold repetition, or the 50 move draw limit.
To adhere to that properly, you need to somehow represent all previous positions that could be reached again, and the number of times it has occurred. Of course you can get that by including all the move history, but it's also possible to prune it a lot, like any capture or pawn move can flush the history since no previous position is reachable. But it's still a bit more complicated than just representing the current position.
FEN doesn't account for this, deliberately leaving the history out of scope. It's a matter of preference whether you'd want a tool like this to handle those cases.
No it shouldn’t. Move history has to be encoded so draw by threefold / fivefold repetition and fifty moves / seventy five moves can be claimed / detected.
The half-move counter in the FEN takes care of the 50/75 move rule. You do need the history if you want to implement the threefold/fivefold repetition rule, but it's rare that it is actually relevant for e.g. a chess engine's strength.
Not OP, but having a favicon—any favicon, really—during prototyping helps me get a feel for my project's identity, and, more pragmatically, gets rid of incessant 404s.
https://fav.farm seems like a cool service at first, but it doesn't actually do a whole lot. I'd just assume inline the one-liner they mention (similar to https://css-tricks.com/emoji-as-a-favicon/) and avoid the external dependency for the price of 117 characters.
This and castling strike me as the kind of rules where a King like Henry VIII was losing and decided to castle for the first time ever and his opponent was too scared to say anything to stop it.
On one hand this kind of rules seem like tacked on, artificial, but on the other hand en passant has been introduced for a good reason and chess would be quite dull without it.
If checkmates actually said ‘checkmate’ on them you’d be able to find them once the Google bot has indexed the whole site.
Ideally every page needs to include a string summarizing every preceding board state leading up to it, so you can search for a current board state plus ‘checkmate white’ to find every possible way to win from a given board state.
Then all that remains to turn Google into the ultimate chess oracle is to persuade your opponent to make all the moves you found.
Fun fact: you can use this to play chess960 (i.e. fischer random chess), or any other "custom start position" variant, just by appending a FEN to the URL (replace spaces with underscores).
That depends - Chess960 doesn't have different castling rules from normal chess, it just has additional considerations that normal chess does not.
In other words, Chess960's castling rules are completely consistent with normal chess castling rules, so depending on how it is implemented, it might just work.
It depends on how exactly you define it. If the standard rule is as commonly taught "king moves two spaces and the rook hops over", 960 isn't the same. If the rule is "king moves to c or g file, rook moves to d or f", then it is the same. Those rules are equivalent for standard chess but only the latter ports to 960 properly. (We're probably agreeing, in that's what you mean by depending on the implementation, I'm just spelling it out.)
The main difference is that the FEN no longer only encodes castling to the king's or queen's side. It must fully encode which file for each side. Castling _rules_ are the same, just the castling _location_ can change.
I admit that while I do regularly play chess, I'm not super well versed in either FEN nor Chess960. That said, I've been trying to figure out why you would need a different notation for Chess960 for half an hour now, and I just can't figure it out. All explanations I'm seeing just make some vague mention about ambiguity in the regular notation for Chess960, but I, personally, can't think of a situation in which the regular notation is insufficient.
The KQkq still unambiguously mark which player can castle to which side, and once either a rook or King move for the first time, you just remove the corresponding letter(s). What am I missing?
One of the rooks might move over to the other side during the course of the game, and then it's no longer unambiguous which one is the castling rook.
E.g., if you have your king on e1, a rook on f1 and another one on g1… can you castle if the f1 rook moves? Can you castle if the g1 rook moves? Just “kingside” won't tell you the difference.
I mean technically it still isn’t ambiguous because you could just refer to the starting position to see which rook is allowed to move.
Which of course is annoying to implement, but you do already have to keep state on the history of the game to determine if moves are legal, e.g. you can’t castle twice.
The entire point of a FEN is that it describes the entire board state without having to know anything about the history.
> Which of course is annoying to implement, but you do already have to keep state on the history of the game to determine if moves are legal, e.g. you can’t castle twice.
No, that's what the castling rights field in the FEN is for. Once you castle, you zero out both the k and q bits.
> When Google indexes this site will we successfully compute all possible chess moves?
How do spiders know when to stop spidering when they keep getting original content? I assume there's a Gordian solution to the Halting problem like a limit to bytes or seconds. But if you applied the same rules to ebay.com and val.town that doesn't scale.
Big spiders neither stop nor start. If each webpage gives you on average 200 new urls, you need to aggregate them, calculate ranks and schedule the top 0.5% for crawling. Crawling capacity is constant, the only question is the quality of your ranking formula.
There's a lot of heuristics. Big sites get more crawl time. Some crawlers will back off if pages are slow. There's usually some sort of 'interestingness' calculation, so repetitive content won't get crawled as much.
This is great! I love the simplicity of it. I was hoping that since it didn't require Javascript, it would work in the Emacs Web Browser (EWW). Sadly, it doesn't render the grid properly. Another niggle, when I moved my pawn to its last rank, it auto-promoted to a Queen rather than prompt me.
One of my personal projects uses a similar idea, but it's a word game (scrabble-like) and it's hosted statically: https://jcparkyn.github.io/scrobburl/
I applaud the aim to make lean and fast websites, but the lack of timer and drag+drop on this game makes it unusable, so I think this actually makes the reverse point -- one should not put non-functional requirements ahead of the function of a product. In other words, this was not a good compromise.
This is great. Suggest one additional bit to show black at the bottom. That way the player of black is not handicapped by playing from an upside down position.
Or just rip off the chess piece design of this other minimalist chess board simulator, which is never upside down:
Haha this one got me good. I was poking around the code looking for how the url is transformed into a chess board state, but its JavaScript in 2024 so of course my journey was a short one ending in an NPM import. You’ve gotta laugh, you’ve just gotta laugh…
Obviously very cool idea and implementation tho! I think the answer to the google question is “probably”
I did something nearly identical to this for the board game Reversi as part of an exercise to teach myself Python, except the opponent was always a simple minimax search-based AI. This was back in 2006, though, so I suppose doing it without JavaScript and putting all of the state into the URL was a lot more obvious of an approach back then compared to today. :)
126 comments
[ 3.4 ms ] story [ 183 ms ] threadEDIT: seems like you need to tap the top edge of empty spaces?
edit: ah! regular ol' relative/absolute position (been a bit since I wrote css), this should now be fixed!
https://lichess.org/analysis#explorer
I imagine it would look closer to the Lichess database, which differs quite drastically from the Masters database. For instance, with the masters e4 is met with c5 in 46% of games, but on lichess c5 only happens in 19% of games.
very cool, made it all the way to a checkmate
[0]: https://stackoverflow.com/questions/417142/what-is-the-maxim...
might more fun too, representing each state of play instead of just the board position.
Also easily compressible if size is an issue: https://mbuffett.com/posts/compressing-chess-moves
Would also mean all rules can be represented, and you'd be able to do cool things like highlight the previous move that was made.
Nice, ok, might try and add this.
It could also be pretty long, 5898 moves to be precise when using the 50-move rule [1].
[1] https://www.youtube.com/watch?v=D5DXJxR3Uig
And it's the right choice, IMO -- if two positions are the same they should have the same URL, regardless of the specific move order used to reach it.
To adhere to that properly, you need to somehow represent all previous positions that could be reached again, and the number of times it has occurred. Of course you can get that by including all the move history, but it's also possible to prune it a lot, like any capture or pawn move can flush the history since no previous position is reachable. But it's still a bit more complicated than just representing the current position.
FEN doesn't account for this, deliberately leaving the history out of scope. It's a matter of preference whether you'd want a tool like this to handle those cases.
https://chess.maxmcd.com/r1b1kRnr/p1ppB2p/n2P2p1/8/7P/1p6/PP...
Should say checkmate?
Ideally every page needs to include a string summarizing every preceding board state leading up to it, so you can search for a current board state plus ‘checkmate white’ to find every possible way to win from a given board state.
Then all that remains to turn Google into the ultimate chess oracle is to persuade your opponent to make all the moves you found.
Example: https://chess.maxmcd.com/bbnqrknr/pppppppp/8/8/8/8/PPPPPPPP/...
In other words, Chess960's castling rules are completely consistent with normal chess castling rules, so depending on how it is implemented, it might just work.
Edit: Actually, I think the other way around is more accurate - 960's castling rules are a subset of normal castling rules.
https://www.chessprogramming.org/Forsyth-Edwards_Notation#Ch...
The KQkq still unambiguously mark which player can castle to which side, and once either a rook or King move for the first time, you just remove the corresponding letter(s). What am I missing?
E.g., if you have your king on e1, a rook on f1 and another one on g1… can you castle if the f1 rook moves? Can you castle if the g1 rook moves? Just “kingside” won't tell you the difference.
Which of course is annoying to implement, but you do already have to keep state on the history of the game to determine if moves are legal, e.g. you can’t castle twice.
> Which of course is annoying to implement, but you do already have to keep state on the history of the game to determine if moves are legal, e.g. you can’t castle twice.
No, that's what the castling rights field in the FEN is for. Once you castle, you zero out both the k and q bits.
But if you have a later board state, with two rooks on one side: how do you know which one is still eligible to castle?
How do spiders know when to stop spidering when they keep getting original content? I assume there's a Gordian solution to the Halting problem like a limit to bytes or seconds. But if you applied the same rules to ebay.com and val.town that doesn't scale.
[0]: https://github.com/Dragon-Hatcher/type-system-chess
Repo: https://github.com/Jcparkyn/scrobburl
Or just rip off the chess piece design of this other minimalist chess board simulator, which is never upside down:
https://mirrorchess.com/
(It's ok, I made it.)
For example - https://chess.maxmcd.com/rnbqkbnr/ppp1pppp/8/3p4/3P1B2/8/PPP...
Obviously very cool idea and implementation tho! I think the answer to the google question is “probably”