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.
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...
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.
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.
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...
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.
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 :)
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...
[1] https://en.wikipedia.org/wiki/Go_variants#/media/File:Virgil...
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.
Maybe pawns could just move horizontally/vertically and attack diagonally, regardless of color?
