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.

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.

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.

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.

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.

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.

Updating the book & license

I'm updating the book, even though not much has changed since the last update. In fact, the only thing that has been changed is clarification of side-effects on pieces. Reason why I'm updating the book is because of licensing.

I always thought that simply stating "this book is published as public domain work" should be enough, anywhere in the world. Recently, I stumbled upon Creative Commons site, and I quote: "Dedicating works to the public domain is difficult if not impossible ...", and "... many legal systems effectively prohibit any attempt by these owners to surrender rights automatically conferred by law, particularly moral rights ...".

Now, I'm not sure what are any additional rights automatically conferred by law, beyond moral rights mentioned on Wikipedia site:

• the right of attribution
• the right to have a work published anonymously or pseudonymously
• the right to the integrity of the work

I assume that situation is complicated, since every country has its own  copyright law, each unique in its own way; I'm not even sure how this is treated in a country I live in.

However, to me moral rights as listed above seems completely fine, they should not impinge on any major right granted by Creative Commons Zero 1.0 Universal Public Domain Dedication (henceforth CC0) at all, namely:

• free access, and freedom to use the work as user wishes ("use" includes to run a program or to execute a music score)
• freedom to access the "source" and use it as user wishes, for study or change it for personal use
• freedom to redistribute copies
• right to quote (freedom to redistribute copies of fragments)
• freedom to distribute copies of user's modified versions to others 

From what I understand, if I have moral rights retained, only the last item would be affected somewhat; modified versions should be distributed under a new title, and with new authors, due to the right to the integrity of the work. I'm not sure if right to attribution applies to modified versions; for instance, if modified book should contain "this book is based on ..." clause somewhere in a colophon. It would be nice if it does, but it's not that important to me.

If that's all there is to it, then I'd like to retain moral rights, even if I have had put the book into the Public Domain. If there are some other rights that would prohibit any of freedoms listed above to any person, then CC0 should come into play, and waive those rights away; this is what I meant with "where Public Domain is not applicable".

The reason I put my book into Public Domain in the first place is to prevent any publisher from closing access to my book behind a pay-wall, and limiting its usage by the public, especially given that some publishers are getting very creative, when it comes to their own benefits. And the reason why I choose to go with CC0 is because it seems that simply stating "this book is in public domain" isn't exactly enough.

To summarize, the book itself (PDF file), source texts (TEX files), generated images (PNG files), photo (NEF, and JPG files) are all in  Public Domain, under CC0. Note that all scripts (SH, and PY files, including those used to generate images for the book) are published under GNU GPL v3+ license, as are the rest of source code (C, and H files). Licenses, and how to apply them are found in COPYING, and LICENSING files; in book folder for the book, and in the root folder of the project for source code, and scripts.

Edit: it's actually way worse than I thought. So, I decided to apply CC0 unconditionally, and to hell with moral rights; they are not worth risking any legal loophole which I might have unintentionally introduced, along with possibility to creatively interpret intended usage, and applied license. The book is already updated, and uploaded, both onto GitHub repository, and Google Drive.

Edit 2: CC0 is a dedication, not a license.

A bit more finished

... the book, that is.

I'm updating it since grammar is now finished, and all the polish it needs shouldn't mess with designs, rules, pieces. I say shouldn't, because I bit my tongue so many times already.

Updates include mostly grammar, and some side clarifications, like how to combine multiple side-effects, added some examples on how to diverge,  material pieces are now gaining 1 momentum when diverging from Starchild, all small stuff.

One thing that still bothers me, although much less so then before is that grammar alone (that is, without context) is not be-all-end-all reference. I have wrote it in the book, but it's worth repeating: entity (values) which are present only sometimes are not the same as optional entity (values). 

For instance, move status most of the time is not present, i.e. it's empty value. Except for checks, all other move statuses are mandatory to write. To sort-of convey that mandatory-ness to reader, I defined move status with an empty value, so that status after a move is mandatory not just in notation, but in grammar as well.

Similarly, Shaman stepping is not defined entirely correctly; issue is that Shaman has ordinary steps separated from capture-steps, and can switch between the two after diverging. Wave can be ignored only while making ordinary steps, but not capture-steps. However, both transparency and  capturing side-effects are optional to write, and so both steps could look the same. So, to keep things simple, I lumped all side-effects together, even though they are separated.

Lack of meaning isn't something that can be solved in grammar, and the book can only deliver so much, or so little. In the end, it's up to reader to build his/her own understanding. 

Anyways, back to the drawing coding board.

Updating the book

After quite some time, I'm finally updating the book. Changes from the last update include:

