21–30 of 38 posts
One small note: I tried to castle, and was told "Castling is not allowed because your king was previously in check."
This isn't one of the rules of castling in regular chess. [1]
Also, it would be nice to implement the three-same-position draw, since I got trapped in a cycle of just moving my king back and forth forever.
1. https://en.wikipedia.org/w/index.php?title=Castling#Requirem...
Earlier quoted context omitted.
> I need 3 or 4 colors, and in some cases I need 5 4 should be enough https://en.wikipedia.org/wiki/Four_color_theorem , but the alternating color in the border may be a problem. It's an interesting variant for nerdsniping. I guess it's possible to find a 4 color version but it may need too much backtraking. --- > I invite you to try the tutorial that opens up when you load the demo I didn't notice. It's linked at th…
Yes, someone else here mentioned the four color theorem, and that gave me a few ideas to improve that. For the demo, it actually opens up when you start the game. But it's possible to skip it, which is totally fair, I should have expected that. I'll make the button more obvious, you're absolutely right that it's too hidden at the moment. > knight forks are probably more OP than a bunch of blinkstackers with infinite…
Sorry, I watched too many videos of StarCraft 2. OP means Over Powered, i.e. an strategy that is imposible to beat.
% years ago, Google made an AI bot to play StarCraft 2, and they made a demo against two proffesional players. The bot was "cheating" so the bot has vision of the whole map, and the bot could make as many "clicks with the mouse" as it wants (APM "action per minute").
The bot discovered an estrategy that was to create some robots with lasers "stalker" that can shoot from a distance, so many of them can atact the same unit. And use an upgrade "blinck" so they can teleport a short distance. So the bot could make all of them atack and pick the hurt units and teleport to the back so the heal while continue atacking.
A human can only manage 5 or 10 of them together, and there is a high chance of forgeting to send one to the back. The bot used like 30 of them, atacking from different angles.
There is a video with clips of the game. The most clear fight were the bot (in blue) use the trick is https://www.youtube.com/watch?v=6EQAsrfUIyo&t=510s
---
I tried the demo. The default player is too weak. It makes too many silly mistakes. The harder players is hard. I'll try again tomorrow.
(The bishops that bounce against the walls when there is a corner with 3 squares in the border are weird. Also, bishops are too easy to block by "walls". I like knights better.)
This is very cool, I'm enjoying it. One small note: I tried to castle, and was told "Castling is not allowed because your king was previously in check." This isn't one of the rules of castling in regular chess. [1] Also, it would be nice to implement the three-same-position draw, since I got trapped in a cycle of just moving my king back and forth forever. 1. https://en.wikipedia.org/w/index.php?title=Castling#Requir…
Thanks a lot for the correction regarding castling. I did look up this page a fair bit when implementing this, and I swear I had seen the rule that castling wasn't possible if the kind had been in check. But looks like I was dreaming. So I'll fix that shortly.
For the three-same-position draw, yes, it's on my list. It was really low priority, but your comment makes me move this up the list. I had improved the bot so that it would be better during the end game, thinking that would avoid the need for this rule, but it looks like that doesn't work all the time (which shouldn't be surprising). So yes, I'll work on that as well,
That's great feedback, thanks a ton.
Earlier quoted context omitted.
It might be worth considering just changing the rules for the pawn to deal with this. It's hard to tell what it means to move "forward" on a board like this, even after understanding the indicators. Maybe pawns could just move horizontally/vertically and attack diagonally, regardless of color?
That's an interesting suggestion. The pro is that it will simplify things, remove visual and cognitive clutter. The con is that we stray away from classic chess rules, which I'd still like to avoid as much as possible. I will think about it. It may be possible to allow as an option.
Perhaps define forward as the direction(s) which, when extrapolated as a rook, would reach the opponent's backrank. If it doesn't exist, the direction(s) which, when extrapolated, terminate on the opponent's half. This would allow extra freedom to pawns in some funky topologies that can occur in your game, but generally follows the principle of least surprisal.
Earlier quoted context omitted.
actually, I realise now that the implementation I shared in my previous comment is a generic one. At some point, I decided to make a variation of it, specialised for this board. The reason wasn't the number of colors, though, it was to have better control of the colors of the bottom and top rows. And I also realise that, contrary to what I said above, I do not set the colors on the left and right sides. So that will…
Let's say your colours are black, white, green and purple. So far, you've managed to use only black and white, but you've reached a node with both black and white neighbours. You need (are forced) to choose a different colour! You could choose green, or purple – and whatever solutions you reach from that point, you could swap all the greens and all the purples to yield another solution. However, the next "free" choi…
Although I'll have to re-read you when I rework the implementation. But in any case, the operation is already done very quickly, so I've never thought about monitoring it. So any performance improvement on it isn't a high priority. There are other operations in the full grid generation that are more time consuming, like the smoothing/squarification, which needs to be applied multiple times. But even then, since the grid is so small, the whole thing takes less than a second.
That said, I'm thinking of ways to improve the menu where players select the next board. Right now, when you want to generate a random one, I only display one. But it could be nice to display multiple ones. In which case 1 second generation becomes X seconds. So if I do that, any speed up could be welcome.
Earlier quoted context omitted.
I classic chess, the rooks can move in any direction. Forward, backward and sideways are allowed. The pawns are the only pieces that are limited to forward movements. So the arrows are only necessary for the those. Or maybe I'm misunderstanding your question?
In this image we are seeing the two paths this took can take (“left” and “forward”). But forward is not the same as a pawn’s forward. The pawn would, about halfway down, “turn” away from the rook’s path https://polyreplay.com/games/assets/chesstwist/description/s... Personally I think the rook makes intuitive sense as shown. I would vote for the pawns following the same path even if it means they cannot reach the oth…
The way I see it, is that for a rook, it is easy to know which path it can follow. You simply take it's current position and allow it to move to any neighbor tile sharing an edge, and then the opposite tile, and the opposite again, and so on.
For a pawn, it can also move to neighbor tile sharing an edge, but there are multiple ones, and only one is allowed. So how to you define which it is?
If we were to say, as I understand is what you suggest, that it will follow the same path as a rook, here is the problem that I see. If it was in one of those tiles you mention, we can't infer which path a rook would take from the pawn current position. We would instead need to know its starting position. And by just looking at the board in a given state, the pawn could come from 2 places ( see https://imgur.com/a/sExTqsP ). So that would require the player to always keep in mind which pawn comes from where. Which I think is really hard. Especially for games with no timer, as those could last days.
I'm much more in favor of a definition of forward which is comprehensible by just looking at the board, without having to think about the starting point. Which is why for now I've settled on using the direction of the tile edge. Even if there is a non-negligible cost of visual clutter.
Also, I'm quite keen on preserving the fact that all pawn can be promoted to a piece when reaching the opposite edge. As soon as you know that a pawn can't do that, they lose a lot of their threat potential.
But I don't want to close off this idea. It does make me think, and I'd be happy to be convinced otherwise. And it could very well end up as a variant inside this variant!
Earlier quoted context omitted.
That's an interesting suggestion. The pro is that it will simplify things, remove visual and cognitive clutter. The con is that we stray away from classic chess rules, which I'd still like to avoid as much as possible. I will think about it. It may be possible to allow as an option.
Your constraint should be that if the board is the special case of regular chess, the game should play exactly the same. Allowing the pawn to move towards any side is too much because it would violate this principle. Perhaps define forward as the direction(s) which, when extrapolated as a rook, would reach the opponent's backrank. If it doesn't exist, the direction(s) which, when extrapolated, terminate on the oppone…
I'm still unsure, as I describe in my reply there, an issue I see is that you can't know the path a pawn would take, unless you know where it comes from.
But since both of you reached the same solution, I'll keep thinking about it.
Earlier quoted context omitted.
Yes, someone else here mentioned the four color theorem, and that gave me a few ideas to improve that. For the demo, it actually opens up when you start the game. But it's possible to skip it, which is totally fair, I should have expected that. I'll make the button more obvious, you're absolutely right that it's too hidden at the moment. > knight forks are probably more OP than a bunch of blinkstackers with infinite…
> There are too many words I don't understand here to infer your meaning. Sorry, I watched too many videos of StarCraft 2. OP means Over Powered, i.e. an strategy that is imposible to beat. % years ago, Google made an AI bot to play StarCraft 2, and they made a demo against two proffesional players. The bot was "cheating" so the bot has vision of the whole map, and the bot could make as many "clicks with the mouse" a…
> I tried the demo. The default player is too weak. It makes too many silly mistakes. The harder players is hard. I'll try again tomorrow.
Thank you for playing it. And that's great, that's more or less how I intended. I want players to start with a bit that isn't too intimidating, so that you can select a stronger one after if needed. And I'm glad that the stronger one gave you some challenge.
> The bishops that bounce against the walls when there is a corner with 3 squares in the border are weird
Currently, I define a diagonal as 2 tiles sharing a point and no edge. So by that definition, you will indeed see tiles on the edge which make up a diagonal. Definitely the type you can't see on a regular board. There could be an alternative definition where you need to have 2 other tiles that share edges with those first 2 tiles (as is the case almost everywhere inside the board), but I like to embrace the weirdness that this brings, so I keep the first one.
And yes, knights here are much harder to predict!
Earlier quoted context omitted.
Your constraint should be that if the board is the special case of regular chess, the game should play exactly the same. Allowing the pawn to move towards any side is too much because it would violate this principle. Perhaps define forward as the direction(s) which, when extrapolated as a rook, would reach the opponent's backrank. If it doesn't exist, the direction(s) which, when extrapolated, terminate on the oppone…
yes, GP reached the same conclusion as you. https://news.ycombinator.com/item?id=40550176 I'm still unsure, as I describe in my reply there, an issue I see is that you can't know the path a pawn would take, unless you know where it comes from. But since both of you reached the same solution, I'll keep thinking about it.
This only happens when there's no straight path to the opponent's backrank, so you are allowed to go "sideways-foward" until you hit a square from which there is a clean forward path again.
Agreed that the past should not matter, only the current position.
Earlier quoted context omitted.
In this image we are seeing the two paths this took can take (“left” and “forward”). But forward is not the same as a pawn’s forward. The pawn would, about halfway down, “turn” away from the rook’s path https://polyreplay.com/games/assets/chesstwist/description/s... Personally I think the rook makes intuitive sense as shown. I would vote for the pawns following the same path even if it means they cannot reach the oth…
I think I see. You mean those tiles, is that correct? https://imgur.com/a/YHSYjSe The way I see it, is that for a rook, it is easy to know which path it can follow. You simply take it's current position and allow it to move to any neighbor tile sharing an edge, and then the opposite tile, and the opposite again, and so on. For a pawn, it can also move to neighbor tile sharing an edge, but there are multiple ones, and…
I think pawns changing from being relatively worthless because they’re not on a promotion track to very dangerous because capturing a piece has allowed them to shift into one is pretty fun actually. Diagonally capturing a piece would also occasionally cause the pawn to “turn” which would be a really Tricky change in its zone of attack