Moved!

Well, that didn't took all that long. I was worried because, honestly, I'm not much of an administrator. There are still some loose ends, of course, but nothing that should impact on a daily development. So, new repository is hosted at Codeberg: https://codeberg.org/mmlacak/crochess.

Old repository on GitHub at https://github.com/mmlacak/crochess was updated with new location, and then it was archived. Old repository is not mirrored, so it won't receive any further updates, but will be kept as read-only.

For now, this blog will stay as-is, I don't have much new content for it. You see, I thought I'd write in great detail about intricate design choices I made in code. Turns out, writing in great detail requires quite a bit of effort and time, if you want to introduce designs, and thinking behind them properly. Even worse, when I tried to actually write something, sooner rather than later I ended up with obsolete text, since in the meantime I also changed source code.

For instance, I wanted to write text describing CcPathNode, which is a building block for all possible paths traversed by a piece in a ply. Before I finished it, I removed subs link, because to compare each path in a tree with user notation I had to assemble complete path from root node down to ending leaf node, resulting in CcPathLink linked list. Substitute side-effects were used for displacements, e.g. every time a Serpent encounters a Pawn, there might be multiple valid choices, which do not alter moving piece path (e.g. Serpent in this example).

To prevent tree from eating all available memory, I made a simple linked list effectively just for displacements in CcPathNode. Problem is that substitute side-effect does not belong to any particular step, and so might end on e.g. the last one. Serpent can displace Pawns in each of its steps, so each CcPathNode would carry only one step (so that displacements list can be connected to their rightful step), which would be quite wasteful.

Moreover, choice made is not known in advance, so all choices has to be carried over for comparison, while still being attached to their proper step. Because user notation and generated paths share more-or-less the same data, the same struct is used for both. So, I had to add list of possible displacements to a CcStep, rendering list in CcPathNode obsolete, and so original subs list was removed. So, now each step in a ply could have either a displacement (for user notation) or a list of tentative displacements (for generated path tree). And then, after I finished changes, I recalled that Serpent has two choices after each step, so each CcPathNode in its tree will always contain only one step anyways, and with no bounds its path tree could contain up to 524,288 nodes, at 60 bytes each, giving a grand total of 30 MB ... so much for preserving memory. There are displacements in trance-journey, though, so not everything is lost 😅.

This explanation isn't very good, but you get the idea how difficult it is to convey the reasoning behind some design choices. Problem is, code is riddled with such intricate decisions, and sometimes I'm not even sure what is the best approach at times, until I try to do something, and then it turns out it has to be changed. On top of that, I have to write and maintain documentation (even if it mostly just enumerates what functions, macros exists with very little explanations) because it might also contain valuable warnings, concepts explained, without which I'd be also lost at code, with no navigation helpers.

So, now you can see why blog will mostly contain announcements when new book update is available, or when application goes live. LinkedIn group will also stay as-is, with mostly just links to blog posts.

Moving (closer to) home

I have been using GitHub to host my online repository for over a decade now. The problem is that I'm getting errors -seemingly at random- like this one:

Too many requests

You have exceeded a secondary rate limit.

Please wait a few minutes before you try again;
in some cases this may take up to an hour.
Signing in may provide a higher rate limit if you are not already signed in.

For more on scraping GitHub and how it may affect your rights, please review our Terms of Service.
Contact Support — GitHub Status — @githubstatus

even if all I did was try to access a page with my own commits. Even more infuriating, those errors now  persists even if I delete all the cookies.

Also, in not-so-distant future (I hope!) I might want to use CI/CD. However, broken GitHub implementation was one of the reasons why e.g. Zig moved over to Codeberg, and I'm inclined to do the same.

So, I'll be moving my online repository to Codeberg, and also primary email and probably even this blog. In short, there will be delays before I can continue development. In theory, it should be simple to switch from one online git host to another; in practice, there is a difference.

Home? you ask. Well, this time around I'll prefer European services, preferably non-profit.

Last edit: 2026-01-26 8:31 UTC

No guessing, only counting

Newly introduced randomized variants also pose a good question: how much there are different initial setups? Let's calculate!

Note that randomized Classical Chess variants and randomized Croatian Ties variants of the same size has the same number of possible initial setups. In Croatian Ties variants Knights are replaced by Pegasuses, but otherwise number of different pieces and their count is the same. Pawns in all variants are irrelevant, since they can be arranged in only one way. So, the only difference is the order of figures arranged in the first and last rank. Both mirrored and symmetrical flavors of randomized variants has the same number of combinations, so it's enough to calculate only once, then double the result.

First, a very brief introduction to binomial coefficients:

$$c=\left(\genfrac{}{}{0ex}{}{n}{k}\right)=\frac{n!}{k!\cdot (n-k)!}$$

where $n\ge k\ge 0$, and $n!=n\cdot (n-1)\cdot (n-2)\cdot ...\cdot 2\cdot 1$.

Our factor $c$ is number of combinations when placing $k$ pieces of the same kind (e.g. 4 Rooks) onto $n$ available fields (e.g. 10 empty fields).

So, we'll start with randomized Classical Chess 14, and with Bishops, since we have to make sure we have the same number of Bishops on light and dark fields. There are 4 Bishops in this variant, so that would be 2 Bishops on light and other 2 Bishops on dark fields. In these variants there are 14 fields at each rank (surprising, I know!), so that gives us 7 light and 7 dark fields. Obviously, each set of light and dark fields is completely separated from each other, and so numbers of possible arrangements of Bishops on different fields are the same:

$$c_{\mathrm{light}}=c_{\mathrm{dark}}=\left(\genfrac{}{}{0ex}{}{7}{2}\right)=\frac{7!}{2!\cdot 5!}=21$$

where $7$ is the number of either light or dark fields; and $2$ is count of Bishops on those fields. So, our factor $c_{\mathrm{light}}$ is number of combinations of 2 Bishops arranged over 7 light fields; and $c_{\mathrm{dark}}$ is the same over dark fields.

Next, we have to arrange 4 Rooks over $14-4=10$ fields, where 14 is size of a variant, and 4 is number of fields already occupied by Bishops:

$$c_{\mathrm{Rooks}}=\left(\genfrac{}{}{0ex}{}{10}{4}\right)=\frac{10!}{4!\cdot 6!}=210$$

Next, we have to arrange 4 Knights over $14-8=6$ fields, where 14 is still size of a variant, and 8 is number of fields already occupied by Bishops and Rooks:

$$c_{\mathrm{Knights}}=\left(\genfrac{}{}{0ex}{}{6}{4}\right)=\frac{6!}{4!\cdot 2!}=15$$

Queen can now pick between two remaining fields (ladies are choosers! 😎):

$$c_{\mathrm{Queen}}=2$$

King will have to be satisfied with whatever field is left empty:

$$c_{\mathrm{King}}=1$$

So, our number of combinations for randomized Classical Chess 14 variants is:

$$c_{\mathrm{14}}=c_{\mathrm{light}}\cdot c_{\mathrm{dark}}\cdot c_{\mathrm{Rooks}}\cdot c_{\mathrm{Knights}}\cdot c_{\mathrm{Queen}}\cdot c_{\mathrm{King}}=\mathrm{2,778,300}$$

that is for either mirrored or symmetrical flavor. If flavor is also randomized choice, total number of initial setups is doubled:

$$c_{\sum \mathrm{14}}=c_{\mathrm{14}}\cdot 2=\mathrm{2,778,300}\cdot 2=\mathrm{5,556,600}$$

both those numbers also apply to randomized Croatian Ties 14 variant(s).

Calculation of number of different initial setups for randomized Classical Chess 20 variant(s) -and, by extension, Croatian Ties 20 variant(s)- is the same as above, but numbers are slightly bigger. Size of a chessboard is now 20, there are 10 light fields, and 10 dark fields, there are 6 Rooks, 6 Knights and 6 Bishops (of which 3 are on light fields, and other 3 on dark ones). Taking all into account gives the number of initial setups as:

$$c_{\mathrm{20}}=\mathrm{2,421,619,200}$$

that is for either mirrored or symmetrical flavor. If flavor is also randomized choice, total number of initial setups is doubled:

$$c_{\sum \mathrm{20}}=c_{\mathrm{20}}\cdot 2=\mathrm{2,421,619,200}\cdot 2=\mathrm{4,843,238,400}$$

both those numbers also apply to randomized Croatian Ties 20 variant(s).

