Ratings & Comments

Should I presume that in variant 1, a King may move to or stay on an attacked space, and in variant 2, a King may not move into or remain in check?

This is how it should be.
In variant 1, a captured king is assimilated by a king of the other side in the worst case, and the game continues until one side has captured all pieces.
In variant 2, the capture of the king ends the game.

Shako sounds well!

I have now reduced the name and call the variant simply 'Conquer' - some other terms are occupied, e.g. 'Assimilation Chess', 'Fusion Chess', 'Take Over Chess'.

Following your recommendation I have not used the phrase 'starting position' in my description now.

Then thank you for pointing out that perpetual recaptures may become possible. In the description I have included a rule against perpetual recaptures.

So far, I have not been able to get Shako to work on Jocly. Here's the URL:

https://www.chessvariants.com/play/jocly/shako

In control.php, I have the string shako replaced by shako-chess, which the files for running it use. Also, https://www.chessvariants.com/play/jocly/shako-chess is not working any better.

I've noticed some different things about Shako. First, there is a folder called originalShako, and Shako is the only game with such a folder. Second, there is a Shako file called shako-chess-mxdel.js, and it is the only file matching the *mxdel* wildcard.

This is not a general problem with Jocly. Other games are working. I have tried multiple browsers, these being Firefox, Edge, and Waterfox.

H.G., would you know what's going on and how to fix this?

I added a special media query to this page to recognize the browser available on the Kindle. Recent Kindles have a 300ppi screen, which results in displaying 300 pixels as an inch. Since most screens would display 300 pixels in a larger physical size, this can lead to images and text being too small in the Kindle browser. While it's Article mode can make a page more readable, it's best to not make readers need to rely on it. The query checks whether there are lots of pixels on a small screen. The idea is to check that the width is at least the width in pixels of the 6 inch Paperwhite and no more than the width of the 10.2 inch Scribe in inches. With some margin for error, the query looks like this:

@media (min-width: 1060px) and (max-width: 7in) {
}

Besides the size issue, the Kindle browser has hardly been updated in years, and it does not support many features that have become commonly supported in other browsers. For example, this page uses a flex display, but since the Kindle browers do not support this, I have provided some fallback CSS for putting some sections in columns.

Oh, thanks everyone for fixing the page up, thanks so much.

H.G. said ...

I think this page is also misrepresented in the index: it is mainly a rule description; that it also happens to contain a link to a Zillions file is coincidental.

Yes, you are right, I did this page ages ago and for some reason never did a proper game page, and then it got all these nice comments and I just left it like it is. Maybe sometime I could write a proper game page and add if you want to comment on the game to do it on the 'download the game' page, I dunno lol.

Why this title A A Royal and His Pet, with 2 A? A typo?

I've noticed some different things about Shako. First, there is a folder called originalShako, and Shako is the only game with such a folder. Second, there is a Shako file called shako-chess-mxdel.js, and it is the only file matching the *mxdel* wildcard.

Definitely something wrong there, and considering the 'modified' date probably of my doing. It seems the file was moved 'out of the way' by changing an o into an x. I don't recall doing this, but I was probably experimenting for how to hack new games directly into the Jocly library, to discover which files it actualy used for running by removing those and try what would break.

The curious thing is that in the Jocly install on my website the name is shako-chess-model.js. The date is exactly the same, though. (And just a few days before I implemented my first game, Team-Mate Chess.) I must have renamed it after the jocly/dist/ sub-tree was copied to CVP.

