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).
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.
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.)
> Plain, brutalist, no bloat chess. Every page is only html and css. Every chess move is made by clicking a link. Send a link to your friend and they'll send you one back to make your move. No silly animations or slick interactivity to trip up your gameplay. When Google indexes this site will we successfully compute all possible chess moves?
> Functionality is quite limited, and things might be broken. Please let me know if you find bugs!
Not sure if the first paragraph boasts the pros or the cos of this
sort of implementation.
It's one thing to market implementations done in unusual ways with the intent of exploring the possible. It's another to portray software implemented with the right technologies as : bloat, silly animations, slick interactivity to trip up your gameplay.
It doesn't help that the second paragraph showcases shortcoming of this kind if implementation.
It could all just be sarcastic and I fell for your trap.
I suspect it's mostly "because it occured to me I could," which I think should always be an acceptable reason for building something slightly unusual.
I do rather like the idea of play via stateless link passing, though, and honestly the "prettiness" of animations and interactivity does not, at least to me, seem like a net advantage.
"the right technologies" is highly dependent on the user experience you're trying to achieve; in this case I think I'd argue that for the goal at hand, these -were- the right technologies, just like for the UX goals of more featureful sites a different bundle of technologies were the right thing too.
Yeah the idea that you wouldn't want animations in a GAME is hilarious. It must either be a joke or this person is really that far up the "the web shouldn't have js" culty asscrack.
It's cool and interesting to make a game that doesn't require those. But it puts extreme limitations on the game. There is no reason to aspire to making only games that include no js and animations. If there's ever a usecase for JS and animations its a game. Games are usually dynamic. Games usually involve moving visuals. Saying those things are unecessary means you're the guy at the game party who refuses to play Catan because tic tac toe is enough.
This isn't really static right? It's still dynamically rendered by the backend each time you request the page. There aren't 999999919291293923 pre-rendered pages living on a server somewhere.
I can start a game on Lichess, resign it right away, enter analysis mode, then disconnect from the internet and continue to use the board (in the same way that one can use the board on site we are discussing here), so Lichess's analysis board does not use XmlHttpRequest either.
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.
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.
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.
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.
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.
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.
I noticed a weird bug where sometimes the game will auto-move for a player. In particular, this seems to happen when one queen captures a piece, and the opposing side has the ability to capture that queen with their queen, the game automatically makes the 'queen takes queen' capture.
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.
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.
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:
> 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.
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 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. :)
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”
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.
Bruteforcing all the possible moves into a static set of files. I wonder how much space it does occupy, considering that small files take more space than large files with the same amount of bytes
I think a compromise would be more practical: every position that has actually occurred as a pre-rendered html file, with novel positions generated dynamically.
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.
Example: https://chess.maxmcd.com/bbnqrknr/pppppppp/8/8/8/8/PPPPPPPP/...