Show HN: Chess Twist | Hacker News Reader

Show HN: Chess Twist

polyreplay.com

29 pointsfrading36 comments

I continue my experiment of transposing classic games onto an irregular grid. I've previously released variants of minesweeper and checkers. And now I'd like to share my variant of Chess.

Chess can be a pretty punishing game, but I thought this was nevertheless a way to make it even more challenging by making it trickier to anticipate your opponent, even though both players still have the same information.

From the playtests I've done, that challenge is pretty compelling.

It also seems to be more fun at 2 people, where both players keep surprising one another.

Open articleView on HN

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

great to hear, thanks a lot!

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.

I just fixed the castling bug. Thanks a lot for letting me know.

So in this version the bishops can change the color they can move on?

The corners with 3 and 5 neighbour have a special mark. What does that mean?

Can you share how the board is generated or it's part of the secret special sacuce? I think a blog post about the generation of the borard with a few nice graphics can get a lot of traction here.

> So in this version the bishops can change the color they can move on?

It's more that black and white colors don't apply anymore in a grid like this. Since there will be places where more than 4 tiles can share a same corner, you need more than 2 colors.

So here, colors are only used for cosmetic reason, to differentiate the tiles from one another.

That said, I've tried to keep the essence of classic chess where I could. And it's totally possible on the sides of the board, where it's guarantied to always have 8 tiles touching a side with a full edge. So for those, I'm alternating white/black and positioning the king and queen on the expected colors.

But as soon as there is a corner with more (or less) than 4 tiles, the color assignment needs to adapt and that trickles down to the rest of the board. So in most boards, I need 3 or 4 colors, and in some cases I need 5 (but maybe my algo could be improved to limit that number).

> The corners with 3 and 5 neighbour have a special mark. What does that mean?

The red marks (which I call red wall) highlight where only 3 tiles are connected. And the blue ones (which I call blue pivots) highlight where it's 5, or even 6. They each generate different strategies.

For the red wall, each tile that is touching it has a missing diagonal. So it acts like a wall, especially for the bishop and queen, but also the pawn. This wall can be great for defense. Or for rooks, this can be great for attack, as you can target 2 parallel lines from there [1]

For the blue pivots, you have the opposite, as you have more than 1 diagonal. So if you have a bishop, it can go in 2 directions from this corner.

I invite you to try the tutorial that opens up when you load the demo, it has a couple steps which illustrate those. Or maybe you have gone through it, and it's not clear enough? I'd be very happy to hear any feedback on this. I have a feeling this info could be more obvious, and that may not be the case yet.

And for the board generation, I'm completely open about it. It's actually inspired by a game called Townscaper, and the author generously shared how he made it. I'm merely running with it.

I've just written this short explanation on r/proceduralgeneration [2], which I'm copying it here:

-------

The game is built using Threejs, Vuejs, and Polygonjs (my own 3D engine based on threejs). You can see examples of scenes where this type of grid is created [3] and the core library is open source here [4]

You can also see the code for the most important node, called quadrangulate [5] In short, it takes a bunch of triangles, and convert them to quads by grouping them in pairs.

This conversion is straightforward when the triangles are neatly aligned and you process them in order, and the output would then be a very regular grid. But if you process them out of order, you will en up with isolated triangles that have no more neighbouring triangles. Those can't be converted to a quad. But if you subdivide the whole thing, you then get an irregular grid like the one above.

-------

What I forgot to mention is that after the subdivision, you may also need to apply a smoothing, or squarification, where you iterate several times of the whole grid to transform the tiles from a rhombus to be more like squares.

And you're absolutely right, I should do a blog post about it. It's a question that comes up very often as well, it could do with a central place. And I'd love to see more people using this system, as interesting mechanics emerge from it.

[1] https://x.com/fradingue/status/1796892307523830068/photo/2

[2] https://www.reddit.com/r/proceduralgeneration/comments/1d5np...

[3] https://polygonjs.com/gui/irregular_quad_relaxation/edit

[4] https://github.com/polygonjs/polygonjs

[5] https://github.com/polygonjs/polygonjs/blob/master/src/engin...

> 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 the top. You may add another link at the bottom for people like me that skip the headers. I'll try later.

---

About the new strategies, in human vs computer the knight forks are probably more OP than a bunch of blinkstackers with infinite APM. I'd trade a rock or even a queen for a knight just to give my brain some rest.

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 APM

There are too many words I don't understand here to infer your meaning. The knight forks I know are when a knight threatens the king and another piece, but it looks like you mean something else. It could be related to what I mentioned with multiple diagonals, although that does not affect knights. And OP is probably not original poster. And I don't know what bindstackers or APM are (maybe Actions Per Minute?).

But it does look like you know more about chess than I do, so I'd love to absorb that knowledge.

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

ah yes, that's a bit clearer now :) And I'm glad that I used to play starcraft before google decided to be involved.

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