Number of different initial setups for randomized Classical Chess 26 variant(s) is calculated the same as above, but numbers are bigger still. Size of a chessboard is now 26, there are 13 light fields, and 13 dark fields, there are 8 Rooks, 8 Knights and 8 Bishops (of which 4 are on light fields, and other 4 on dark ones). So, number of initial setups is:

$$c_{\mathrm{26}}=\mathrm{2,013,316,519,500}$$

that is for either mirrored or symmetrical flavor. If flavor is also randomized choice, total number of initial setups is doubled:

$$c_{\sum \mathrm{26}}=c_{\mathrm{26}}\cdot 2=\mathrm{2,013,316,519,500}\cdot 2=\mathrm{4,026,633,039,000}$$

both those numbers also apply to randomized Croatian Ties 26 variant(s).

As an interesting tidbit, if we try to calculate number of initial setups for randomized Classical Chess, we get:

$$c_8=\mathrm{2,880}$$

that is for either mirrored or symmetrical flavor. If flavor is also randomized choice, total number of initial setups is doubled:

$$c_{\sum 8}=c_8\cdot 2=\mathrm{2,880}\cdot 2=\mathrm{5,760}$$

Obviously, these numbers are somewhat bigger than Fischer Random Chess would have it (i.e. 960), since it also imposes an additional constraint on how initial setups are generated; namely, "the King must be placed on a square between the Rooks", and does not support symmetrical flavor, only mirrored.

New variants galore!

While adding new, simple variants I also thought at the time about adding randomized variants of those, since that is a natural and easy way of improving ones chess variants appeal, without introducing even more complexity; it's what chess designers are inclined to do. Especially if said chess designers have played Fischer Random Chess recently and liked it, because everybody likes randomized Classical Chess, even if they're casual potato just like me, and lost every single game within minutes.

Jokes aside, that's how it played out; I postponed adding randomized variants, since I thought that soon I might be able to finally implement rudimentary support for simple variants in my console application. When it became apparent that I won't be able to pull it off in time, and due to randomized variants being relatively simple, I decided to take the plunge, and do it now. Other reason for adding randomized variants now is they do increase scope of the project somewhat, and it's always better to have scope clear before any real work commences, which is now on the table again.

Why new, randomized Croatian Ties variants all have two ranks of Pawns for each player, while originating, simple Croatian Ties variants have only one(?), I hear you asking. Well, simple variants have fixed positions, and it so just happens that Pawns attacked from the very first move by Pegasuses are also the ones protected by at least 3 different pieces; Rook behind said Pawn, Bishop from the side, and Pegasus beside it. Better, no Queen or King is attacked by Pegasus on its very first move, even if it does capture a Pawn.

In randomized Croatian Ties variants there is no such a guarantee, it's possible to end up with initial setup with undefended Pawns; worse, figures attacked by Pegasus after capturing Pawn might be Rooks, or even Queen, with no escape hatch; worse still, they might be undefended, too. And an unfair situation would be if King itself is exposed in such a way; dark player would be checkmated even before his/hers first move. Fact that initial setup is fair (as in, mirrored or -at least- symmetrical) is of no consequence here, this is not acceptable. So, to prevent Pegasuses from gaining unrecoverable advantage to light player, and give dark player a fighting chance to defend himself, rank of light and dark Pawns had to be added to initial setups.

Sure, at least in theory, it's possible to filter out unfair initial setups, and allow only playable ones; but, it would require more complex randomization algorithm, which has to be very carefully reviewed to ensure unfair setups can't slip through. Then, there is a question where filtering ends, how much of an advantage light player should be allowed? If not much (to keep game fair), then such an algorithm would also kill randomness by severely restricting number of available setups. Also, I'm not really fond of complex designs if it can be avoided, in this case by adding a simple safety net. 

And so, here we are; with only 12 new, randomized variants added to the mix; that makes it 28 variants in total: 10 canonical variants, 6 simple variants, and 12 randomized variants (of which 6 are in mirrored and other 6 are in symmetrical flavor). Since this is quite a change, I'm also updating the book; changes from the last update include:

• clarifying grammar 
• clarified syzygy
• clarified activation momentum
• clarified Starchild's summary, activations
• added piece steps table
• clarified displacement steps
• Pyramid cannot be uplifted anymore
• new, randomized Classical Chess 14, 20, 26 variants, in mirrored and symmetrical flavor
• new, randomized Croatian Ties 14, 20, 26 variants, in mirrored and symmetrical flavor
• tiny fixes, and more ...

The book was compiled on December 12, 2025, version is 20251212.020837, and can be found behind that red button above, or in other usual places.

Last edit: 2025-12-12 17:32 UTC

Updating the book!

As promised, I'm updating the book since I finished planned changes; most notably, Wave cannot activate Pyramid anymore. Reason I removed such an activation is because it complicates things significantly when Pawn, Shaman gets involved (i.e. any piece that has step- and capture-fields separated), for no real gain.

Other changes include simplifying some (visually) complicated examples, rewriting and clarifying some explanations, grammar + some small changes, fixes. While editing it struck me that examples having chessboards cut exactly at fields edge (e.g. chessboard sized exactly 9 x 6) looks unsettling, and kind-a awkward; so I also added partial fields (hints at where rest of chessboard is) to all of those.

Since two months has already passed since the previous update, I'm updating the book; the book was compiled on November 10, 2025, version is 20251110.003215, and can be found behind that red button above, or in other usual places.

Even more guessing!

Previously, I wrote down my guesstimates how much One variant is more complex than Classical Chess, turns out a lot. Now, it's time to do the same for new, simplified variants. I'll do just Classical Chess 26, smaller variants are of lesser interest here. As for Croatian Ties variants, I haven't yet got around how to calculate complexity factor due to increased mobility; so, using previous method Croatian Ties variants would have exactly the same complexity as their Classical Chess counterparts, which doesn't feel right, but it is what it is.

If you haven't already, read blog post linked above; it explains how complexity factors are calculated, and why. So, let's start with size:

$${\mathrm{cf}}_{\mathrm{size}}=1+\ln \left(\frac{{26}^2}{8^2}\right)=1+\ln \left(\frac{676}{64}\right)=3.357310$$

Next, it's total number of pieces on the chessboards:

$${\mathrm{cf}}_{\mathrm{pieces}}=1+\ln \left(\frac{104}{32}\right)=2.178654996$$

There are no new pieces, so complexity factor for different types of pieces is one:

$${\mathrm{cf}}_{\mathrm{types}}=1+\ln \left(\frac{6}{6}\right)=1.0$$

The same applies to Croatian Ties variants, since every Knight is replaced by Pegasus, so there are the same number of different types of pieces.

There are also no new interactions, so complexity factor also goes to one (this one too applies to Croatian Ties variants):

$${\mathrm{cf}}_{\mathrm{interactions}}=1+\ln \left(\frac{3}{3}\right)=1.0$$

Our complexity $c$ is then defined as a product of all factors calculated above:

$$c_{\mathrm{regular}}={\mathrm{cf}}_{\mathrm{size}}\cdot {\mathrm{cf}}_{\mathrm{pieces}}\cdot {\mathrm{cf}}_{\mathrm{types}}\cdot {\mathrm{cf}}_{\mathrm{interactions}}=7.314420189$$

This is complexity scaling factor of regular games from Classical Chess into Classical Chess 26 variant, i.e. all games should be 7.314 times longer. For instance, the longest recorded tournament game was 538 moves (269 FIDE moves, aka cycles), which turns into 3835 moves (1968 cycles) for Classical Chess 26 variant. Average on-line match lasts about 80 moves (40 cycles), in Classical Chess 26 variant that would become 585 moves (292.5 cycles). Average tournament match lasts about 88 moves (44 cycles), which becomes 644 moves (322 cycles).

The same, however, does not apply when calculating maximal possible game length, because players will try to maximize each and every metrics available to prolong the game. So, for maximum game length we have to calculate linear scaling factors; for chessboard sizes factor becomes:

$${\mathrm{cf}}_{\mathrm{size}}=\frac{{26}^2}{8^2}=\frac{676}{64}=10.562500$$

Next, for total number of pieces on the chessboards we have:

$${\mathrm{cf}}_{\mathrm{pieces}}=\frac{104}{32}=3.25$$

Complexity number for different types of pieces is still one:

$${\mathrm{cf}}_{\mathrm{types}}=\frac{6}{6}=1.0$$

Finally, complexity factor for number of different interactions is also one:

$${\mathrm{cf}}_{\mathrm{interactions}}=\frac{3}{3}=1.0$$

