Comments/Ratings for a Single Item

That is correct. Some years ago I programmed some chess variants for Jocly for which the standard support for chess variants (the 'chessbase' module) was not sufficient. E.g. because these involved multiple royalty (Spartan Chess), multiple capture (Chu Shogi, Tenjiku Shogi, Elven Chess), move induction (Scirocco), piece drops (Shogi, mini-Shogi, Tori Shogi), contageon (Werewolf Chess).

This was all done by hacking the Jocly 'library' files, inserting new, decently looking source code into the 'uglified' files that resulted from compilation, as at that time I did not manage to compile Jocly myself. (I never managed to do that on Windows, and the Linux version I was running was too old.) Because of this procedure, I never payed any attention to source files that did not seem to affect the final product (i.e. when embedding Jocly through the control.html applet). Such as credits.html.

After I learned how to compile Jocly (which required setting up a VM with a newer Linux version) I started a project to 'back port' the games I had implemented to regular source code. And push that to my on-line source code repository, in the 'hgm' branch. This stagnated, because it turned out that the official Jocly version has a faulty implementation of repetition detection (it considers different pieces of the same type as distinguishable), which doesn't hurt much in the variants it implemented so far, but manifested itself frequently in the variants with piece drops I wanted to implement. But it turned out that fixing that bug invalidated all existing opening books. (In particular those for orthodox Chess and Xiangqi, which seemed pretty important.) And the code that was originally used to create those books was never released, and the Jocly developer could not find it anymore.

So I was not sure how to proceed. Incorporating two versions of the base-model.js file in the official source, to preserve one with faulty repetition detection for use with orthodox Chess and Xiangqi did not seem an acceptable solution. The logical solution is to find a way for the variant-specific *-model.js files to bypass the general book-probing code, and contain their own. And then provide such an alternative in the model files for Chess and Xiangqi, to probe their own books according to the old position-key system. But I never got to doing that.

This Jocly file apparently does not recognize a win from a King capture, even though no rule exists against moving into check.

This implementation should apply the checking rule. So it should not even be possible to move your King into check, which means it can also never be captured. The general Jocly code for chess-like games enforces this, and I did not think it was worth the trouble to change it. You could consider it a bit of computer help, which it prevents you to do moves that immediately lose. Compared to the amount of help you already get by only being allowed to play pseudo-legal moves it doesn't seem very important.

Excuse me if the question has been asked already, I don't see it straight.

Why using a Westerned board, bicolor and regular squares? The chu shogiban should be unicolor with elongated cells if I'm not wrong. No?

Large uncheckered boards are very annoying when you have diagonal sliders.

The goal of this implementation is to make it easy for the user to play. The game is hard enough as it is. It is not intended to be a museum display that shows how things were in the Edo period. That is one of the reasons I also kept in the checking rule. I see no point in seducing people to stupidly blunder away their King, only to use the take-back function for resuming the game with a sensible move.

As to the elongated cells: I suppose this was just laziness. I am not sure whether Jocly even has a board view with elongated cells (since it did not implement Shogi), and if it would, it would probably be uncheckered. And I did not feel like designing new board views; it was more interesting to support new game rules (such as multiple royalty, locust capture, piece drops).

Well HG, no need to talk about museum display and Edo period! Cool. I was just asking. My question makes sense anyway. I don't find your choice is consistent. If you want to ease the users up to using a board which completely foreign to Japanese tradition, then why keeping with pieces with kanjis? Chu shogi does not even need pointed pieces by the way.

To my taste, a shogi with kanjis on a checkered board is ankward. That's all.

The checking rule is a different story. I understand that choice here.

You are absolutely right about this, and I have always been aware of it. If you switch Jocly to the 2D representation for Chu Shogi, you can see that I did use pictogram rather than kanji pieces there. It has always been my plan to 'fork' this implementation of Chu Shogi into one that consistently uses kanji (and that could then have an uncheckered board), and one with a western representation. But that is easier said than done:

For one, it is not entirely clear what that western representation should be: pictograms/statues or mnemonic. For westerners kanji are awful, but for large games pictograms/statues are not much better. People would have to learn to associate moves with unrelated shapes or names, as the pictograms only help memorizing the names. (Like kanji would for people reading Japanese.) For a large game this is a daunting task, for someone only familiar with the 6 orthodox pieces. We might have become unperceptice for this, by slowly familiarizing ourselves with ever larger games, expanding the piece repertoire step by step after those from the smaller games became as natural to us as orthodox pieces.

Yet when I conducted a survey on the TalkChess forum what representation for Chu Shogi they would prefer, most people preferred the pictograms over the mnemonic pieces. In the XBoard implementation of Chu Shogi I tried to use pictograms that at least had some resemblance to the move, like swords pointing in the relevant direction for the Vertical and Side Mover.

Then there is the problem for the 3D pieces. The Jocly tutorial gave a prescription how to create those. But it required software that was no longer available, so I could not do it. I could create simple geometric shapes, such as the shogi tiles, with a text editor, after learning the encoding standard for the Jocly pieces. And it is basically only a single piece that I had to create for that. Only the top surface has to be painted differently, and this was just a matter of selecting a JPG image of wood, and using MS Paint to write various kanji on those from a Japanese character set.

Of course I could also write mnemonic symbols on the shogi tiles, and color them differently, but then the use of tiles would just make the symbols unnecessarily small. Perhaps I should use square tiles or draughts chips, and pain mnemonic symbols on those. It would be a horrendous task to create Staunton-like 3D pieces with a text editor, and I never got any further than distorting existing ones. The existing Jocly 3D pieces are not very suitable, (e.g. what Chu piece would you use an Antelope for?), and I am not even sure there would be enough to represent all types.

It appears that this Jocly preset for Chu Shogi is not invoking the counter-strike rule in the following cases:

• for the first part of a non-Lion multi-move after any type of Lion capture.
• if a Lion is captured only on the first part of a non-Lion multi-move