Feature request: Play again in the same checkboard. I got a checboard with two wall that blockd my bishops and the computer got a regular grid. I want revenge!!!

Feature request?: Symetric maps (like in Starcraft 2).

Does the bot run in the server or in my computer?

Feature request?: The hard bot takes too long to play. Can it make a ping when it plays. Does chess.com make a sound, or they decided it's a bad idea?

Thanks a lot for those feature requests, and most importantly for playing!

> Play again in the same checkboard

You can indeed get your revenge. When you start a new game, you can change several option. One of them is how the next board is selected. You can either:

- keep the same board - pick one from a curated list - or generate it randomly

By default, it is set on the 3rd option, but you then need to change it to the first one ("Same Board"), like in this video: https://imgur.com/a/sq8TDbx

> Symetric maps (like in Starcraft 2).

That's not possible at the moment, but someone else had the same request, so I'll have a think. I personally prefer boards that are very irregular and therefore asymmetric, but I appreciate it's subjective.

In the mean time, when you select a board the from the curated list, you can see 5 board types: "very irregular", "regular vs irregular", "almost regular", "regular" and "central pivot". This last one will have boards that are fairly symmetrical (but not completely).

> Does the bot run in the server or in my computer?

It runs on your computer. It's all javascript, running in workers. If the game has a decent success, I'd like to take the time to do a rewrite in a different language to get it in wasm, as it could run faster.

> Can it make a ping when it plays

You should hear the sound of the piece being moved, like in this video: https://imgur.com/a/XoWIJZb If you don't, the only reason I can think of is that the game audio has been turned off, via the button at the top right of the screen?

I'm not sure what chess.com does now, but I believe using a audio hint is really useful for exactly the reason you encountered. And it's even more needed when playing multiplayer without a timer, as your opponent could take even longer to play.

I won against the hard bot :)

Add a confirmation to the resign button!

Can you add a permalink to share the game with my friends so they can see the replay?

(In one moment, the bot atacked my rock with a bishop, and the rock was totaly traped in the corner between the pawn and the knight :(. But after a few minutes of thinking, I used a magical curved path of my far bishop to stop the atack. It was very surprising to be able to save the rock.)

Permalikt to checkboard may be nice too.

When the bot is hopeless (like a rock and two knight down) it makes too many silly moves. Probably all the moves have 0% chance of wining, so it can't pick the best one. Perhaps a counting the pieces heuristic may at least avoid the very silly moves.

(In one moment, the bot could eat a knight, but it just moved the king away instead.)

> I won against the hard bot :)

Congrats! Although I wish it had given you an even harder time!

> Add a confirmation to the resign button!

Yes, you're right, it is much needed.

> Can you add a permalink to share the game with my friends so they can see the replay?

Yes, that would indeed be very useful. I'll see how I can make it work. And maybe there is a way to have it so that it works also for the iOS and steam versions.

> Permalikt to checkboard may be nice too.

Absolutely. That's on my list. (although bear in mind that the demo only has 2 different boards)

> I used a magical curved path of my far bishop to stop the atack. It was very surprising to be able to save the rock

Nice. Thanks a lot for sharing this one. Those are indeed the great reversal moments, I love those.

> When the bot is hopeless (like a rock and two knight down) it makes too many silly moves.

There are many factors that drive how the bot behaves. There clearly is room for improvement, although that will probably need a rewrite in wasm, and most likely need someone who has more experience at this than me. Although I could only hire someone if it makes financial sense. Something I keep thinking about.

And I'm still going through some of the feedback I received, so expect an update in the week or so.

Very cool! Looking forward to playing it.

I suggest to minimize visual clutter, because any new player's brain will be overloaded trying to figure out a board, and less is sometimes more.

I'd remove the forward direction triangles where they can be unambiguously inferred from the baseline. A lower grain contrast wood texture might be a good idea too.

You mentioned you sometimes use five tile colours but you can probably improve it: yes, the four colour theorem guarantees that :)

Yes, minimizing clutter was a priority, and still is. I've tried to avoid those arrows for a long time, but the pawn movements wasn't clear enough without them. And I agree it's not the optimal display.

Displaying them on some tiles only is something I have not thought of. My first reaction is that it may feel harder to read, as tiles with an arrow may look like they would act differently than those without? We may induce the idea that it has a different purpose. So for now, I'd prefer a solution that would look the same on all tiles, I think that's much easier to parse. But then I should probably give this a try before rejecting it.

You do have a good point regarding the wood texture, I've tried other textures, but couldn't find a better one yet. But I'm sure that's possible. Nevertheless for now, you can also display different skins: https://imgur.com/a/zitKlpz

And thanks a lot for mentioning the four colour theorem. I'm looking at its wikipedia page now. I'm sure I came across it many times before, but I did not think about it when tackling this part of the problem. My implementation is here is anyone can spot my mistake: https://github.com/polygonjs/polygonjs/blob/master/src/engin...