Taken together, our complexity $c$ becomes:

$$c_{\mathrm{longest}}={\mathrm{cf}}_{\mathrm{size}}\cdot {\mathrm{cf}}_{\mathrm{pieces}}\cdot {\mathrm{cf}}_{\mathrm{types}}\cdot {\mathrm{cf}}_{\mathrm{interactions}}=34.328125$$

This is scaling factor for the longest possible games, i.e. the longest games should be 34.33 times longer in Classical Chess 26 variant compared to Classical Chess. For instance, previously mentioned 11797 moves (5898.5 cycles) game as the longest possible with 50-cycle rule in Classical Chess 26 variant becomes 404,968 moves (202,484 cycles) game. Even longer 17697 moves (8848.5 cycles) game with 75-cycle rule in Classical Chess 26 variant turns into 607,505 moves (303,752.5 cycles) game.

These doesn't appear to be large numbers, if you recall estimates for One variant, but should not be underestimated; even "just" 7.314 times increase in complexity results in some prolonged games, especially if increase in complexity is allowed to also translate into longer time allowance per turn. So, 15 seconds per player's turn in bullet game now becomes approx. 110 seconds per turn; given that average Classical Chess 26 game length would be 585 turns, it would last for approx. 17.834 hours of gameplay time; or, 2.23 days if we assume 8-hour gameplay in a day. If we don't increase time allowance per turn, 15 second per turn bullet game would take approx. 2.438 hours of gameplay time.

In short, new Classical Chess variants does pose a challange, even if only just by scaling up. Croatian Ties variants builds more on top of that challenge, by replacing Knights with more mobile siblings, and also allowing Pawns to move sideways, which throws off known gameplay patterns, tactics.

New variants finished!

Well, that was surprisingly quick, but all new variants are done, including Summary. To be fair, I was  being overly cautious, thinking of what took me to finish Miranda's Veil. Turns out, simplified variants are simple, most additional stuff (in Summary) has already being done, and just needs a little edit, here and there.

Since new, simplified variants are quite a chunk, I'm also updating the book; changes include:

• fixed displacement notation examples
• fixed side-effect summary spacing
• fixed typos (thanks to @RainRat)
• new Classical Chess 14, 20, 26 variants
• new Croatian Ties 14, 20, 26 variants

The book was compiled on September 8, 2025, version is 20250908.191123, and can be found behind that red button above, or in other usual places.

New variants!

Quite some time ago I wrote that I'd like to add some enlarged, but otherwise Classical Chess variants, but dismiss them as not belonging to the book, and requiring their own, separate book which would also discuss mobility. In the meantime, I kinda warmed-up to the idea that enlarged Classical Chess variants do belong to the book presenting new variants, especially since their objective is to make playing on large chessboards more approachable to average, casual player.

Currently, I plan on adding enlarged Classical Chess and Croatian Ties variants as remarks at the very end of the book; those variants won't be fully featured, but will include images. I'm not entirely happy with this design choice, since it will disrupt the flow of the book; but it should be worth it, given that this new book on mobility and such is still very far away, if it will be written at all.

I plan on adding 3 new Classical Chess variants, those will feature only pieces found in Classical Chess, with exactly the same rules, except longer rushes and castlings. I'll also add 3 new Croatian Ties variants, those would be nearly identical to their Classical Chess counterparts, but all Knights would be upgraded to Pegasuses (Pegasi?), and all Pawns will be of side-ways variety; this is to compensate somewhat for decreased mobility of Pawns, Knights on a larger chessboards. New variants will be played on 14 x 14, 20 x 20 and finally 26 x 26 chessboards.

New variants won't bring neither any new pieces, nor any new interactions. Still, I'll have to expand Python application which generates images for the book to support all new variants; later, library will have to be expanded as well. This will take some time, given my usual tempo of writing (which is very slowly) I hope I'll have the book finished by the end of this year.

Join us at LinkedIN

As is a standard trope with older (software) engineers, I'm also bad at socializing, online and off. It's not that I'm internet illiterate, quite the opposite, but somehow casually connecting with strangers is one of my Achilles' heels. Maybe the issue is that I grew up in an disjoint world where each and every service stood only on its own, and rarely had been linked to another. Or, maybe it's that I value privacy, but data gathering and profiling is so prevalent that I have no desire to engage.

Anyway, here it is: a link to Croatian Chess group at LinkedIN; it's still a small, cozy group, with even smaller amount of posts (hey, if you join, you could improve things!). Usually I post when there is something new or relevant to Croatian Chess; usually it's about the most recent blog post. The group itself is not dedicated strictly to Croatian Chess; all posts about all chess variants, and chess in general are welcome, memes included. If you join, please avoid controversial topics like politics, religion or any other ragebaity content; there are plenty of those elsewhere.

Thank you for joining!

One step at a time

I changed how Pawn-sacrifice is initiated, by limiting Serpent to its neighboring fields. As a consequence, Pyramid is now activated with only one momentum, so sacrificing Pawn is also limited to only one step. While change itself is rather small, and it applies to only one special movement, there are a few design choices worth pointing out.

The issue with Pawn-sacrifice was that one could lose quite a few Pawns, and in turn have promotion opportunities severely limited or completely gone, all in only one move. Also, in its original form, Serpent could initiate Pawn-sacrifice by activating Pyramid from across a chessboard. It was also possible for a Serpent to slither around pieces and still find a way to its own Pyramid. Similarly, Pyramid activated with a lot of momentum could sacrifice Pawn at the other side of a chessboard.

In my defense, when Pawn-sacrifice was originally conceived, Serpent's movement was much more limited, up to 9 fields in the largest variant, 8 otherwise. In the mean time, I extended Serpent's reach, but failed to notice its impact on Pawn-sacrifice. By limiting Serpent to its neighboring fields, one now has at least some warning signs (Serpent, Pyramid and Pawn placed close to each other) what is about to happen, and an opportunity to counteract that kind of a move.

I'm also updating the book, Pawn-sacrifice is the only meaningful change. The book was compiled on July 29, 2025, version is 20250729.034138, and can be found in other usual places.

Remove the rule, update the book

I have removed the rule which stated that the first piece in a move cannot return to its initial position, regardless if it was the only piece in a move, the first in a cascade, or in divergence. Since this is a major change I'm also updating the book, the other changes include:

• clarified double checkmate, added notation and status grammar,
• reworded Starchild intro,
• clarified castling notation, fixed grammar,
• clarified optional notation, fixed outro,
• reorganized sections, 
• fixed formatting in tables, 
• other tiny fixes.

If the rule stayed, it would actually mean that all pieces would have to be uniquely tracked, which would mean that each piece would have to be assigned unique number at a start of a match, and then for everything else it's type and tag would have to be fetched from look-up-table. This would lead to a major  shift of underlying API in a library; but more concerning, also in paradigm shift, where chessboard wouldn't host pieces anymore, but their unique identifiers. This change would be even more of a tectonic shift than the previous one; doable, but got me thinking; is it really worth it, why did I impose such a rule, and such.

For one, it wasn't a movement rule per se (belonging to any particular piece), but it was a restriction imposed on a movement rules of all pieces. As such, it doesn't belong in the book, but among other FIDE or tournament rules. More specifically, any piece starting a move cannot do anything more than just to initiate a permutation of Waves, if that starting piece is about to return onto its initial position in the same move. What I overlooked is that permutation necessary leads to repetition of positions, and that has already being handled by FIDE; for instance, see FIDE 9.2 point in FIDE Handbook.

Another reason for the removal of the rule is physicality; all pieces of the same color and type look the same; this is especially true if displayed on-screen, on a web site, or in a computer game. And yet, the rule called for recognizing (and accounting for) that one specific e.g. dark Rook which started a cascade vs. the other(s) which did not. Of course, computers can be programmed to distinguish those easily; however, a player would have hard time tracking which dark Rook is which, especially in a long-winded cascade.

In short, the above rule would be difficult to implement, goes against a physical reality of a game it tries to regulate, and there is already available better, easier alternative; so, no wonder it has been removed.

Anyway, the book was compiled on June 6, 2025, version is 20250620.014531, and can be found behind that juicy red button above, or in other usual places.

Guessing game

Merging pieces and tags mentioned in a previous post have gone much smoother than I expected, and it's finished now. I also wrote in that post my estimates how long a game in the largest variant could take. In the meantime I have revised my estimates, and so I present you with bigger, better numbers. Again, these are very rough guesstimates, it's difficult to even assess how much numbers presented here could deviate from real-world matches; in short, those shouldn't be taken too seriously.

