（评论）

（评论）
(comments)

原始链接: https://news.ycombinator.com/item?id=40342803

用户根据特定的移动规则讨论国际象棋游戏之间的概念差异。他们比较了一个常见的定义，即国王移动两个方格，车跳过中间的棋子，与另一个定义，允许国王移动到某些文件，而车保持在同一列内。这些规则对于传统国际象棋来说是可以互换的，但只有第二个规则对 960 方棋盘有效。用户对有人建议关闭游戏中的动画表示惊讶，暗示这可能是一个玩笑或对非 JavaScript 意识形态的极端坚持。他们挑战了所讨论的游戏是纯静态的观念，指出通过后端进行动态渲染。他们解释了对可声明和可检测的规则（如三重/五重重复和五十/七十五步棋）进行编码的重要性。对于更强大的国际象棋引擎来说，历史可能并不总是必要的。用户提到了 Chrome、Firefox 和 Safari 等现代浏览器之间的 URL 长度不同，但在对实际限制做出判断之前强调了 CDN、Web 服务器和搜索引擎的考虑因素。根据他们过去的经验，他们对一种名为“黑白棋”的不同棋盘游戏进行了暴力破解，并使用最少的方法（不包括 JavaScript）实现了它。他们还提到了这个国际象棋应用程序遇到的问题：皇后升级不正确以及无法在 EWW 浏览器中使用棋盘。尽管偏爱轻量级和快速的网站，但用户得出的结论是，这些妥协导致了不令人满意的游戏体验。

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.)

Indeed - perhaps you could say that 960's castling rules are a superset of normal castling rules.

Edit: Actually, I think the other way around is more accurate - 960's castling rules are a subset of normal castling rules.

> 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.

Well played and clever implementation!

I'd wager that it's a humorous description, taking certain virtues to an illogical extreme.

The limited functionality is nevertheless likely referring to features beside the ones described as bloat.

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.

Lichess opening explorer would probably be a fairly accurate indicator of how the cache hit ratios would develop:

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.

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.

huh, I originally thought this would create unusually long URLs, but if it's just the sequence of moves it could stay pretty small.

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 uses the FEN, which is the standard notation for chess positions.

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.

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.

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’m frankly kind of bummed that this isn’t fully static chess. As in every possible move is a pre-rendered html file on a server somewhere.

This is more akin to how Yahoo Games and other chess sites worked in the early aughts.

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:

https://mirrorchess.com/

(It's ok, I made it.)

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 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. :)

> 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.

Doesn’t seem to work on Mobile Safari? I can tap to select a piece but tapping a target square to move doesn’t do anything.

EDIT: seems like you need to tap the top edge of empty spaces?

yeah, I squashed a few bugs here but there is more weirdness. will check it out

edit: ah! regular ol' relative/absolute position (been a bit since I wrote css), this should now be fixed!

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 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.

（评论） (comments)

（评论）
(comments)