The five-colour theorem was first proven in the late 19th century. The known proof of the four-colour theorem is non-surveyable. There's probably no small mistake in your implementation, and the solution you should go with is unlikely to be a fully-general algorithm. (I'd suggest starting from the border on the outside, greedily filling in as many choices as are forced (up to isomorphism), then randomly choosing a candidate breadth-first or depth-first until you've found a four-colour solution.)

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 be an easy modification.

After that, I do go breadth first. But I do so by looking at all neighbours of the current tile, simply by taking them in the order given by my internal graph. Instead I should just take those that are connected to another tile that has been already visited.

So thank you for those advice, that's super helpful, I really appreciate. I had to look up "non-surveyable" as well, I'm learning a lot here. That said, I'm having a hard time understanding "as are forced (up to isomorphism)", is that something you could clarify?

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" choice you make could be the same colour as you chose last time, or a different one, so it is actually free (so isn't forced).

Since the "swap green and purple" operation is bijective (a one-to-one, reversible mapping), and preserves all the properties we care about, we can call it an isomorphism. If there's an isomorphism between two solutions, we say that those solutions are isomorphic. Swapping all the greens and purples of any isolated region of the graph (i.e., one surrounded by a strip of black and white) is an isomorphism, if the only property we care about is "is this a colouring of the original graph?".

I was saying it's pointless to search isomorphic solutions if you can help it. If you have isolated regions of the graph yet to be filled, you can halve the time it takes to explore each region's possible colourings.

However, if you consider isolated regions completely separately, you can solve them one after the other (and backtrack once you know any region's been made impossible by the choices of colours in its border), for a much larger speedup.

The whole thing about isomorphisms was a red herring, an artefact of my thought process rather than an actual insight. I doubt trying to exploit this will net you anything more than a 2× improvement, and that's only if you do it cleverly.

ah I think I understand now. Thanks a lot for clarifying.

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.

Making Go Twist is a bit more straightforward, since the rules work unchanged for any undirected graph. Such as this diamond lattice [1] in which inner points still have 4 neighbours.

[1] https://en.wikipedia.org/wiki/Go_variants#/media/File:Virgil...

Ah that's interesting, thank you. Especially as Go is the one I'm the most unsure about, mostly because I've rarely played it. I have a feeling that making a semi-decent bot is going to be extra difficult. Or at least I'll need a better intuition of what a good bot would do first.

Pawns should probably have a piece that indicates their orientation. As far as I can tell it is impossible to discern which way a pawn moves without querying the ui.

There are those little black and white arrows on each tile, which indicate which way is forward for a specific player. Does that help? Or maybe you saw them and you mean something else?

Interestingly, someone here mentioned that those arrows add a lot of clutter, and someone else on twitter said they only noticed them after I pointed them out. It's interesting how people perceive things like that so differently.

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.

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

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.

I get the dillemma, but I don't think it's a problem that the string of squares used to define "foward" isn't always the same as path the pawn will actually take if it chugs along.

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.

Thanks a lot for insisting of this, and that end up convincing me. I describe the change in the sibling comment: https://news.ycombinator.com/item?id=40634675

That was super useful. So don't hesitate if you have any other feedback.

The first image shows a rook traveling a path different from the one shown in the arrows though? Why would the definition of forward be different for a pawn vs rook?

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 other side. Then remove the forward indicators and just make the pawns statefully indicate their direction.

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

Well what I’m saying is you should make the pawns themselves have an appearance that denotes the direction they are facing (e.g. a bit pointy or just slap an arrow on them). That way you do not need to know their starting position in order to understand their current state. This way you can also remove the arrows indicating tile direction.

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

oh that is interesting, I haven't thought about changing the appearance of the piece to convey more info. That's definitely something worth exploring.

And I agree as well that pawns changing track when they capture can be a fun one. It could even make you reconsider a capture if the pawn is on a good track and would end up on one that turns to the side.

I'm not promising I'll change the current behavior, but that does make me think.

I kept thinking about it, did some tests, and you convinced me. So the pawns movements are now changed. It works like that now:

- pawns move forward in their "track", just like a rook would do, just one tile at a time.

- if the track reaches the end of the board, the pawn can promote as usual.

- if the track ends on the left or right side of the board, when the pawn reaches it, it changes track. If there are multiple tracks it can take from there, the one that reaches the end in the least amount of moves is selected

- when a pawn captures, it changes track following the same rule.

And I agree now that using capture to change the zone of attack of a pawn is a very nice addition.

On top of that, if multiple pawn are constraint to turn sideways at first, it's not simply a handicap. It also helps strengthen the defense in that area, as you can have more efficient pawn walls.

In all all, it's great, thanks a lot for arguing in favor of this change.

Reply on news.ycombinator.com