Estimates here are based on the fact that most large, complex systems settle its metrics somewhat in the middle, since most extremes tend to cancel each other out. For this analysis we'll be comparing easy to calculate metrics such as:

• size of a chessboards,
• count of all pieces in a variant,
• number of different types of pieces,
• number of possible interactions,

and will be comparing One variant against Classical Chess. For each metrics we'll calculate its contribution to overall complexity, then multiply them all together, since they are all (mostly) independent; although, total number of pieces is always larger than number of different piece types.

All complexity factors have the same form, so let's define generic complexity factor $\mathrm{cf}$ as a simple ratio between new ($n$) and old ($m$) metrics, like so:

$$\mathrm{cf}=\frac{n}{m}$$

Edit: with provision that $n\ge m$.

This definition is all well and good, but applies only if corresponding metrics contribute to system's complexity directly, in a linear fashion. Most of the time, this is not the case. For instance, adding two ranks and files to a classical chessboard is a much larger change (as a percentage) then adding the same to the second largest variant, Discovery. So, each increase in metrics yields diminishing increase in complexity; for such a non-linear increase there is a function which sets limits to growth, and that's natural logarithm ($\ln$):

$$\mathrm{cf}=\ln \left(\frac{n}{m}\right)$$

There is still a small issue to solve here, before calculations can take place. Observe what happens if we compare e.g. Classical Chess with its own self:

$$\mathrm{cf}=\ln \left(\frac{m}{m}\right)=\ln \left(1\right)=0$$

Our complexity factor $\mathrm{cf}$ gets to 0. This is actually fine, all that calculation is showing us is that there is no additional complexity when comparing a variant to itself. Still, we'd like to multiply our complexity factors, as independent variables should be. So, we'll add 1 to formulae, like so:

$$\mathrm{cf}=1+\ln \left(\frac{n}{m}\right)$$

Now that we have generic formulae for complexity factors sorted out, we can actually calculate something; lets start by comparing sizes of chessboards:

$${\mathrm{cf}}_{\mathrm{size}}=1+\ln \left(\frac{{26}^2}{8^2}\right)=1+\ln \left(\frac{676}{64}\right)=3.357310$$

Next, we can compare total number of pieces on the chessboards:

$${\mathrm{cf}}_{\mathrm{pieces}}=1+\ln \left(\frac{190}{32}\right)=2.781288$$

Another comparison is between number of different types of pieces:

$${\mathrm{cf}}_{\mathrm{types}}=1+\ln \left(\frac{18}{6}\right)=2.098612$$

Finally, we can compare number of different interactions:

$${\mathrm{cf}}_{\mathrm{interactions}}=1+\ln \left(\frac{19}{3}\right)=2.845827$$

Our complexity $c$ is then defined as a product of all factors calculated above:

$$c_{\mathrm{regular}}={\mathrm{cf}}_{\mathrm{size}}\cdot {\mathrm{cf}}_{\mathrm{pieces}}\cdot {\mathrm{cf}}_{\mathrm{types}}\cdot {\mathrm{cf}}_{\mathrm{interactions}}=55.767104$$

This is actual length scaling factor of regular games from Classical Chess into One variant, i.e. all games should be 55.767 times longer. For instance, the longest recorded tournament game was 538 moves (269 FIDE moves, aka cycles), which turns into 30002 moves (15001 cycles) for One variant. Average on-line match lasts about 80 moves (40 cycles), in One variant that would become 4461 moves (2230.5 cycles). Average tournament match lasts about 88 moves (44 cycles), which becomes 4907 moves (2453.5 cycles).

The same, however, does not apply when calculating maximal possible game length, because players will try to maximize each and every metrics available to prolong the game. This can be seen in Classical Chess games alone; the longest possible game with 50-cycle rule is 11797 moves (5898.5 cycles), while with 75-cycle rule it's 17697 moves (8848.5 cycles). If we calculate ratio between the two rules:

$$\frac{75}{50}=1.5$$

and game lengths, we can see that contribution to game length by rules extension was almost perfectly linear (50% increase in movement rule resulted in 50% longer game):

$$\frac{17697}{11797}=1.500127151$$

So, for maximum game length we have to calculate linear scaling factors; for chessboard sizes factor becomes:

$${\mathrm{cf}}_{\mathrm{size}}=\frac{{26}^2}{8^2}=\frac{676}{64}=10.562500$$

Next, for total number of pieces on the chessboards we have:

$${\mathrm{cf}}_{\mathrm{pieces}}=\frac{190}{32}=5.937500$$

For number of different types of pieces we get:

$${\mathrm{cf}}_{\mathrm{types}}=\frac{18}{6}=3.000000$$

Finally, we can calculate factor for number of different interactions:

$${\mathrm{cf}}_{\mathrm{interactions}}=\frac{19}{3}=6.333333$$

Taken together, our complexity $c$ becomes:

$$c_{\mathrm{longest}}={\mathrm{cf}}_{\mathrm{size}}\cdot {\mathrm{cf}}_{\mathrm{pieces}}\cdot {\mathrm{cf}}_{\mathrm{types}}\cdot {\mathrm{cf}}_{\mathrm{interactions}}=1191.582031$$

This is scaling factor for the longest possible games, i.e. the longest games should be 1191.58 times longer in One variant compared to Classical Chess. For instance, previously mentioned 11797 moves (5898.5 cycles) game as the longest possible with 50-cycle rule in One variant becomes 14,057,093 moves (7,028,546.5 cycles) game. Even longer 17697 moves (8848.5 cycles) game with 75-cycle rule in One variant turns into 21,087,427 moves (10,543,713.5 cycles) game.
Edit: all this without resurrections, with those used it's -for all we know- infinite.

These are all very large numbers, even "just" 55.767 times increase in complexity results in some ludicrous (as in, almost completely impractical) estimates. For instance, increase in complexity should also translate into longer time allowance per turn, simply because there is so much more stuff a player has to handle. So, 15 seconds per player's turn in bullet game (10 minutes, spread over average of 40 turns per match, see https://en.wikipedia.org/wiki/Time_control#Classification) now becomes approx. 13.941776 minutes per turn; given that average One game length would be 4461 turns, it would last for approx. 1036.5710456 hours of gameplay time; or, 129.5713807 days if we assume 8-hour gameplay in a day. If we don't increase time allowance per turn, 15 second per turn bullet game would take on average 18.5875 hours of gameplay time, or 2.3234375 days with the same 8 hours of gameplay per day.

And that's just bullet, lets not talk about classical time controls here, those numbers would be depressingly huge. One thing that is sorely missing from complexity estimate is mobility, and associated with it, piece powers. These are not easily estimated; also, increase in mobility alone does not add to complexity, rather it's ratio between mobility and available space (i.e. chessboard size), and I'm not sure that ratio has been increased by much. Anyway, this post is already too long, so I'll leave it for some future post.

Tectonic shift

It's unusual to have very base data model change this late in a project; any yet, here we are. Currently, I was implementing generators of all legal paths every piece can make in a ply. Since this change will disrupt development for quite some time, let me try to explain it.

The issue I'm talking about is that currently piece and tag enumerations are separated; which would be fine in almost all designs, since most of the time one data entity is indeed independent from any other, e.g. one person's year of birth is very separated from their phone number. This is not the case here, Bishop can never get "can rush" tag, nor Knight can ever castle.
Edit: Tags and pieces have very few, and very intimate relationships; usually tag can be attached to a few pieces (e.g. rush and en passant tags for privates). Technically, tag is a link between a piece and a field at which that piece is located. Once that link is broken (e.g. a Pawn has been activated and moved away), there is no more tag present (e.g. activated Pawn has lost its promotion tag) even if both a piece and its originating field are still present in a game. Most of the time the best data model is the one designed after real-life; this is why original design featured tags separated from pieces. 

Another issue with separated piece and tag enumerations is that, well, they are separated. So, every function working with pieces (and in a chess game that means all of them) has to have two separate parameters. Yes, you can combine then in a neat struct, together with some other bits (e.g. a position) to bring number of parameters down; but, they both are now present in every struct you have to pass around.

Plus, they still take too much space, in fact, twice as much as needed; and that's after a change has been made quite some time ago, so that only 1 byte (char) is stored per enumeration instead of default 4 (enums are just fancy ints). You might think that we have moved past storage issues since like forever, but that is true only for local apps. For libraries, one has to consider possibility that it might serve many users at once, also it might need to do it on a restricted hardware (e.g. micro-controllers).