The problem is that the content of that file is also not what it is supposed to be. It is not uglified, and looks like the source file jocly/src/games/chessbase/shako-model.js. Normally the files jocly/dist/browser/games/chessbase/*-chess-model.js are a concatenation of the base-model.js, the variant-specific model file and perhaps some others, and then uglified. The uglification is probably not essential (the hack I used for implementing my games was to replace the uglified variant-specific part from such a file for a similar game by source code of my own game, but it needs to contain the base-model.js code to work.

Problem is that I cannot find the original uglified shako-chess-model.js file anywhere amongst my files. I tried to put back this file (on my own website) from a recently compiled Jocly from the back-porting project, but apparently the base-model.js file there is no longer sufficiently compatible with the old one for this to work. Unfortunately I forgot from where I clopied the Jocly version on my website, otherwise I could fetch a shako-chess-model.js file from there. Perhaps Zied still has a version on the Musketeer Chess website.

[Edit] I now managed to find a shako-chess-model.js file in the Downloads folder of one of my Windows systems. When I put that in the Jocly install on my website (and go through the cumbersome procedure of flushing the cached version), Shako works again there. The file is probably the same as that in the originalShako directory (where all files do have the same date). This directory does not exist in the Jocly install on my website, though. So I have no idea how it got created on CVP, which (at least for the jocly/dist/ part) was supposed to be a copy of that. It looks like someone copied all shako-* files on CVP to this directory, and then renamed the shako-chess-model.js. Anyway, I copied the shako-chess-model.js file now back to the chessbase folder on CVP as well. This should fix the problem if nothing else was changed.

As long as the pieces are going to stretch to fit the size of the space, maybe you could make an Interactive Diagram increase in size on a large (in terms of pixels) mobile screen.

This could be hard to control without knowledge of the entire page layout. The way I usually insert Diagrams into articles is by defining a 2 x 1 table, where the left cell contains the Diagram, and the right cell a list of pieces that can be clicked to summon the corresponding move diagrams (generated by the Diagram script as a 'satellite'). I then specify an explicit width for the left cell (and top alignment for the right cell). This to leave as little white space as possible between the board and the list.

It appears that the width specified for the table cell overrules the natural width of the Diagram itself; if I specify it too small the Diagram gets squeezed. So with an absolute width specified here, there would never be an opportunity for the Diagram to expand, no matter how wide the screen is.

I suppose the width of the left cell could be specified as a percentage of the screen width. Then the Diagram inside of it could expand if again the square size would be indicated as a percentage of the table width, rather than in pixels. Currently the Diagram script applies parseInt() to the value given for squareSize (this to prevent the 1+1=11 problem when you try to calculate something with it), so that specifying a width of 10% would be the same as specifying 10 (which by default is interpreted as pixels when used in the style width spec). It could make the script remember any non-numeric suffix to the value, and append that again to the number when specifying a width. Then it would be up to the one who configured the Diagram to decide whether he wants to use relative size (which would expand with the screen or window size when the surrounding HTML element does so).

But I don't think expansion would give a good result, unless overly large piece images are used (like 100x100). But of course the preson designing the page would know whether that is the case.

I've just finished a game of Symmetric Chess. At first I was seduced by this rule of Bishop's conversion, but finally I am not so convinced. My opponent was playing with White, so his two Bishops were on white squares. He moved c-Bishop first, then he lost it. So, only his g-Bishop remained on its initial square unmoved and was waiting for a conversion non-capturing move that never came.

I found rather confusing looking at this chessboard with this unique remaining Bishop standing on g1 and unable to move on the diagonals. An observer coming at this moment would not understand why the Bishop cannot move and capture a piece on f2 or h2.

So the rule is clear, but I found this a bit bizarre after all.

The whole site should now appear at a more normal size in the Kindle browser, because I used the @media query described earlier to zoom the contents by a factor of 2 in Kindles.

M. Badii - J. Stranjakovitch, Paris 1989 reached the position in the diagram below after

1.e4 a6 2.d4 b5 3.f4 Bb7 4.Bd3 f5 5.exf5 Bxg2 6.Qh5+ g6 7.fxg6 Bg7 8.gxh7+ Kf8

The game continued 9.hxg8=Q+ Kxg8 10.Qe2 Bxh1 with a win by White after 24 moves.

I see no reason for rules that may prevent early pawn promotions in Grand Chess. Most of us want games that are more interesting, not less. And after all, there is no limit to the number of promoted pawns on the board in Shatranj.

[EDIT] I should have specified the rules that I was objecting to:

"5. A Pawn can promote only to a friendly piece that has been captured, and for which it is exchanged."

"6. If no friendly piece has been captured, then a Pawn may not move beyond the 9th rank."

Okay, we'll feature Shako in April. It has been programmed for Jocly, Game Courier, ChessV, Zillions-of-Games, PyChess, and Ai Ai, and it even has an Interactive Diagram on the page. Its games on Game Courier go back to 2006, and it has been played every year on Game Courier since 2015. On a personal note, it is one of the first Chess variants I learned about after getting involved with this site, as it was in the Large Variant contest of 1999, and David and I were trying out variants in that contest together.

I suppose that David uses the term 'early promotions' not so much to refer to promotions before the last rank is reached, but to promotion so early in the game that nothing has been captured yet. And I agree that this rule doesn't really make a more interesting game, but seems purely conceived for the convenience of playing it with woodware, without the need for extra pieces. (Which seems a bit strange, as it would still need two extra Pawns and pieces per player, presumably from a second orthodox set, which would leave plenty of spare pieces available for promotion.

On the other hand, one could argue that it is a nice tactical dilemma that when you are planning a promotion you should also take care something worthwhile is traded by the time you reach last rank. This happens so rarely, however, that it doesn't seem worth to complicate the rules for making it possible.

Note that although the orthodox game shown by David does have an early promotion, but not one where the promoted Pawn survives.

This is more  criticism on how the pieces should be represented, than on the rule. In particular, whether the right or obligation to convert still exists should be 'hidden' (like castling rights) or explicitly visible. E.g. when playing with woodware, one could put the Bishops initially on a Draughts chip, to indicate they can convert. When one of the Bishops starts as a Wazir, you remove the chips from both. When it starts as a Bishop, you move its chip under the other, so that it stands on two chips, indicating it now must start as a Wazir.