• Monolith is opaque
• Wave is not divergent any more
• Shaman is now divergent
• Centaur, Wave activated by Centaur cannot diverge
• Unicorn can diverge
• Wave activated by Unicorn cannot diverge
• Serpent can displace Pawns
• Monolith is noble
• extended Serpent's movement limit
• Monolith now constantly accelerates while moving
• Serpent cannot diverge
• Wave activated by Serpent cannot diverge
• removed Monolith's movement limits
• Serpent cannot loop anymore (in a single ply)
• simplified trance-journey, fixed notation
• added sense-journey
• removed odd variants
• added a new pieces: Scout, Grenadier
• changed Pegasus symbol (G --> E)
• and much more!

The latest update to the book was made on July 9, 2023, version is 20230709.134133, and can be found in usual places.

Even newer book update!

I'm updating book again, even though not even a month has passed away, because there are a couple of clarifications to changes made by previous update, so this update is sort-of a patch to previous update. Anyway, transparency has been clarified, Monolith is now opaque. Also, divergence of Unicorn, Centaur and Waves activated by them is clarified.

The latest update to the book was made on February 16, 2023, version is  20230216.080342, and it can be found in usual places.

New book update!

I'm updating the book, there are quite a few interesting changes to hold it back. Most notably, Wave is now transparent, and also Wave and Starchild are now divergent. Static move is now officially illegal. And so on, ... you get the idea.

Changes since the last update:

• Wave is transparent
• Wave and Starchild are divergent
• added static move, piece, loop rules
• added symbol for resurrecting opponent's pieces
• clarified self-checkmate
• updated move, and compatibility grammar
• clarified promotion notation
• small grammar fixes (e.g. promotion is mandatory)
• and much more!

The latest update to the book was made on January 24, 2023, version is 20230124.083845, and can be found in usual places.

After this, I'll continue working on library; there are quite some changes to be retrofitted. Also, a lot of guess-work has to be done to reconstruct proper path taken by any piece, because transparency and divergence notation is optional.

Reason why it is optional is because "o, this is too hard" is not a valid reason; and convenience for a user is more important. Only if there are some data that are truly missing (like, not specifying a piece for e.g. a promotion), then I'd say side-effect is mandatory.

Anyway, I think there should be no more major changes to the rules, and the book. After all, I'm running low on ASCII symbols usable for algebraic notation.  :)

Transparent Wave, book updated

As mentioned in a previous post, I have changed Wave to be transparent; just as Wave can optionally interact with other pieces, now they can optionally interact with a Wave, or just ignore its presence. This is done so that interactions are symmetrical; what works for Wave, also works to the Wave.

Obviously, each design choice has its own set of additional ramifications. In this case, consequence is that Wave cannot be pinned any more, since it's transparent, and can be ignored. And consequence of that is that now, when pinned piece is moved, or starts a cascade, it has to be replaced with any other piece, but Wave.

Speaking of symmetrical designs, I was tempted at one point to define Wave as completely transparent, i.e. opponent's pieces wouldn't be able to capture a Wave. I dismissed this design as it would still have to allow for a Wave to activate opponent's Wave (that's the major point of a Wave!), so Wave wouldn't be completely transparent. Even worse, that would allow Waves to move about without ever being in danger, and so it would devolve any variant featuring Waves into A Bigger, Better Classical Chess™, now with additional set of annoying little buggers spoiling all the fun. In short; bad, bad design.

Wave being completely transparent would make sense if no interactions with opponent's pieces are ever allowed. I don't want this, since this too devolves any chess variant into slightly better variation of classical chess. The whole point of Wave, with its ability to allow playing with opponent's pieces, is to turn game-play from static, deterministic affair into a seeping-sands ground, for both players, simultaneously. Obviously, too much sand is too bad, this is why there are several restrictions on what Wave can reach and do. 

For instance, players start with just 2 Waves each; cascading of all material (non-Wave) pieces, except Pyramid, has to be initiated by a Wave. So, even if piece starting a cascade gathered enough momentum, most of the time it won't be able to cascade more than two additional material pieces, without using loop(s), which limits reach of pieces. And the most importantly, each play with opponent's pieces requires own Wave to activate opponent's Wave first. Since it's easier to control positioning of own Waves (compared to opponent's), each player is in a reasonable control of where take-over by the opponent could be made, and which pieces are exposed. In short, possibility to take over opponent's pieces is there, without being too easy to do so.

One other change to the book is inclusion of COPYING, LICENSING files; those clarify what is meant when book is put into a public-domain: 

• book itself, i.e. PDF file is in public-domain
• all texts (TEX files) are in public-domain
• an accompanying picture (JPG, NEF files) is in public-domain
• all generated images (PNG files) are in public-domain
• all source-code is released under GNU GPL v3+ license, covered by separate COPYING, LICENSING files

Transparent Wave is small, but significant change to overall design, and game-play. Similarly, explicit book licensing is also small change, but important to protect availability, and usage of the book. So, I'm updating book, which can be found in usual places. The book was published on October 17, 2022, version is 20221017.032524.