Hey hey.

I'm still working on the feedback received from the demo last week.


One that stood out was regarding the movement of the pawns. My initial reaction was not to change what was already in place, as it seemed to me to be working just fine.


The way it worked was that the pawns would follow the exact same rules as classic chess, which is that they can only move forward. And the forward direction in the boards generated here was toward the edge of the tile that was the most facing the opposite end of the board. One drawback of that is that some tiles are placed in a way that makes it hard to see which edge it is. So I added arrows on every tile to show that direction.

It worked, but it also made the board visually cluttered. That's no good.


The suggestion that was brought up to resolve that is to make the pawns not move forward, but instead follow the track on which they start, similarly to a rook.

If that tracks reaches the opposite end of the board, it's great, the pawn can promote to a piece just fine. But if the track does not reach it, and instead reach the left or right side of the board, then the pawn can turn and follow the next track starting at that tile, until it can then reach the opposite end.


And if the pawn captures, it automatically changes track. Although that's where it can get ambiguous, as there can be multiple tracks it can follow. When that happens, the track that can reach the end with the least number of moves will be the one.

And there are actually cases those multiple tracks can reach in the end in the same number of moves. In those rare cases, the pawn will have a choice on which it can take when it moves.

Phew, it wasn't an easy update. But it should hopefully make more sense when you play it.


Now, it still isn't clear which direction pawns can move when you just look at the board. You still need arrows. But a good news is that we don't need arrows on every tile. We only need them where the pawns are.

So I've experimented with a few designs before settling down on one.

A first attempt was with an arrow that would be showing the direction from the pawn itself.

But that felt messy and hard to read. So maybe by adding a more pronounced arrow?

But no, it still feels untidy.

So I went back to the arrows we previously had everywhere, and simply used those.

This way, those arrows feel neatly tidy against the edge of the tile.


Another request was to have symmetric boards.

There was 2 reasons for this request:

- 1. to have boards that would not advantage one player over the other
- 2. to make prettier boards

Now, I still disagree with the first reason, as the features in our twisted boards do not necessarily give an advantage to one player more than the other. They can be used for both attack and defense, and therefore are great for both players.

But 2, I can agree to that, there is a pleasure in symmetry. And that by itself was a good enough reason to add.

So it's here, although it's not available in the demo just yet. You'll have to wait for the release. But here is how it will look:

That's it for now!

Last week end was a blast, the demo got popular on twitter and reddit. Thanks a ton to everybody who played the game, and especially to those who took the time to provide feedback.

So here are fixes for 3 issues that got mentioned:


The previous textures used for the board were too contrasted. This was a bit distracting and made the board not as easy to read as it could be. So I looked at this again, tested with several new textures, tweaked some colors and we now have something that is a bit more muted, while still preserving the wood look.

You can see in this screenshot the previous one on the left, and the new one on the right.


Many players were eager to start playing when opening up the game, and skipped the tutorial. Honestly, I completely understand, I often do the same. But some skipped it so fast they didn't realise there was a tutorial at all.

So I've added a more prominent button, to at least let you know that there is one, and that it may be useful to read it through. This way, you can at least start it when you want.

Although this doesn't change the fact that tutorials are pretty boring. Ideally there would be no need for one. Or at the very least, information would be slow dripped to the players without interrupting the flow. But since here you need to know how each piece can move from the start, it still feels like a dedicated tutorial is hard to avoid.

We'll see, maybe there is a better way, I'm still thinking about it.


In chess, there are a bunch of criteria on wikipedia[en.wikipedia.org] that defines if castling is allowed or not. When I implemented this move, I looked those criteria up to be extra sure of what I had to put in code. And I looked them up again. And again. And then I was pretty sure I got that right. But turns out I got overzealous and added a rule that did not exist! That invented rule was that you couldn't castle if you had been in check before. Thankfully a kind player pointed it out. So I removed that, and now you can properly castle following the official chess rules.

That's it for now. There is more feedback I'm thinking about and which may or may not make it in the game. We shall soon see!