Comments by HGMuller

We could also ask the more general question of not keeping anything other than chess variants. Something to think about.

Indeed, that occurred to me too. We could easily delete all lines in the jocly-allgames.js file that do not refer to chess variants.

OTOH, the preferred access to the variants on this website appears to be through the Jocly overview page, not through the 'other Jocly games' link that the applet always shows. It is a bit silly when you first have to select a variant you don't want to play, and then switch. And the switch works in the applet, but not for the rule description page we embedded the applet in.

But the overview page also needs refactoring; listing the available variants by date is not helpful at all to the unwary visitor of this website. I am not sure what the best presentation is, though. I suppose alphabetically, even though this competes with what you could do (with some more knowledge and effort) in the site's alphabetical index.

I am also thinking of 'modernizing' the install here. By replacing jocly.game.js the Jocly core is already fully compatible with the recent source code. The only variant in the CVP install that has not been back-ported to source yet is Tenjiku Shogi. Since all game-specific model and view files include a version of the chessbase model and view, there is no harm in different variants needing different versions of these.

So we could replace all model and view files in the chessbase folder by those from the most-recent compile, and the images and supporting info file these use in the chessbase/res sub-tree as well. I think Tenjiku Shogi exclusively uses sprites, mesh files and diffusemaps from the shogi2 subdirectory, which does not exist in the source tree. Only jocly-allgames.js must be made to always have the extra line defining Tenjiku Shogi, compared to the version created by building Jocly from source.

You must not write anything on the row behind the =. Probably /..$= would already do. On encountering the = filling of the matrix skips to the friendly captures/hops, and at the same time copies what you already have defined in the row (so ..$ here) to the corresponding friendly interactions. What you continue after that will start to overwrite the copied friendly interactions.

I suppose I implemented the idea I described earlier in this thread, to give U moves a penalty in the positional range. I don't remember when I did that. (Or in fact that I did it at all.)

BTW: K-side castling is done with the pocketed Knight, instead of the Rook! Better move the pocket squares to 2nd rank.

This would only be possible with significant additional GAME-code programming. For one, you would have to program enforcement of the 'prelude', as the HandleMove routines in the Post-Move sections only handle normal board moves. So the code should first test the move number, and do something else for the first few moves.

Apart from that you would also have to add code after the call to HandleMove, in order to automatically step the piece on board that is gated.

I don't think you get this criticism because you chose an uncommon name. It is mostly because it is such an awful name, which looks very un-English in multiple ways. I don't think you would have gotten many complaints if you had called it a Falaffel.

Is it possible to make an Interactive Diagram use a hexagonal board?

The current standard scripts do not support that. The I.D. represents the board through a HTML table, and in theory it should be possible to create a table with a masonry-like tiling, shifting each subsequent rank by half a cell. This could be done by giving the first cell on each rank colspan 1, 2, 3, 4, ..., and all other cells colspan="2".

I have tried this, though, and it works to some extent. But for reasons that I do not grasp yet it also changes the height of the ranks in a way that I could not control.

Once the pieces are displayed on the hexagonal grid defined by the table, suppressing cell borders and coloring would allow display of a custom hexagonal board image as background.

But some hints to where I put my code and what that code should be are very welcomed.

I think the variable 'mln' gives you the current move number in the Post-Move sections. What you want is special treatment for the first few ('prelude') moves, and then the normal procedure possibly followed by gating when this would be required. So something like:

if == mln 0:
  ... // do what has to be done for the first prelude turn
elsif == mln 2:
  ... // do what has to be done for the third prelude turn
else:
  gosub HandleMove true;
  set waiting where #ori 0 -1; // square behind moved piece
  if not flag #ori and == 1 rank #ori != @ space #waiting: // virgin first-rank piece with something behind it
    add space #waiting #ori; // gate the piece
    empty #waiting;
  endif;
endif;

You stil would have to suppress normal moves for the pieces waiting to be gated. I suppose the easiest way to do this define an alternative version of those that looks the same but does not have any moves, and put those on 0th rank. When its turn comes to be gated you then put the version with moves on the board.

Using grid would probably help you avoid this problem too. With grid, you should be able to make one column or row diagonal, though I have not yet tried using grid with hexagonal boards. My CSS code for hexagonal boards uses absolute positioning, as grid was not yet part of CSS when I wrote the code. Anyway, absolute positioning is another alternative to using tables.

