Static Chess
val.town
val.town
Example: https://chess.maxmcd.com/bbnqrknr/pppppppp/8/8/8/8/PPPPPPPP/...
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.
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?
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.
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.
> 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.
Well played and clever implementation!
The limited functionality is nevertheless likely referring to features beside the ones described as bloat.
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.
There are. They're just compressed with an application-specific compression approach.
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.
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
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].
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.
[0]: https://stackoverflow.com/questions/417142/what-is-the-maxim...
- [Try it](https://afauroux.github.io/chess/) - [Fork it](https://github.com/afauroux/chess)
For example - https://chess.maxmcd.com/rnbqkbnr/ppp1pppp/8/3p4/3P1B2/8/PPP...
Or just rip off the chess piece design of this other minimalist chess board simulator, which is never upside down:
(It's ok, I made it.)
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.
Obviously very cool idea and implementation tho! I think the answer to the google question is “probably”
EDIT: 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!
We need a brutalist software manifesto.
This is more akin to how Yahoo Games and other chess sites worked in the early aughts.