There is another issue with enumeration storage, and that's space it takes in a chessboard struct; again, currently it's double the amount it actually needs. Parsing user notation and applying it to a current chessboard is not an easy task; if undo is supported then one has to apply all moves performed until that point. To speed things up (and avoid doing the same job twice) position after performed move can be stored, and later retrieved. Only problem is, the largest variant has 676 fields, 190 pieces and 14 different interactions (losing tags are not counted, as they're result of interactions), which means it can last much longer than classical chess game. The longest recorded classical chess match in tournament was 269 moves, but legal match can stretch up to 5898.5 moves with 50-moves draw rule, or up to 8848.5 moves if 75-move draw rule is used instead.

For the record, move to me always means all actions performed by one player in one turn; this is different from FIDEs definition used above which define a move as white player action followed by black player action; for FIDE definition I use term cycle. Reason why I refer to move as such is because each player moves their pieces independently to each other (current chessboard position notwithstanding), there is a meaningful choice to be made; in fact, making a choice is the whole point of a game.

So, how long can chess game go in the latest and greatest variant of them all, the One? Honest answer, I don't know. I tried to guess-timate the thing, but it's probably wildly inaccurate. My guess is that tournament games won't last much longer than 18.000 moves, and technically legal games could probably go for 10.000.000+ moves; both with 50-cycle draw rule. This post is already too long, if you're interested to hear my reasoning, let me know in comments below.

As you can see, if undo is supported by storing chessboards, just having variant enumeration as an int in a chessboard struct can easily eat up to 40+ MB of space, just for that one enum. Undo chessboards could currently use 13+ GB of RAM in total; with changes proposed here implemented, that could drop down to 6.5+ GB. This is why I'll merge piece and tag enums, and also change variant enum storage to byte. Such a change will affect everything in the project; for the time, there will be development without (much) progress.

New book update

I'm updating the book even though less than a month has passed since the previous update; the newest changes include:

• rewrote checking opponent's King by Serpent,
• tiny clarification, cascading en passant,
• filled-in, clarified piece activations table,
• removed activations on miracle-fields by Starchild, Wave,
• removed Wave divergence on miracle-fields,
• a bunch of tiny fixes, clarifications.

In a previous update I planned on making an exception to Wave's transparency, so that King behind it is not in check anymore. That has been revised, and so Wave transparency stays the same, and King behind it is still in check. Due to Shaman being able to capture multiple pieces in a single ply, I had to put forward rule that King is in check if it could be captured, if it was opponent's turn. Then everything else followed from there: if a Wave can be passed over by a piece due to its transparency, then attacker already have direct access to a King; and hence, King is already in check.

I also removed all activations on miracle-fields, except Starchild can still activate a Star. This is due to miracle- and uplifting-fields being the same, so it was hard to determine on-the-spot (when parsing user notation, building legal path, ...) if interaction is just an ordinary activation (on miracle-field), or it's uplifting a piece; because uplifting is a two-stage process, and so activation context has to be passed between plies, before anything conclusive can be known.

The book was compiled on April 2, 2025, version is 20250402.230028, and can be found in usual places.

En passant finally described! And checking opponent's King! More news at 11! Also, the book has been updated ...

I'm updating the book after only two months, since there has been some significant changes, including en passant being thoroughly described, for real. More detailed list of changes follows:

• fixed side-effects table, added footnote
• clarified displacement
• described checking opponent's King
• clarified static Serpent
• clarified castling blocked
• clarified piece actions
• clarified Scout can be rerouted around any non-empty field
• described en passant blocked, denied, turned into capture, divergence, ...
• described activation after en passant
• described multiple rushes, en passants in a cascade
• described en passant in close quarters
• described en passant affected by a Star, Starchild
• switched to non-shifted tilde
• and many more tiny edits, fixes, ...

While I was reviewing changes I made to the book since the last update, it also occurred to me that I gave too much leverage to pieces attacking opponent's King. Most pieces grew significantly more powerful, especially in late variants, while King remained the same it ever was, in effect making it much weaker against any opposing force. This is fine, and as it should be; the tricky part here is finding the right balance. This is why I already started changes to limit checks only to pieces directly "in line of sight" of opponent's King, meaning that King is in check only if all capture-fields between an attacker and a King are empty. In hindsight, what happened here is just me always leaning towards giving a player more choices, a piece more mobility; in short, more power for all; sometimes more power is just too much.

I also lean towards doing the same with Wave. Currently, due to its transparency, Wave cannot be hard-pinned to its King. With upcoming changes, Wave on a capture-field would nullify any check to a King behind it. The reason is the same one used to make Pyramid incapable of checking opponent's King, while at the same time that very same Pyramid can capture any other opponent's piece; it is to ensure all checks, checkmates are direct, simple to see, and reason about. It also helps that in doing so, it makes rules (and code implementing them) less fiddly.

It could be argued that transparency of Wave is hard principle, i.e. it should always work like that, without exceptions (which is true), and also that King would be sufficiently protected just by aforementioned changes, without changing Waves (also true). Counter-argument might be that directness of checks and checkmates is also hard design principle, i.e. no pieces between checking piece and checked King. Good game design promotes, and sticks to its own design principle hierarchy. To me, directness of checks, checkmates have precedence over any other rule; which means, transparency of a Wave will have to have an addendum.

I plan finishing changes mentioned here, then continue working on the code; book update will follow its own (give, or take) quarterly schedule. In the meantime, I'm also starting to think about revising One variant, namely Starchild could be reverted to its initial design, where any piece could activate it. Still, this is very low priority, and in very early stage; so, it most likely won't make it in time for next book update.

The book was compiled on March 9, 2025, version is 20250309.071052, and can be found in usual places.

Updating the book!

I'm updating the book, since previous update was three months ago, and there were some meaningful changes, which include:

• changed reposition symbol to backslash,
• removed unsupported castling notation examples,
• added delayed column to variants table, description,
• removed monogamous promotion,
• changed draw offer cancelled symbol,
• clarified resurrecting converted pieces,
• clarified only captured and oblationed pieces can be resurrected,
• clarified resurrecting Waves, Starchilds,
• fixed grammar: Starchild can be activated,
• and many more fixed edits, typos.

Some of changes were made to ease parsing user notation; for instance, repositioning symbol used to be just comma, which is also used for list of captured pieces during (double) trance-journey. Another example, cancelled draw offer was previously written as (-), now minus sign has been removed from brackets, since it's also used to separate destination from any previous step.

For castling notation, previously one could specify for Rook starting, any or all intermediate fields; now it accepts only destinations, either full position or just a file, optionally preceded by Rook symbol. So, Kh1-d1&Re1 is acceptable notation, but Kh1-d1&Ra1-e1 is not anymore; because King is not transparent to Rook, it's just a very special move. Another reason is that it also simplifies parsing user notation, without losing any valuable information.

I also removed monogamous promotion; after some thinking it was obvious to me that promotion does not add anything to the game, but only complicates things for players, and for no good reason. I thought I had one when I was setting promotion rules, but certain choices doesn't make a good story. I prefer freedom of choice over (unnecessary) rules. There is also a moment when one has to consider simplifying design, when possible. 

The book was compiled on Jan 13, 2024, version is 20250113.203449, and can be found in usual places.

Grepping over history

In a series of posts for a future, forgetful me; today's topic is a way to search for changes in a file content over past git commits. Turns out it's not that easy, it's either a two step process; or, one gets laundry list of every occurrence of whatever is searched for that ever existed.

I opted for two step process; first search for commit IDs of interest, then get files in that commit:

• git log --grep=<regexp> lists all commits with a message pattern,
• git log -G <regexp> lists all commits with a content pattern,
• git log -S <regexp> lists all commits with different count of content pattern (additions vs. deletions),
• every search can be further restricted to a file (or folder), e.g. git log ... -- path/to/file/.

Now that commit IDs are filtered-out, one can get file by using:

git cat-file --textconv <commit-ID>:path/to/file;  --filters can be used instead of --textconv. I find it more convenient to just dump committed file into a temporary file, like so: git cat-file ... > temp.c, then open said file in a text editor. Every text editor nowadays is aware of external content change in opened files; so, to repeat search with another commit-ID one has to do as little as just dump into the same file. It's also convenient if temporary file has the same extension as committed file, that way text editor can do syntax highlighting, without having to be set manually.

For a laundry list of everything everywhere, one can use git grep <regexp> $(git rev-list --all); the problem is that it's very long, even if restricted to only one file both in grep and in rev-list, like so: git grep <regexp> $(git rev-list --all -- path/to/file) -- path/to/file.

Too much coffee

Since the very last post, I reverted most of the changes to the repository. Too little sleep, and too much coffee will do that to you. You see, I overlooked that out of 8 divergent pieces in the latest variant, 6 are available to any one player, and 4 of those are also transparent. Which means that every single piece in a move (and especially the ones starting a cascade) has to recursively build its path along chessboard, to find out its longest path.

Except, that is not completely correct; generated path for the first piece has to maximize momentum, not its length; and obviously enough, those two things are not necessarily the same. Also, I still need a way to filter out all generated paths according to parsed user notation, since it might contain specific fields visited, and side-effects exerted. And so, I do need a parser; hence revert.

Not all is lost, most of development on now archived branch was also merged back into mainline development; including newly assigned reposition symbol. I also renamed modules storing parsed notation, because those were all too easily confused with modules parsing user notation. Storage for parsed notation (at very least, steps and side-effects) should also be part of generated paths, since paths also has to contain everything encountered on a current chessboard.

Before I delve more deeply into generating paths, I plan to clean-up losing tags, try to resolve TODOs in parse modules, and also have parsing user notation covered with tests. As for tests, one can easily get drown in those, and still fail to test some peculiar interaction. I think, I should give up on testing all of interactions since there are simply too many of those, and cover only the simplest forms.

For instance, I should have one battery of tests just for step separators, the other one just for side-effects, and another still for ply separators, and one for move statuses; each of those should test only one separator, side-effect, status. It might be possible to generate tests based just on a chessboard set-up, and test all interactions that way. However, without a proper way to generate all legal moves for a given situation on a chessboard, it's too early to  think about it.

Early spring clean-up time it is, I guess. And after all of that, on to generating and filtering paths.

Conveyor-belt no more

You might have noticed in the repository that I already scrubbed clean C source code of all kinda working, but not all that useful modules. The problem is that design consists of all special cases, where every special case has its own super-special case; special cases all the way down. Trying to implement this in a super-uniform, context-agnostic code based on a conveyor-belt design is nigh on impossible.

So, this time I'll try different approach, and handle each piece and each interaction separately. Also, instead of trying to implement all of pieces and side-effects all at once, I'll start with one simple case (say, Bishop), and then do everything from parsing notation to applying that parsed ply to chessboard, just for that one piece. In short, finish vertical implementation, before going sideways (except for new Pawns ;). This will also allow for testing full stack before adding more pieces, interactions.

Downside to this approach is that adding each new piece, interaction will also require changes to already existing, and tested, API. Unfortunately, there isn't much I can do about that. Still, slow progress is much better than no progress at all.

Conveyor-belt, you ask? Well, in what seems like eternity, when dinosaurs roamed the Earth Flash-based games on the web were popular, there was one fun and engaging lil' puzzler, even if it featured sometimes wonky physics. So, when objective is to move balls to the other side of a valley, and gain some height in the process, what the most obvious solution immediately comes to mind? Conveyor-belt, of course! It works for sure, it's easy to understand, a bit grindy to implement; but hey, upsides surely outweighs its downsides, right?

If you'd like to try it yourself, here it is. Spoiler alert, conveyor-belt might not be the best solution, and by far.

YouTube strikes again

Don't you love it when your favorite source of entertainment, amusement, even education drops an adorable little note of fr*ck off:

Video unavailable

This video is no longer available because the YouTube account associated with this video has been terminated.

But, copyright claims could be easily resolved without ever terminating anything, or anyone. Instead of meeting every DMCA claim with an axe and bleeding good, quality content in the process, YouTube could just divert any monetization to its proven, rightful owner. If attribution is wanted, YouTube could insert short notice, saying something like "This content is owned by such-and-such copyright holder", and provide link to their web site, or YT channel.

But no; axe very fast, is automated, much law, wow. Look ma, no workers!

Usually, most music for me is just some pleasant background noise, no need to get upset about a particular interpretation, if they are all very similar to each other. This one, however, is part of the book, and it's the most sublime; in comparison, all the others are almost as good, but not quite. Luckily, original poster was kind enough, and persistent enough to already repost missing music.

On the side note, YT seems really desperate to be fishing for phones used by real people:

Verify to do more on YouTube

To add custom thumbnails, verify your phone number. 

BTW, choosing different playlist thumbnail worked in the past. Putting it behind a phone-wall is downright phishy, and sleazy.

The worst part? Google and -by extension- YT already have my phone number, and it's already verified because of 2FA.

MBAs seems all forget that a company has to be useful to own customers if they want their business in the long run, and with as few annoyances as possible. If company is getting more and more annoying, it's also getting less and less useful, and so customers will go to alternatives, no matter how big a company is, and how impossible it might seem to fail. OTOH, we had been in a downward spiral before; now, given that MBAs copy each other, we might be in for another.

Edit: tried to explain myself better.

A new book update

I just finished the most recent changes, and so I pushed a new book update. There are some slight corrections, clarifications, but also conceptual change, and complete activations overhaul. I was comparing activation and divergence, and especially for a Wave, their differences; and it made me thinking: "why activated Wave can move over only one type of field, while diverged Wave can choose any?", "how is this fair?", ... So, I decided to level the playing fields, so to speak, and make all activator's steps, fields accessible to activated Wave.

Now, Wave does not inherit type of field at which it has been activated anymore, and instead it can choose from any of steps its activator can at the beginning of a ply. For the most part, activation works just like it was before, changes are relevant only for activators which have separated step- and capture-fields, like Pawn, and Shaman. For those two, Wave can now choose any movement or capturing step as its initial direction.

I was a little bit concerned about Wave activated by Shaman being OP. But, it's just one new activator, which is still more restricted than the other one OP already present in the game; namely, Centaur. So, in a way, it's more fair, since Centaur is now less of an outlier.

At the moment, I don't have any planned, or outstanding changes for the book; so, I'll say, it's as good as it gets. Of course, it's quite possible that I missed something, that should be corrected. With so many moving parts it's difficult to stay on top of every new version. In any case, if you notice something that looks like discrepancy between various texts, tables, examples, ...; please, do let me know.

I'll take this time between the book and the code, to take some more side-questing, and invest at least a few days to get to know NeoVim better. While I don't like vi, nor any derivatives, and have never been a fan, there is no denying that Pulsar is getting more and more annoying, the more I use it. I'm not sure what Pulsar devs are using, but I'm kinda appalled by the lack of performance on older, although still middle-of-the-road CPU, with plenty of memory. I also tried disabling tree-sitter, heck, even all of auto-complete stack, restarting Pulsar without plugins; all to no avail. I mean, everything works ok if edited file is well under 1k SLOC, otherwise it's a lot of pain. In a 4k SLOC Python file, every edit takes at least a second (!) before editor shows the change. As it is right now, this is not a proper tool for work, it's a toy. Bright, shiny, fairly extensible, beautiful; yet, ultimately, next to useless. Which is a shame, really; I do like it a lot.

Geany, you ask? Well, I did use it, it was good, I kinda liked it; but, after Pulsar, it's like going back to your first bike. Sure, it works, it can make you go places, but it's not the same anymore. For me, it's plan B, if NeoVim does not work for me. Especially since with the newest Geany version (2.0.0) very little has been changed compared to previous stable version, except devs bumped version number, and introduced C++17 dependency. So, it's painful to get the upgrade if your Linux repo is LTS, and it's simply not worth it. All together paint a bleak picture for future development of the IDE.

Anyway, the book can be found in usual places, it was compiled on November 14, 2024, and the version is 20241114.064539.

Gentle sounds of Hilti in the morning

As you might have noticed, last few months were much slower than my usual. As I have announced last year, skyscraper I live in is undergoing major renovation works, even if it's one year late. Company managed to get additional year for works to complete, and now whole building sounds like, walks like and quacks like a busy building site; in short, it is properly noisy in my apartment during any work day.

While I do prefer to work during night, when there are as few distractions as possible, it's still a challenge to get some sleep, or do anything else in such a noisy environment. So, while I'll try to do my best, this mess will probably last for at least a year. Unfortunately, I don't have notebook PC anymore, so I can't even take my work to e.g. library and work from there. Will try to see with friends what can be done ... though, not holding my breath.

Undoing git push

This is just a quick note on how to undo push already made to git repo. This will undo changes to your workspace, local and remote repo.

First, do reset:

git reset --hard HEAD~1

Instead of just resetting last commit (to previous HEAD~1 commit), you can reset e.g. last three by entering HEAD~3, or enter SHA-1 of last-good commit.

Then, force changes from local repo onto remote:

git push --force

Obviously, all changes made to repo after chosen commit will be lost, if they are not in some other branch.

Your colleagues will hate you if you screw their work. Take care!

Pulsar, Pulsar, shining so very, very brightly

... yet ever so very, very briefly.

When it's at its best, Pulsar is so bright you gotta wear shades, it's that good. Its default theme (One Dark) is great, optional Dark One Dark is just gorgeous. Plain and simple project management, as-in collection of files. GUI is uncluttered. Editor split into two panes is joy to use, especially given that split panes aren't supported by many editors, or only in some hybrid form. Add to that a large selection of easy-to-install, easy-to-use plugins.

Things are getting dimmer from here on, I'm afraid. Plugins are mostly leftovers from Atom era, some fail to install, other do not work as intended. While plugin dependencies are handled when installing, they aren't when disabling. For instance, disabling autocomplete-plus also makes otherwise working autocomplete-python non-functional, without any visible clue; and even with "Output Debug Logs" on, I haven't been able to find error message in DevTools console, though it might be buried under the pile. Once installed, there is no telling what dependencies a certain plugin has. So, if I disable open-on-github what will stop working?

Plugin resolution is just by its name, name clashes are also not handled. For instance, if you search for "ctags", you'll find symbol-provider-ctags plugin made by savetheclocktower, with version 0.0.5, and no installs as of yet in package manager, and 55 on website. If you click on said plugin, both in editor and on website you'll encounter the same name plugin, but it'll be the one bundled with editor, made by pulsar-edit, and with version 1.0.0.

Pulsar's worst isn't any worse than any other editor, but leaves you blinded, and befuddled how people who took their time to put sublime "Ignore Whitespace On Current Line" option (in whitespace plugin) could also put fixed syntax highlight list into language-todo plugin. I know it's about managing one's expectations, and not every plugin is ready for prime time; but c'mon, it's not done in C, there are no worries if all strings are properly terminated, or if an array has enough space, lists and dicts  are so very easy, settings are also already persisted.

There are other annoyances, too. One that almost made me rage-quit Pulsar is "Atomic Soft Tabs" (in Editor Settings); until I found the bugger I thought I was getting tab chars, even though I clearly set indents with spaces. Some annoyances are spillovers, terms from Mac. Keyboard shortcuts having +cmd; what's cmd key on a PC? Another one, tab size defaults to 2. Also, what's with tabulation choices, "soft", "hard", "Soft Tabs", and their interactions? If you have to explain them, maybe it's time to rename? Or, better yet, simplify; one reasonable way to handle tabs is in Geany, feel free to copy its design.

There are some idiosyncrasies, as well. What is buffer, and why it's exposed to end-user? Is it a file? What if a file is really large (e.g. 40+ MB), does the equivalence still holds? Is "Find in Buffer" always the same as "Find in File"? Maybe rename it if it is? Or, better yet, implement "Find/Replace in File" that works on files of all sizes, even if only portion of that file is loaded into a buffer?

Also, why "Max Screen Line Length" is even an option? Why very long line can't be displayed as such? Is there a limit scrollable pane can handle? Does it considerably slows down editor? If so, why its numeric field accepts 19-digit numbers? I'd prefer editor to show me the content of a file as-is, with no modifications, except UTC-8 ones.

I could continue rambling, as Pulsar has it's fair share of annoyances and idiosyncrasies; but all editors have, you can only choose which ones you hate the least. Most of Pulsar's annoyances can be solved, others are not relevant to me. In fact, taken just as an editor it's great, and I like it a lot. It's only when I try to hold it by its devs promises ("Hyper-Hackable Text Editor", "Packages make Pulsar do amazing things."), then it comes a bit short. I tried Code::Blocks, CodeLite, Kate, even return back to Geany; in short, it was like a trip down the very bumpy memory lane, all the way back to 90s.

So, the blinky star it is ...

Book update and stuff

I'm updating the book, since previous update is already two months old, even though there aren't that many changes, but then again, there are no reasons to hold them back.

Changes from the previous update include:

• divided, moved piece actions tables
• fixed action tables for Pawn, Shaman, Wave
• described mometum restrictions of actions
• fixed notation, grammar for double side-effect (promotion + capture)
• added examples, Pawns (not) blocked by Wave
• described singe-step pieces and transparency
• clarified diverging from opponent's Starchild

The book was compiled on July 21, 2024, version is 20240721.112914.

In a bit surprising, unexpected move (pun intended!), last month I decided to convert all of DoxyGen documentation into Sphinx, and also ditch my editor of choice (MS Visual Code, at the time) for something else. This was done mostly on some sort of an intuition, feeling; which is strange, since I'd usually try to do some (strategic) thinking, e.g. "syntax hilight is broken again, for xyz times", "folding comments is borked, again", "editor is getting too slow", ...

Each documentation system has its own strengths and weaknesses, just like everything else in life. I'm already missing DoxyGen warnings when e.g. functions parameters do not match content of a C file. Also, with DoxyGen, it's immediately clear what is documented, and what is not. On the other hand, for DoxyGen one better have editor capable of folding (unusual) comments.

Sphinx is much more crude, you have to specify everything by hand, write everything down explicitly, and even then stumble upon random bricks on the (yellow) road. For instance, files can be organized hierarchically; labels generated automatically from section titles are flat by default (!?), there is only option to prefix them with a filename (!?). As a result, all your sections has to be prefixed with context (by file name, by parent title, etc.); so you now have titles:

• Piece
• Piece data
• Piece functions
• Tags 
• Tags data
• Tags functions

instead of what should be default:

• Piece
• Data
• Functions
• Tags
• Data
• Functions

Sure, second option can be done, but then files might have to be split, sometimes into very small ones. It's no good.

On the other hand, Sphinx does not bloat source code files. It's free-form, and lets you easily organize any way you want, and document key concepts, designs, informal agreements, and so on. Currently, I plan to document libcrochess in parallel to its development; later I might add documentation for various build scripts (gfx.sh, pdf.sh, build.py, py/), and docs for off-screen-shot generator.

Converting documentation proved to be a bit grindy, but relaxing experience, although there were way more text to convert than I'd ever imagine I has written. Anyway, it's done now.

Changing the editor was a bit more pain. Unlike some (most?) developers, I'm not attached to editor I use. Still, I do like the ones that tend to disappear when I'm working, and have all the essentials: 

• proper dark-mode
• simple project management, as in a collection of files
• find in (project) files, and with regex
• search and replace in (project) files, also with regex
• visual editor, e.g. commands are on clickable menu, or at keypress, not on a command line (i.e. vi is not for me)
• split text panes, preferably both panes are proper editors

I tried Kate, but only very briefly, I wasn't able to set it into proper dark mode, since some GUI, window elements have either hard-coded colors, or under non-KDE desktop it defaults to some light colors. Tried to install some KDE control panel app, tried to  fiddle with some settings, only to fail, time and again. It seems I'd have to install full-blown KDE desktop just to set Kate right. Thanks, but no thanks.

So, I returned back to Geany, which is reasonably good, fast, small, and with selection of useful plugins. It only fails at the last item, and in a strange ways; you can split editor into two panes, but only one (left, in my case) is a proper editor with working key shortcuts, the other one can be edited, but most shortcuts don't work.

I asked devs, quite some time ago, it seems it's quite a challenging issue, since Geany was designed from the very beginning around assumption that one file will be ever edited by only one editor widget. There is a 2.0 version out there, but it does not come in Mint repository, since default gcc version does not support C++17; so I can't test if new version solved the issue. For what it is, old version is still quite usable. Shame it's not more popular, and made better.

Which left me wanting more. So, I tried Pulsar editor, and it's great. So far, I only find that it does not have "save all" option. Other than that, I have to say I'm not fond of Electron apps (and 750+ MB for an editor!), but here we are. I think I'll stick with it, for now.

Updating the book

I'm updating the book mostly due to constant interest from readers. There aren't too many changes, since previous update was just two months old. What surprised me is that there are some meaningful changes at all, I was trying to do much more on the programming side, and will continue the same (although, it's tough avocado to crack. Mind you, that text was written before divergence and transparency were introduced!).

Changes from the previous update include:

• described tags in introduction
• changed diverging rushed Pawn, now it can't rush again
• clarified check, checkmate after activating a piece
• clarified check, checkmate while diverging a piece
• clarified Scout's forking steps
• clarified Starchild's divergence
• added rushing limits table, description
• added castling limits table, description
• described forward-displacement notation

The book was compiled on May 14, 2024, version is 20240514.045357, and can be found in usual places.

Finished once more

Oki, so the book is updated once more, and there are no more planned additions to it, so I'll call it done. That is, if I don't stumble upon a special interaction which was somehow left undocumented. For instance, I only recently stumbled upon rushing Pawn starting a cascade (nothing special here), which blocks capture-field of opponent's Pawn, so that en passant is not possible anymore (whoops!). Missing details like this are always a possibility, the best I can do is update the book as needed.

What I really wanted to write about is what didn't made into the book. First thing is a (semi-)transparency of Unicorn and Shaman. This isn't really a problem, but a nuisance; it adds so much in complexity, without enhancing game-play really.

It also does not make sense. I always tried to have all pieces congruent with their role, their story. And having physical entities suddenly becoming transparent to physical is not it.

Other things that didn't make it into the book are resized and expanded Classical Chess variants. I started doing it as casual remarks at the end of the book, but then realized that (if described in sufficient detail) these variants would significantly overgrow its casual remark status.

Worse, those variants actually do not belong to the book. Just as each piece has its story, so does the book as a whole. You most likely don't want to be reading synopsis for 1984, while finishing Alice's Adventures in Wonderland.

I was thinking for quite some time about a new book, where I'd  discuss mobility and calculated values of pieces in different variants. There is some chance that new book will be written, and  then alternative Classical Chess variants would be described in it. While I'd like to do it, right now is not the right time for it. That new book would be a major undertaking, and there are more important things I have to do.

My current plan is to finish game engine library and console application first. After that, I'll add enhanced PGN and other chess file formats support, and obviously document all enhancements done to adapt them for all Croatian Chess variants. And in a distant future, bot and networking support, then GUI application.

The book has been updated!

After almost half of a year, I'm finally updating the book. Changes from the last update include:

• fixed grammar (castling, Serpent cannot diverge, Pawn-sacrifice)
• clarified rushing, en passant
• clarified blocked castling
• changed Starchild transparency
• clarified diverging to starting field
• cleaned-up Wave, Starchild, Shaman intro
• simplified resurrection destinations
• described Starchild entering existing syzygy
• redo Shaman's movement, capturing
• clarified activating Wave by Shaman
• added Shaman, Unicorn (semi-)transparency
• removed Shaman, Unicorn transparency (yes, really!)
• rewrote capturing, diverging Shaman
• fixed Wave blocking castling
• clarified Wave activated by Pawn
• added Classical Chess chapter as an intro on how to read the book
• added en passant turned capture
• added blocked en passant
• added transparency of pieces table, description
• added piece actions table, description
• fixed typos (thanks, RainRat!)
• redo Pawn-sacrifice
• started adding expanded Classical Chess variants, then discard them all (yes, really! #2)
• improved images rendering (field-marker per corner, B&W per variant)
• clarified trance-journey interactions
• and more!

The latest update to the book was made on March 15, 2024, version is 20240315.011526, and can be found in usual places.

LinkedIn group

Recently, I noticed quite a few people checking on this blog. If you're interested, there is Croatian Chess group at LinkedIn: https://www.linkedin.com/groups/8989938/. At the moment, group is still small and cozy, but world of chess is large enough, and you can share anything you like 😉

Simplifying

Changes described in the previous post are mostly done. I'll continue working on the book, hence no update just yet. There would be no changes to rules, pieces, designs; I'll be just clarifying descriptions, most notably, movement of Shaman really needs to be simplified. Another issue is that I put a few examples in parallel into just one image. Obviously not ideal, but also not sure if it would really benefit from splitting it up.

As for changes described in the previous post, Starchild has been made transparent to all pieces, Unicorn is now transparent to Shaman, and Shaman is now transparent to all own pieces (i.e. in the same color), and to opponent's Shaman. Sometimes you just have to take the plunge; I'm not really happy with this kind of a blunt design, lumping all pieces into just three categories. On the other hand it does make sense, and can't be really more selective, while also keeping its simplicity.

One planned change that didn't make it, is that Starchild can be activated only on trance- and miracle-fields. While that can be done, both Waves and Starchilds are kinda life-line; if player ever looses all of Waves and Starchilds, (s)he cannot cascade anymore, and cannot resurrect any captured pieces, which is a major setback. To leave opportunity to save at least some of those pieces, I decided to keep activation of Starchilds and Waves on its step-fields.

While castling is special, one-off move, in reality is not that special compared to e.g. resurrection, and so it can stand to a reason that it too should participate in a mundane cascades. So, Wave is now set as not blocking when castling, and Starchild is blocking only destination fields of castling pieces. As a result, castling can now also start a cascade.

With all of those changes made, I do plan on revisiting movement of Starchild, its activation rules, just to check if all of those are sound. In fact, the book as a whole could receive a little reading from me. Yes, really. 

While I did wrote the book, changes are always made to one page, one example, one paragraph at a time. So, keeping track of all rules (and exceptions to those rules) is nigh on impossible. And yet, it's necessary if one is to check that all things are inherently congruent, to themselves, and between each other. So, I'm going to re-read the book to see if rules (and their exceptions) could be simplified while keeping their original spirit intact.

Streamlining

Usually, I would preface talk about the book with an (also, usually overdue) book update, then write something about plans for the future. Not this time. Changes done so far were minimal, and so it didn't make sense to update the book this time around, given that I'm thinking about reversing some of the changes made. Right now, I'm kinda stuck in the middle of a coding session. As soon as I put together minimal implementation for paths, routes, I'll do changes to the book, since it has priority over any code.

For example, one change committed to repository, but not yet in an updated book is clarification that all step-fields must to be empty when castling. This however is one of the carry-overs from classical chess, which doesn't have transparent pieces, and can be reverted back. After the change, Wave could be placed in-between castling Rook and King, and it still wouldn't prevent said castling.

Things do get dicey from here on, since then Wave could also be activated by either King or Rook. Sure, it could be done, and momentum could be calculated by simply counting step-fields traveled over by e.g. Rook. But, I don't like activating Wave while castling, since Rook is sort-of stepping over King, and castling is meant as an one-time super-special move, not a regular one. Maybe solution is to simply state that castling pieces cannot activate Wave, but are not obstructed by it, either; that seems the most reasonable design so far, will see.

Speaking of transparency, I'm also thinking about making Starchild transparent. You see, it kinda makes sense, but not all of the time. One design was to make Starchild transparent to pieces travelling over step-fields, but not over capture-fields. This would mostly just complicate things, but wouldn't do much for gameplay, since almost all pieces have the two kinds of fields lumped together, anyway. I tried to reconcile the two opposing design choices, but so far couldn't really make it work.

A solution (although, kinda cheesing it) could be to have Starchild transparent to some, but not all of pieces. For instance, Starchild could be transparent to e.g. Unicorn, Shaman, Starchild and naturally Wave, but not other pieces. Again, not really happy with this design, so I'll have to take a look into it. Although, past experience thought me not to relay too much on first impressions, sometimes necessary evil is necessary.

I have to admit I made a blunder: currently Starchild cannot be activated, and it's just by a simple decree ("you can't do that"). This is not good. What I should have done is describe interactions, everything else should be derived from that. In this instance, I should have written that Starchild can only be activated on miracle-fields (by other Starchilds), or on trance-fields (by Shamans). While net result is the same, one does not impose arbitrary limitations (and you already know how I feel about those), it just enumerates interactions.

Together with bad no-activation rule will go rule that material pieces gain one momentum from Starchild, by simply diverging from it. I don't know what kind of a brain-fart I had that day, but oh boy, it's still smelly. Solution is simple, if a piece has enough momentum, and Starchild is transparent to it, great; if not, it'll be blocked from moving any further, just like any other piece.

Another design that I'd like to simplify is set of potential destination fields for resurrecting syzygy. Other things that desperately needs simplifying are rules regarding multiple syzygies, be it a piece moving from one into another, or standing on a shared field, or something else.

In short, while the book is finished, some things are still settling, and it will take its time, just like everything else. On the other hand, if you look at classical chess, which is much simpler design, it took roughly a millennia to have rules more-or-less in its current form. As an additional bonus, I'm very, very slow; both in writing, and in coding. If you ask me, I'd say don't prepare your popcorn just yet ...