I am not familiar with this technique, but a problem could be that it is not just about positioning the images, but also about translating mouse clicks to cell coordinates. (Which must also work for empty cells, for entering non-captures.) In the table version I have attached event handlers to the cells for this.

I am not aware of any such sources.

I don't think there was any suggestion that the idea is no good, or the implementation was flawed. Just that the presentated explanation of it is very cumbersome.

I agree with Bn Em that it would be much better explained by not presenting this as pieces that change, but just stating that the orthodox pieces get some extra moves on some of the squares. And then show a table that mentions the extra moves for each piece, and on which squares it would get those.

OK, so the betza.txt code, which thus aims to test for whether the move is the one that was just entered, would work fine even in the presence of comments?

And the code to test for whether we are in prelude should look like

if == 0 $mline[$mln]->movenum:

?

rfNX rfCX rfFXX rfNXX ...

Is there a way to enter XBetza on this?

Not on this page. But you could use the configurable applet page that the Piececlopedia links to, and write the Betza move you want in the URL.

I wanted to try out the Blue Gecko (frB4lbW2flFbrFfW) but I can't limit the B move to 4 on this diagram.

I guess I should extend the move-definition aid to 11x11 one of these days. But in case of the Blue Gecko, why bother? The 4th step of the B move will hardly ever be needed. And even when you leave out the frB move altogether, it can already force checkmate. You could also use B3 plus a direct AY leap, which shows that adding the AY leap does not shorten the mate (on 8x8, at least).

It would be an interesting challenge for someone to make an Interactive Diagram for this variant.

It is not the pushing that makes that difficult, but the rule that Pawns have a double-step from the first rank. (That they regain the possibility when returning to 2nd rank can be indicated by making it an ii move.) I suppose it could be done through a morph for the Pawn that forbids access to the enemy half, but then exempt the fmW and fceF moves from that, so that only the fmnD move suffers.

The pushing is not too complex: hop on a piece (d), land on the empty square immediately after (af or yaf), and then step backward for friendly capture with unload (i.e. swap, abud). The bounce rule is implemented (on diagonal moves only) by landing off-board after the hop, returning backward for a second hop, this time hopping off sideways, and swap from there (pyafoabpasabudB).

To prevent such misunderstandings one usually refers to the squares as light and dark, and the pieces as white and black.

If I understood Fergus correctly all that is needed to do it is compare the value of turn instead of mln. Like

if == 1 turn:
... // code for first prelude step
elseif == turn 2:
... // code for second prelude step
else:
  gosub HandleMove true;
  ... // code for performing the gating if needed
endif;

The only thing I am still in doubt about is whether the current betza.txt include file on which the PTA-generated code relies tests for a move being the final one in a safe and reliable way. Because it uses mln for the test rather than turn. But that would affect every preset automated through the PTA, and I have never encountered a case where it did not work.

'Mate' is for positions with white to move, 'mated' for positions with black (the bare King) to move. Mated-in-0 means black is already in (check)mate, mate-in-1 means white's (best) move will terminate the game. The number in those columns is the number of positions from which the result can be forced in the given number of moves (3rd column). There is no mate-in-0, but the logical successor of mate-in-1 would be positions where white can capture the King (which would be illegal in a variant with a checking rule), given in the fore-last row.

The final row gives the total of the columns, expressed as a fraction of the total number of pseudo-legal positions (= ignoring any checking rule, but without multiple pieces on the same square). For generally won end-games the left will be close to 100%, but the black-to-move fraction will be much lower, because of positions where black can capture a King or an unprotected piece. For generally drawn end-games the right number will be close to 0%, but the left number will be much higher because of King captures, and can be over 50% if white has a strong piece.

Janggi is a bit difficult to implement in the I.D., because of the rule that the Palace diagonals are also valid orthogonal directions. I suppose it could be done by morphing, but you would need a different piece type for each square in the Palace, for R, C, K and A. Ban on jump and capture can be indicated by $ in the captureMatrix, in a type-dependent way.

Yes, I had seen it, but had no time to look into it yet.

Quickly glancing at the code in betza.txt suggests that it would never say 'check'; searching for "say Check" only finds "say Checkmate" where it terminates a game, as one of the possible reasons for termination. So I would be surprised if you had ever seen it say 'check'.

Is it supposed to say 'check'?