Hacker News Reader

Comment by perihelions | Hacker News Reader

- "While these moves could be calculated client-side, providing them server-side ensures consistency - especially for complex or esoteric chess variants - and optimizes performance on clients with limited processing capabilities or energy restrictions."

Just a wild guess: might be intended to lower the implementation barrier for new open-source software clients on new platforms, and/or preempt them from implementing subtle logic bugs that only show up much later.

The rules of chess are a bit tedious to implement, and you can easily get tired and code an edge-case bug that's almost invisible. Lichess itself did this—it once had a logic error that affected a very tiny number (exactly 7) of games,

https://github.com/lichess-org/database/issues/23 ("Before 2015: Some games with illegal moves were recorded")

(I apologize I couldn't find the specific patch that fixed this)

View on HN

For those curious about the illegal move, it seems like it's allowing queen side castling through the king side rook (or vice versa). eg. if this is the first rank, R _ _ R K _ _ _, then you could make the move O-O-O and end up with _ _ _ R K _ _ _

Naturally, it's not possible to view this move anymore, but this game (https://lichess.org/XDQeUk6j#48) has everything up until the last legal move right before the illegal castling happened.

I can see why that only appeared in 7 games. It's pretty rare to see a rook in between a king and another rook that are otherwise legally able to castle. Even rarer for someone to get into that position and actually try to castle.

Also that linked game is pretty entertaining. It's not a good game, but it can be fun watching lower ranked players make moves that you'd never see in higher level games. Like, who plays Bb5+ against the Scandinavian? Amazing stuff.

Wow it just ate the rook huh?

seriously...how'd it vanish?

Wouldn't the bug with queen side castling end up with _ _ K R _ _ _ _?

This looks like the relevant fix: https://github.com/lichess-org/scalachess/pull/154

(the broken code checked that the only pieces on the king's path to its new position were kings and rooks of the appropriate color)

Another wild guess: Lichess could be pre-calculating and caching the legal moves for the most common chess positions. While pre-calculating every possible legal move for every position would be impossible, you could pre-calculate the most common openings and endgames, which could cover a lot of real-world positions. This cache could easily be larger then practical for the client, but a server could hold onto it no problem. This could save on the net processing time, compared to the client determining all legal moves for every position.

Given that a good chess move generator will work in way less than a microsecond (TBH, probably even less than taking a DRAM lookup for a large hash table), and most chess positions have never been seen before, having a cache sounds counterproductive.

> and/or preempt them from implementing subtle logic bugs that only show up much later.

Validating a submitted move is distinct from listing valid moves. I assumed the server would need to validate regardless of providing a list to the client.

It's still duplicated work, and clients are likely to get it wrong and create more work for both devs.

From what I remember, one of the main reason also was to avoid bloating the JS on the game page. That page is kept especially slim to maximize performance and load times for low-powered devices.

Great!

A bit of surprise consideration … is that even common in these days of overfancy web sites.

Reply on news.ycombinator.com