A lot of people are making fun of his code or versioning skills.
It's very cool that he was able to code something interesting enough to be on the top of HN, without mastering the tools he used.
People should focus less on code and tools and more on making great stuff, like him.
> Do not expect the code to be stable under any modifications, but you can try if you want I guess. Also there are barely any comments sorry. I am in Electrical Engineering and I like writing shitty code to piss off my Computer Science friends.
Teenager Evariste Galois did a lousy job of explaining how his math worked, none of the experts could make sense of it. He'd been dead a decade before Liouville said hey, this shit is alright. It turned out to be sorta useful a century later. A couple of the experts are still remembered, not for much.
There's a button with two diagonal arrows that lets you enter fullscreen mode although you might have to scroll a bit to get it to show. Otherwise, you might have to fork the replit and make an account. It's free.
Very interesting. From playing a single game you immediately notice that traditional chess theory doesn't apply to this game at all. After some testing I found a few things in particular that change the way the game plays out drastically:
When having two pawns adjacent one of them can still defend the other by having it only slightly behind. They can also alternate defending each other with a single move. Pawns can also attack/defend things directly in front of them by pushing up against them. These things combined mean that it's almost impossible to have any pawn weaknesses, other than having a singled out pawn with no neighbors. In general pawns are the most improved piece with this ruleset.
The ability to move directly forward makes knights significantly stronger. Knights ability to move through other pieces is also particularly strong versus pawns which can now block most pieces from moving around quite easily.
Since pawns generally mainly move along one axis, it is easier to control the distance between pieces in the forward-backward axis than in the left-right axis. This makes it harder to utilise Rooks to capture two adjacent pieces. Bishops on the other hand have an easier time capturing two adjacent pieces, if positioned correctly. I'm not sure this compensates for the fact that bishops now have a much harder time penetrating positions, they are the most easily blocked of all the pieces.
Overall it is very interesting as a chess variant, it plays so very different from chess. It's hard to even figure out reasonable openers.
"To win, you simply need to capture the opponent's king. This is mainly because stalemate is basically impossible, as the king can always move an infintesimal amount, and also because implementing check/checkmate would destroy the last ounce of sanity I have left."
Do not expect the code to be stable under any modifications, but you can try if you want I guess. Also there are barely any comments sorry. I am in Electrical Engineering and I like writing shitty code to piss off my Computer Science friends."
My father (quantum mechanics) would sometimes submit awful but working code to Dijkstra without proofs just to piss him off. Dijkstra didn't like the looseness of the physics students when it came to software development, while physics students didn't like the software proofs for things in physics that were experimental and needed a 'quick' (nothing was 'quick' then compared to now of course) set of calculations/simulations and not waste time on writing formal proofs for them.
In chess, you win when you are "about to" capture the opponent's king on your next move, which is called putting them in check, and there's no way for the other side to avoid it (block or move out of check).
So I've always found it very bizarre that if it's a player's move, but any possible move would put their own king in check, then it is a draw (rather than a loss).
This leads to a situation where one side can have almost no pieces left, perhaps only the king, but still somehow draw since the king can't move anywhere where it wouldn't be captured.
I imagine a king all by himself peeping his head out out for a place to move, but everywhere is covered by snipers, so, since he can't move anywhere without getting captured, despite being overwhelmed by enemy forces he yells out a la monte Python "So we'll call it a draw then!"
It's because chess was invented by programmers, and stalemate means "the game is broken because there are no legal moves so it's impossible to continue", so we call it a draw.
Maybe if you think of it in terms of the opposition falling to put you in check despite you only having a king left? Your army chased the opposing king to the forest but failed to defeat him, be gets to live out his days as a hermit. You are denied 'satisfaction'.
?
In my family, against my children, it's a running joke that I'll almost always fail to win, and stalemate them.
There’s something profound here about how the very natural conventions in Chess (“If you did that, you’d lose, so I’d rather we continue playing”) have redefined “valid” in a way that is surprisingly hard to re-implement with code.
You can make illegal moves in over the board chess, and sometimes it's advantageous to do so. E.g. In blitz chess an invalid move is an immediate loss. So, if you're going to lose anyway, you can make an invalid move hoping your opponent doesn't take the time to notice. One common one is to move your king next to your opponent's king, putting their king in check, if they don't call you on it, and don't move their king out of check, they lose. Unofficially, this is considered part of the game in blitz, but is considered unsportsmanlike in long games (where it's not an immediate loss).
It always struck me as odd that the checkmate definition should be so (relatively) complicated. A much simpler definition is "you lose if the opponent captures your king". A checkmate is just a situation where you can't avoid getting your king captured. If someone doesn't notice their king is on check, then they could lose the next move. After you pass the beginner phase, this will almost never happen to you anyway, so most games will end the same way: checkmate or losing because of time.
When I was in school, we used to play blitz like that. You lost track of your king, boom, you're dead
It is very easy to implement with code. Chess computers are some of the first well-known computer programs (see, for example, Deep Blue).
What is difficult is adapting chess's rules to this analog environment. It would be similarly difficult if you played this way with a real chess set in the real world, has nothing to do with code.
you can’t represent the real plane on a computer. you can only have a limited amount of precision that effectively results in very dense grid, but a grid nonetheless
Then it's checkmate, not stalemate. For a stalemate you need a situation where the king is not in check, but there are no legal moves. It seems impossible in practice, if not in theory.
What would people think about doing a tournament for analog chess? I'd be willing to put down $1k for the prize pool. I think it'll be cool to see what creative strategies people come up for this.
Please say more! Very interested in this category in general. Would love a version of basketball where the points are a continuous function of distance from the basket rather than discrete 2 & 3 pointers.
I did not look at their particular code but I had files named like this in my projects: api_v1, api_v2. Reason being that the software V2 still supported v1 api so both were present and needed.
"To run the code you will need to install Python and the PyGame library, and then run the latest .py file because I can't be bothered to actually use version control."
Readit News
> Warning: This code is fucking awful.
> Do not expect the code to be stable under any modifications, but you can try if you want I guess. Also there are barely any comments sorry. I am in Electrical Engineering and I like writing shitty code to piss off my Computer Science friends.
Doesn't the legend have it that he scribbled a lot of his ideas down hastily the day he though he was going to die?
When having two pawns adjacent one of them can still defend the other by having it only slightly behind. They can also alternate defending each other with a single move. Pawns can also attack/defend things directly in front of them by pushing up against them. These things combined mean that it's almost impossible to have any pawn weaknesses, other than having a singled out pawn with no neighbors. In general pawns are the most improved piece with this ruleset.
The ability to move directly forward makes knights significantly stronger. Knights ability to move through other pieces is also particularly strong versus pawns which can now block most pieces from moving around quite easily.
Since pawns generally mainly move along one axis, it is easier to control the distance between pieces in the forward-backward axis than in the left-right axis. This makes it harder to utilise Rooks to capture two adjacent pieces. Bishops on the other hand have an easier time capturing two adjacent pieces, if positioned correctly. I'm not sure this compensates for the fact that bishops now have a much harder time penetrating positions, they are the most easily blocked of all the pieces.
Overall it is very interesting as a chess variant, it plays so very different from chess. It's hard to even figure out reasonable openers.
Do not expect the code to be stable under any modifications, but you can try if you want I guess. Also there are barely any comments sorry. I am in Electrical Engineering and I like writing shitty code to piss off my Computer Science friends."
I appreciate this README's sense of humor
Fucking awful barely-functioning open source code is better than no code available, every time.
So I've always found it very bizarre that if it's a player's move, but any possible move would put their own king in check, then it is a draw (rather than a loss).
This leads to a situation where one side can have almost no pieces left, perhaps only the king, but still somehow draw since the king can't move anywhere where it wouldn't be captured.
I imagine a king all by himself peeping his head out out for a place to move, but everywhere is covered by snipers, so, since he can't move anywhere without getting captured, despite being overwhelmed by enemy forces he yells out a la monte Python "So we'll call it a draw then!"
?
In my family, against my children, it's a running joke that I'll almost always fail to win, and stalemate them.
When I was in school, we used to play blitz like that. You lost track of your king, boom, you're dead
What is difficult is adapting chess's rules to this analog environment. It would be similarly difficult if you played this way with a real chess set in the real world, has nothing to do with code.
I don't think this is true, it should be perfectly possible to cover the opponent's king's entire movement area with your pieces.
I'd love to see a version of this game that actually implements this :D
(I guess, Vikings would appreciate the constraints arising from infinitesimal granularity movement.)
I made a post to this effect: https://news.ycombinator.com/item?id=34377233
For example, "Not Tetris" is an analog-Tetris. https://stabyourself.net/nottetris2/
I certainly enjoy these games. So hopefully more people are inspired to find analog-versions of other discrete or turn-based games, lol.
I guess a more "serious" version of analog Tetris is perhaps Tricky Towers, which is an excellent party game. https://www.trickytowers.com/
"To run the code you will need to install Python and the PyGame library, and then run the latest .py file because I can't be bothered to actually use version control."
Or just clone the same repo multiple times, or have some releases unpacked outside of version control.