Comments/Ratings for a Single Item

I renamed the malett-chess* files to mallett-chess*, including in the control.php script, but I think it's still expecting the old name, because /play/jocly/mallett-chess does not load the game. Is there anything else I can change to get this to work?

In the Jocly tree there is a file dist/browser/jocly-allgames.js . I think Jocly learns from there what games it supports and where to find their model and view files. As far as I could determine only the model and view files in the /dist/browser/games/ sub-tree are needed for playing a game on-line; the files in the /src sub-tree are only used when you compile Jocly. (Which then creates the /dist sub-tree, where the model and view files are (uglified) concatenations of the source files that are specified in the model and view parts of the index.js file of the game 'module'.) For chess variants the model always includes the base-model.js.

That has worked, though it is still calling the game Malett Chess when it loads. I tried to fix this by changing the name in mallett-chess-config.js, but the misspelling remained even after I purged this file from the cache.

I am not sure where Jocly gets the name from that it displays. One would indeed assume that it is from the *-config.js files, as these files must serve some purpose. (They are created on compilation of the source files, from data that is in the index.js file of the 'module' they belong in.)

Which cache did you clear? Your browser's, or CloudFlare? For Jocly the normal method of clearing the browser cache (Shift + load) does not work. I guess this is because the browser then only refetches the files linked to directly from the main HTML document. Jocly seems to fetch the variant-specific .js files only on command of the JavaScript in the 'core' files, once that starts running afterwards. Surfing to the changed .js file, and reloading that explicitly, should bring the latest version at CloudFlare into the browser cache, so Jocly would then use that if you restart it. (And it would allow you to directly check if the intended changes are indeed present.) Adding a ?nocache=true suffix when loading the changed .js file does not help, as the browser would consider that a different file than the one without the suffix (which is the one Jocly would use), and keep both cached.

BTW, there are still many occurrences of Malett with a single 'l' in the *-config.js file. I am not sure whether that will hurt. Some of the info in this file seems unused.

Which cache did you clear? Your browser's, or CloudFlare?

CloudFlare's. I just loaded it in Vivaldi, which is not the browser I was using before, and it used the correct spelling. So, it is working correctly now, and it was still showing the wrong spelling due to using the browser cache.

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'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.

I got Shako working by redirecting it to the originalShako directory. I'm currently having trouble getting Rollerball Chess to work. The link is

https://www.chessvariants.com/play/jocly/rollerball-chess

Well, Shako was already working after I put the original shako-chess-model.js file back.

Rollerball also seems to have model and view source files where there should have been uglified library files, in my directory. I will have a look to see if I can find the originals.

[Edit] OK, done. I uploaded the originals, but to make those available the CloudFlare cache will have to be flushed, and the model and view files have to be loaded directly with cache flushing in the browser.

François Houdebert has some Shogi piece maps for his Jocly implementations that actually work better than the ones currently in use on this site (except for Tori Shogi apparently). Perhaps we can use those for their respective games?

These skins are a proposal to that purpose.

The first step would be to fix the visuals for chu shogi (lateral mover as in minjiku?, tiger ...).

Then we could add skins according to usage: western, mnemonic...
It is made of png (100x100px).

For tori I made tries but it wasn't good enough.

Joclymatch :

Jerôme has updated his joclymatch page with the latest jocly release. It's a handy page that lets you see the rules in the language of your choice and play human against human.

I'm going to send him Seireigi shogi, Kyoto shogi and Tumurid chessvariant and some missing translations. I didn't dare send the others variants for which I proposed a translation without knowing if you'd be interested - I'm thinking in particular of minjiku, werewolf, spartan, shogi and mini shogi. Let me know if you'd like me to send them too.

Yes, I am interested. But would these work on his version of Jocly? They rely on the drop-model and fairy-model extensions.

Yes, I'm going to send him my complete compiled shogivar branch, which I'm trying to keep close to our pull request, just commenting in index.js on the games we've yet to complete, such as Team-Mate Chess: Scirocoo, chu shogi, ...

He'll have the choice of using the new dist directory, adding to his own or linking to the old and new ones.

I share the dist in case you want to add a 2nd jocly in chessvariant to link to minjiku or werewolf ... fom the play jocly page more easily.

Jerome started trying to integrate new variants (OK gigachessII, KO pemba : with message "JocGame.LetsTwist is not a function" in ZobristInit)

Due to lack of time, he finally preferred to open the joclymatch (Sources - Doc).

Therefore He lets us set it up on our own.

I started trying to use it. It's handy for browsing and consulting rules. There's still a hard problem to fix on the create match. I'll have to look into it.

The second commit in the pullreq branch created this function LetsTwist in the Jocly core, to make the Mersenne twister random function that was already there available for calling from base-model. The latter uses it for creating a table of Zobrist base keys for the corrected repetition detection.

Does this mean that we have to add modifications from src/core/jocly.game.js to src/browser/*.js?

His code use dist/browser/jocly.js. This part is not clear for me yet.

It seems the modification ends up in jocly/dist/browser/jocly.game.js, so replacing that by ours should fix the problem. I think this is the only change I had to make in the Jocly core; all the rest could be handled in chessbase.

it seems to work : https://biscandine.fr/variantes/joclymatch/

François Houdebert managed to fix the Shogi Two Pawns bug (where a Tokin capture on a file allowed more than one Pawn to be dropped on that file) in his Jocly implementation of Seireigi.

@François Houdebert,

What did you do to fix that bug in the Seireigi implementation? Please let H. G. Muller know so we can get it fixed for Shogi and Mini Shogi, as both have the same bug. If you guys have already fixed it, we can ask Fergus to flush the server cache.

Also, if you guys decide to copy the Seireigi Shogi implementaton over to the Chess Variant Pages, I would prefer it to simply be named Seireigi for consistency reasons, but the current name works as well.

I just followed HG's recommendation to swap 2 lines: so it's not really fixed yet on the Jocly branch, only on a test branch.

We'll have to get back to work on improving our pull request when HGM is available for that. I've made a todo list of the remaining topics. I can make myself available for that at this time. I've noted the name change to seireigi. What summary (one line description) would you like instead of "Spirit shogi variant"  : shogi with different promotions ?

If you'd like me to compile a set of new variants for the CVP site, I can do that, it could be a handy way to deploy new variants, change links to a 2nd jocly (remove variant on the first should be easier).

Well, I just came back from Gran Canaria last night, so I can now do everything that required my PC again, including accessing my Linux VM with the Jocly code.

It must be a nice trip this time of year.

Don't hesitate to take what you think is useful on the shogivars branch, if you use the western skins for shogi, don't hesitate to turn the black generals, I turned them but it's not necessarily better!

I just followed HG's recommendation to swap 2 lines: so it's not really fixed yet on the Jocly branch, only on a test branch.

Sure, but it is a start.

We'll have to get back to work on improving our pull request when HGM is available for that. I've made a todo list of the remaining topics. I can make myself available for that at this time. I've noted the name change to seireigi. What summary (one line description) would you like instead of "Spirit shogi variant"  : shogi with different promotions ?

The current description is nice and minimalistic, but I think "Shogi with more varied promotions" would work better for the average player.

If you'd like me to compile a set of new variants for the CVP site, I can do that, it could be a handy way to deploy new variants, change links to a 2nd jocly (remove variant on the first should be easier).

We can at least import your Seireigi implementation to the site. That way I can have a link to that implementaton at the top of Seireigi's Rules page (For now it is in Other Options for Computer Play under Notes).

Oh, and while you are at it, you might as well import your graphics for the other Shogi variants as well (Shogi, Chu Shogi, Tenjiku Shogi), so that the graphics on this site are more user-friendly.

Here's an install link to Shogi, seireigi, kyoto, mini, but note that this may change soon.

For the record, I tested the feasibility with chu seireigi but couldn't make the lion/eagle and falcon moves correctly. But it's still interesting to see what it could become.

I haven't heard of Hectochess yet, but I'll look into it.

Here's an install link to Shogi, seireigi, kyoto, mini, but note that this may change soon.

The link is broken, so you'll have to send a new one.

For the record, I tested the feasibility with chu seireigi but couldn't make the lion/eagle and falcon moves correctly. But it's still interesting to see what it could become.

The Seireigi Lion moves are basically the exact same as Chu Shogi, except the second step can only be done when the first captures something. I sent you a comment on Chu Seireigi's page explaining what I found. You can recruit H. G. Muller's help with the Lion moves.

Hectochess should be easy to implement. It's basically just Chess but with 5 new piece types on a 10x10 board and a few tweaks where needed.

The same link in https

For the Lion we probably could make it work with HGM (it needs to combine drop model + fairy move) but we might finish what we've started first.

Indeed we probably have already everything for hectochess. I might give it a try.

For the Lion we probably could make it work with HGM (it needs to combine drop model + fairy move) but we might finish what we've started first.

Yeah, I would finish what you started first. No need to overwhelm ourselves.

I don't think I will be able to figure out a lot of key aspects for Jocly b/c it is such a complicated interface to program, so I think I it is more prudent to work on other things and let you two handle the Jocly implementations.

Here's a draft of hectochess, which can be accessed from this dashboard so that you can check the rules and thumbnails.

I've chosen to keep the usual representation for the Leo so that people used to Jocly can play directly without consulting the rules too much.

The link to the Hectochess implementation is broken, please fix.

The link to hectochess is restored. I'm going to make some corrections to the shogi model, but I'll probably wait until I'm sure it's fully feasible before finishing it properly.

Okay, the link is fixed. However, it goes to the games dashboard instead of the implemetation itself. I checked, and I didn't see Hectochess listed (or maybe I missed it); however, I did find the implementation's URL.

I have inspected the Hectochess implementation, and it is quite stellar, but there are a few mistakes to fix, which should be pretty easy:

• Black's kingside Knight and Champion have been switched (Champion should be next to the Rook, and Knight should be next to the Bishop)
• White's promotion zone is two ranks too far forward. It should be at the farthest rank.
• A King should be able to castle two or three squares to either side. Currently, the implementation only allows the latter.
• Your board has the white corner square on the left (it should be on the right). Because of this, you ended up swapping the King and Queen (from White's perspective, Queen should be on left side, and King on right side).

Also, some things worth mentioning:

• Hectochess uses a 64-move rule instead of a 50-move rule, due to the increased board size.
• Since there are so many Pawn promotions, it may be beneficial to split the options into two rows or have scrolling on the promotion dialog.

It should be better but castling is not yet fixed.

If you want to check the rules : try again on here and follow this image

The board looks better but there is a weird anomaly in the pattern on the last two ranks from White's perspective, which makes it so that two of the rows appear to be merged into a single row, and that Black's white corner square is on the left.

The other problems are all fixed (including King and Queen setup).

As for castling, it shouldn't be too hard to program...I hope.

P.S. I think your update broke the Werewolf Chess image on the dashboard, just so you know.

I think it's working well now.

Any objections to the rules?

The only problem I can find (which probably isn't that big of a problem in the first place, but may still be worth fixing) is that it takes 50 moves w/o moving Pawns or capturing to draw in the implementation, whereas Hectochess increase that threshold to 64 due to the increased board size.

Apart from that, everything works properly.

I think the 64-move rule could be operational now(not tested).

As for the size of the promotion panel, I can’t change it easily, but as the number of large pieces is not limited, I can't see a situation where a bishop, rook or knight would be chosen, so the question arises of keeping them or not.

I think it should be possible to control the size of the promotion panel in the view file for the game. I remember I have seen that once. Unfortunately I don't remember where. Probably in a variant with lots of choice.

thank you for the advice, I'll look into it but from my point of view, as it stands it's acceptable

I think the 64-move rule could be operational now(not tested).

From my testing it took 62 moves to reach a long game draw, so either you are slightly off. or I may have miscounted.

I did find the line of code you will need to update.

In hectochess-chess-model.js it is this block of code:

				// check 50 moves without capture
				if(this.noCaptCount>=100) {
					this.mFinished=true;
					this.mWinner=JocGame.DRAW;					
				}

It should be changed to this:

				// check 64 moves without capture
				if(this.noCaptCount>=128) {
					this.mFinished=true;
					this.mWinner=JocGame.DRAW;					
				}

As for the size of the promotion panel, I can’t change it easily, but as the number of large pieces is not limited, I can't see a situation where a bishop, rook or knight would be chosen, so the question arises of keeping them or not.

I would keep the Rook, Bishop, and Knight, for consistency reasons.

Hectochess has been out too long for me to change this. Several other programs, such as ChessV, and Ai Ai, have implemented this game, and I suspect that all of them allow these promotions.

It is a bit strange that this test is made in the game-specific model file. It would be much more logical to have it in the chess base model, which also keeps track of the noCaptCount, and compare it to a variable moveLimit that by default would be 50, but could be changed in the game's model file.

This 50-move stuff was a weak spot in Jocly anyway, as the noCaptCount was not reset on Pawn moves before I fixed that.

It's true, especially since I thought I'd done it at the model level, but it must have been overwritten during compilation, so I'll have to dig deeper.

That’s the old name : the processed version is  hectochess-model.js

the sources are hectochess-model.js

So I suppose It might have worked this way.

To reproduce it : you play 64 times a piece? and then you should get a draw, right?

After maybe moving up a Pawn on each side, you move a random non-Pawn piece on each side without capturing anything, ensuring as few positional repeats as possible to avoid 3-fold repetition.

I found the problem. You have the wrong number of plies in your check for the 64-move rule, as shown below:

                if(this.noCaptCount>=124) { // this draws after 62 moves (62 * 2  = (50 + 12) * 2 = (50 * 2) + (12 * 2) = 100 + 24 = 124)
                    this.mFinished=true;
                    this.mWinner=JocGame.DRAW;                    
                }

The number 124 should be 128 (64 * 2  = (50 + 14) * 2 = (50 * 2) + (14 * 2) = 100 + 28 = 128). Like so:

                if(this.noCaptCount>=128) {
                    this.mFinished=true;
                    this.mWinner=JocGame.DRAW;                    
                }

you're right, sorry to have wasted your time on this.

It's not a waste if the problem is fixed.

Currently, I still see the 124 in the noCaptCount comparison in your hectochess-model.js file though.

Well, in case you ever run into trouble with the size of the promotion popup: in terachess-view.js there are the following lines:

  45         // Reducing the promo frame which was overflowing the board screen
  46         View.Game.cbPromoSize = 1100;

So I suppose this is the way you can resize it.

It should be fixed.

But the file may be in a cache. Press [ctrl] + f5 to force js reloading?

indeed, it works well

It should be fixed.

But the file may be in a cache. Press [ctrl] + f5 to force js reloading?

I'll give it a while.

Finishing the capablanca model with its prelude should eventually allow similar variants to be grouped together:

For janus, if we put "ANBKQBNA" in setup (King before queen)

castling become :

    var janus={ // asymmetric, to b- or i-file
        "4/0": {k:[3,2,1],r:[1,2],n:"O-O"},
        "4/9": {k:[5,6,7,8],r:[8,7],n:"O-O-O"},
        "74/70": {k:[73,72,71],r:[71,72],n:"O-O"},
        "74/79": {k:[75,76,77,78],r:[78,77],n:"O-O-O"},
    }

Finally could we split fairy-piece-model and a fairy-move-model in 2 files?

I am trying to do the split now, but in doing this I became aware of some bugs:

The routines cbShortRangeGraph and cbLongRangeGraph in the base model did not enforce brouhaha squares for special moves; moves with FLAG_SPECIAL should also be suppressed. Failing to do so allowed the Fire Dragon in Minjiku Shogi to enter an empty brouhaha square, as all its moves are special because of the burning, and eventually come from cbLongRangeGraph.

What is worse is that the way I implemented the brouhaha squares would suppress storing moves without any mode flags, (assuming that the brouhaha squares would have removed those that would normally be possible), while cbAdvancerGraph tries to generate the entire graph this way (in order to apply the flags later). I could rewrite the latter, but variant implementations we are not aware of might count on the old behavior of cbShort/LongRangeGraph. So I think it is better to change those, and store all-zero flags if this was explicitly requested in the call.

    var janus={ // asymmetric, to b- or i-file
        "4/0": {k:[3,2,1],r:[1,2],n:"O-O"},
        "4/9": {k:[5,6,7,8],r:[8,7],n:"O-O-O"},
        "74/70": {k:[73,72,71],r:[71,72],n:"O-O"},
        "74/79": {k:[75,76,77,78],r:[78,77],n:"O-O-O"},
    } 

Perhaps we should also provide a 'convenience function' in fairy-piece-model for creating such tables, so that we could simply write

var janus = cbCastlingDef(4, 0, 9, 74, 70, 79);

where the first-mentioned Rook would get notation O-O, and the second O-O-O.

It's better to know now.

For my part, I wanted to test the loading from a FEN syntax on a 12x12 board. I was looking for a standard candidate that would be interesting to add. Gross chess?

Yes, it would be easier to understand

OK, I think the split is completed now, and pushed everything to my pullreq branch. The new names are fairy-piece-model.js and locust-move-model.js. (I thought that was a more apt name, and not keeping the same name facilitated tracing which games used it.) I also updated the index.js file to include those in the build; for your games that used fairy-move-model.js I assumed that they would only need the fairy-piece-model.js.

I also added a cbCastlingDef function in fairy-piece-model.js, but it is untested.

I would say there is a there might be a bracket issue in fairy-piece-model.js : Error: unexpected token: '{'

Oops! Forgot to commit the fix for that. I did that now, and pushed it again.

It works with the latest commit.

Concerning castling, I was wondering if cbCastlingDef needs more parameters than that in the case of janus

var janus = this.cbCastlingDef(4, 0, 9, 74, 70, 79);

Ah yes, forgot to report that (but it is in the commit message):

It was also needed to specify the King destinations, as one cannot assume that these are 2 or 3-step away. (And indeed, in Janus they are different left and write.) So the function needs 10 parameters now, 5 for white, 5 for black:

kingOrigin, shortKingDesination, shortRook, longKingDestination, longRook.

Since the introduction of the locust-move-model: chu Shogi has been stabilized and is working very well.

I don't know how you see things going forward, but I have the impression that it would be better to modify a few sprites: tiger instead of buffalo, same lateral mover as minjiku, use of hawk and eagle. We need to check the promotion of silver (keep arrow? or sword), tiger (keep antelope? or giraffe), vertical (ship?).

Once that's done, we could make a doc to explain the promotion lines and how the Lion works. I can help to start if it's useful, but I don't want to go against what you'd like. Let me know if you want help on that or if you prefer to see that later.

The representation of promoted shogi pieces as pictograms is one of the things I am in general unhappy with. It has some advantages to make a promotable piece distinguishable from a non-promotable piece with the same move. But using an entirely different pictogram in a game that already has so many different piece types is hugely confusing. So much that I even wonder if it would not be better to leave the difference invisible. (In over-the-board Bughouse players are used to having to remember whether Queens resulting from promotion revert to Pawns when captured, or just leave the Pawns on the board, having to remember they are Queens...) When I implemented Chu Shogi in pictogram representation if XBoard, I added special pictograms for promoted (Crowned) Rook and Bishop, Vertical and Side Mover, which were slightly less detailed versions of the normal pictograms. (Which for the Movers I took to be (standing or lying) Swords, because their shape is a good reminder for the move. In a similar spirit I took standing and lying narrowed Queen symbols for the Flying Ox and Free Boar.)

I think we should give Chu Shogi its own set of pictogram sprites. We could then take pictograms with red outlines or details for the non-promotable equivalents, like the kanji pieces do. And add a horizontal sword to it for the Side Mover. That set should then also made to be optimal for Tenjiku and Minjiku Shogi. (So the flying pieces should be in there too, some also in red.) Most pictograms can simply be copied from the wikipedia-fairy-sprites, and then reoriented or recolored as needed.

If we can make a tenjiku-set-view that can be used for chu shogi, it will have an important impact on the existing chu shogi model, but it's probably the right solution. At this stage, I don't know enough about tenjiku shogi to propose a sprites file in the right order (easier to manage promotions). But I've made a few attempts with icons  that could be used as a complement of yours.

sample 1 : chu shogi in bad order

sample 2 : chu seireigi in the right order

I like the duck, what was it used for?

Tenjiku Shogi is basically an extension of Chu Shogi. Some pieces that in Chu Shogi are only available as promoted pieces, already are present in the initial setup, and promote further. There are also many new pieces in the initial setup, most with their own, entirely new promotions. But all Chu Shogi pieces participate except the Go Between.

This is why I called the kanji piece set tenjiku-set-view rather than chu-set-view; the idea was that it would at some point be extended with all remaining Tenjiku pieces. The kanji tiles only differ in diffusemap anyway, and the diffusemaps for all Tenjiku kanji tiles already exist, used in the Jocly Tenjiku implementation here on CVP. (But under different names from how we would want them.) They would just have to be committed (in a directory chessbase/res/shogi/tenjiku-diffusemaps, using the naming system also used for the chu-diffusemaps).

I added the Duck as a quasi-mnemonic representation for a diagonal hook mover (Long-Nosed Goblin or Capricorn) from the large Shogi variants, and in particular my shrunken version Macadamia Shogi. But I also used in for the Half Duck in Chess with Different Armies.

Sounds good to me.

Do you have time to initialize the sprites file to make your icon choices at the moment? Is there any way I can help?

I should be able to make a pictogram sprites set for in the tenjiku-set-view, on short term. From looking at your sample1 it appears coloring the eyes is enough distinction for indicating non-promotability. On pieces that never promote (such as Queen and Lion in Chu Shogi) I would prefer not make that distinction. But that would work only if we also do not do it in the kanji tiles. For Tenjiku we would also have promotable Queens and Lions. In the case of the Queen I would color the dots at the tips of the crown rather than a band near the bottom; these look more like eyes. The new 2d images for the crowned pieces look better than the old, (I thought in particular the old Crowned Rook was bad), and also have an 'eye' in their crown, which can be colored.

I would not work with upside-down pieces. These cause problems in flip view, and this isn't really a mnemonic piece set. I like the General symbols I made better than those in sample1, which remind me too much on something a Jester would hold. I also think my Phoenix better fits in with the Wikipedia set than any of the possibilities shown in sample1. The two pieces just before Leopard would make very nice Kirins, though; the leftmost probably fits better with the set (but the outline would have to be fattened).The other is too detailed. The 'pumpkin' is a Fire Demon? The Lance gives too much suggestion of a diagonal move, IMO.

I very much like the symbol for Go Between, and perhaps something similar should be used for Reverse Chariot. Was this the idea of having it in two sizes? There is not much risk of confusion, as they can never leave their file. Perhaps vertical stretching would give a better distinction; the eye is more sensitive to shape than to size.

As an aside, some of these piece names are really strange; the Reverse Chariot is not really reverse but bidirectional. Non-Japanese Chu-Shogi players have shown very little imagination in making English names. They don't hesitate to replace Fragrant Chariot and Angle mover by Lance and Bishop, (no doubt western regular Shogi players must be credited for that), but then they insist in calling an obvious Queen 'Free King' instead. I would have called the Reverse Chariot a Streetcar (which is something confined to its track). And the Vertical and Side Mover a Climber and a Sweeper. (The latter as a soccer analogy, where this is the term for the last defender.)

The Ox and Boar are nice (although the latter needs some fattening), but I still wonder whether it would not be better to use pieces with mnemonic value like a narrowed Queen's crown. People need to be reminded of the move, not so much of the name. And I think in a huge game like Chu Shogi they need all the help they can get; it really overwhelms the orthodox-Chess player. For 4-fold-symmetric pieces mnemonic value does not need flipping of the symbols. Perhaps we should reserve the Ox/Bull and Boar symbols for Dai Shogi, where there are a Violent Ox and Angry Boar.

I am not sure if there is any particular way in which I should order the pieces. I have not yet studied these dual-skin examples. Is it essential that all the alternative skins use the same ordering of sprites? I don't think we already have a 'bare kanji' sprites file for Chu/Tenjiku Shogi like we have for regular Shogi. So I suppose we can use any order of the pieces in teh sprite file, as long as the tenjiku-set-view points to the correct cutouts. Problem is that I forgot how I did make this shogi-sprites file. I suppose it must have been with GIMP on Linux, as MS Paint doesn't support transparency.

I agree :

-In the case of the Queen I would color the dots at the tips of the crown rather than a band near the -bottom; these look more like eyes.
-I would not work with upside-down pieces.
-I also think my Phoenix better fits in with the Wikipedia set than any of the possibilities shown in sample1.

The two pieces just before Leopard would make very nice Kirins, though; the leftmost probably fits better with the set (but the outline would have to be fattened).

→ May be we should keep the giraffe (the 1st is the dragon king of a skin in lishogi, the second was an attempt to make a kirin but not good enough)

The other is too detailed. The 'pumpkin' is a Fire Demon? The Lance gives too much suggestion of a diagonal move, IMO.

→We can keep the icones oj minjiku for consistency

I very much like the symbol for Go Between, and perhaps something similar should be used for Reverse Chariot. Was this the idea of having it in two sizes?
→ We could keep one the two (I didn‘t know which size was the best)

The Ox and Boar are nice (although the latter needs some fattening), but I still wonder whether it would not be better to use pieces with mnemonic value like a narrowed Queen's crown.

-->the idea is appealing, we can give it a try

OK, I pushed a new commit to pullreq, which uses tenjiku-shogi-picto-sprites.png in tenjiku-set-view.js. I limited the indication for promoted pieces to a single red dot. In case of the Queen it is perhaps better to put it in the center of the crown, like it were a ruby. I made narrow crowns by cutting away the central spike from the Queen symbol, in two orientations, and also a rotated sword.

I am reasonably happy with the representation, but some images still need some work; the white Tiger needs fatter lines in the jaw, and the Whale has to be redone completely. Perhaps the white Go Between as well.

Perhaps the Reverse Chariot could use another symbol; it now uses the pictogram that normally represents the War Machine. (Well, what can I say, it it had wheels...). We could change it to a real chariot.

As to harmonizing this with Minjiku Shogi, the problem is that the latter uses the fairy-set-view to have western-style 3d pieces, and that a horizontal Sword is not in the 2d sprites set there. So in 3d I used the War Machine. (Which is an orthogonal piece, like the Side Mover, which in Minjiku even has a two-step vertical move initially.) But I think it is much better to have the sword symbol in Chu/Tenjiku, since the Vertical mover is also a Sword, and they are identical, albeit rotated pieces. We could replace the sword sprite in the fairy-sprites file by a horizontal one, and let Minjiku use the 3d Sword that I made. There are no western variants I am aware of that use a Vertical Mover, or in fact any kind of sword.

bravo, that's really convincing. Of course, there are still some small details to be improved, but that can probably be done easily in a second phase (whale, some red dots ... ).

Here are a few links from lishogi if you need :

Chariot  Tiger  Rook-chariot

Regarding minjiku, I think the idea of having the same sword for the piece is a good one. It'll help you find your way around when you switch from one game to another.

attempt for a cart and whale :

While I was at it, I thought I might as well extend the tenjiku sprites with the the pieces for Tenjiku Shogi. My first attempt is here. The Wolf and Bull are good enough for Dog and Water Buffalo, the Griffon seems a logical choice for Lion Hawk. I used a Star for the Free Eagle, which moves as Queen with some close-range locust capture, in the hope that a star would cause the association with 'all directions'.

I am least happy with the various kinds of Soldiers. I represented the Chariot Soldier by a Cannon, because it is also associated with war, and has wheels. For the Vertical and Side Soldier I picked two warrior helmets, but there is no vertical or sideway aspect to those. Perhaps they should be represented by Bows in two different orientations? Then all Soldiers would be represented by shooting equipment.

I also included sprites for the not-yet-implemented Dai Shogi (the third shogi variant strongly related to Chu Shogi). The Wolf can be used there for Evil Wolf, (There is no Dog there), and I left in the Wazir, Ferz and small Bishop and Rook sprites for representing Angry Boar, Cat Sword, Flying Dragon, and Violent Ox (since the latter two are B2 and R2); it seems better to represent these by move than by name. That only leaves the Stone, General, for which there unfortunally is no logical continuation of the Generals series. So I took the Scout symbol for that. We can worry about this more when we would actually implement Dai Shogi.

[Edit] Strange thing: when I was trying it out it appeared to have lost its opening book, and I got error messages in the console about requesting Zobrist keys for invalid board squares. This turned out to be associated with this strange mode Jocly sometimes gets in, where white is at the far end of the board despite "View as player A" having been selected, but the white pieces still all look away from you, and thus have the wrong orientation w.r.t. the board. I usually solve that by firest viewing as player B, and then again as A. This then also granted it access to its book again.

I don't know enough about the game to have an opinion on these choices, but it sure becomes a lot more accessible this way. Note that there are several dogs available in the musketerchess editor if needed. I don’t know if you saw it : I posted yesterday a whale on a comment that may be a little better than the previous one.
Concerning the initialization bug of the selected player, I've noticed it too, not reproduced yet, I'll have to look in the code to see what's going on. A problem loading preferences?

I get the impression it has something to do with the state Jocly had when you left it in the previous session. But I still have not figured out what.

I decided to go for the Bows. I pushed the lot to pullreq; tenjiku-set-view should now contain all the 3d pieces for Chu and Tenjiku Shogi; only 6 pieces for Dai Shogi are still missing. The 2d sprites should already be able to handle all three shogi variants.

I saw your improved Whale, but I decided to remake it anyway in SVG, to get a properly anti-aliased image  The fact that the sprites are 100x100, and usually rendered at smaller size already mimics some antialiasing, but for certain demagnifications it can still come out poorly. So I decided to take no risks.

Now that we've fixed the icons, we're ready for the next big step.

To finalize the pull request, we need to add game rules, and this is necessary for shogis anyway, especially for chu shogi.

I have made a draft of the rules for shogi, mini shogi and chu shogi which can be consulted here (select the game / buton rules on the top)

This could be a starting point for you if you find it useful, you can take them, rework them and put them on the pull request if needed.

The sources are here, it assumes though that you also use the same kind of sprites for shogis

By the way I saw this icon, I wondered if it could be used for the whale and the white horse :

.

It is a very nice trident, which allows a good distinction between the white and the black piece. A very good mnemonic for the White Horse and Whale move. With the image of a Whale I can live (and in XBoard I tried to draw a Dolphin in a shape that resembled the move), but the use of a horse image for a piece that moves so very differently from an orthodox Knight has always bugged me. Currently I use the Nightrider, but I thinkt this trident would be much better.

I update the rules with trident

It comes from musketeerchess

If you want to use the trident and save some time : you can get the sprites here.

Changes :

-remove red dot between axes

-use trident instead of whale and white horse

-remove few pixels below the white fire demon

I am not sure the trident should be used for both the Whale and White Horse. It would suggest that it points in the direction in which it moves, but for black this would just be the opposit. And if you pair the flipped versions for the same type, it would look all wrong when viewed from player B. I am not unhappy with the diving-Whale image; it also suggests something that goes down, without suggesting too much that 'down' would be a direction relative to the symbol. An upside-down symbol would strongly suggest the reason for displaying it in an unnatural way is that you want to indicate a direction with it.

I 'parked' the dot near the Axe for copy-pasting it onto pieces that needed it; the Axe is not used in the set. But the idea was indeed to remove it from the final set. I had not noticed the stray pixels near the Fire Demon.

I'm sharing some sprite tests for a charioteer or lateral and vertical soldiers, I don't know if we still need them because we already have a satisfactory result :

The rightmost chariot mightbe good for the Reverse Chariot. I admit it is more remaniscent of the name than of the move, but in this case that is not so important. Lance and Reverse Chariot are practically useless people, and players will quickly learn to simply ignore what is in the edge files, without paying much attention to how it looks. It is mostly the location on the board that identifies it.

tenjiku-set-view.js should probably use :

res/shogi/tenjiku-shogi-picto-sprites.png

instead of

/res/fairy/tenjiku-shogi-picto-sprites.png

?

concerning tenjiku, should the fire demon slide vertically? In wikipedia I have the impression that it's horizontally.

In Modern Tenjiku Shogi it slides vertically. This is another contested rule issue. The first western publication was by George Hodge's TSA ("The Shogi Association") and gave a vertical slide. IIRC it seems that only two historic sources are known that describe Tenjiku Shogi, and that one of those contains an inconsistency between the text and the accompanying image. (The text says vertical, the image and the other source consistenly say horizontal.) So it is 3 vs 1, as well as that it seems more likely to err in a text than in a picture. The best argument for a vertical move seems to be that "there could be yet undiscovered sources that also state it moves vertically".

But the modern rules do not claim to be the historic rules. I used the modern rules for the Jocly implementation so it could participate in the correspondence championship.

tenjiku-set-view.js should probably use :

res/shogi/tenjiku-shogi-picto-sprites.png

instead of

/res/fairy/tenjiku-shogi-picto-sprites.png

?

Well, it already worked for Chu Shogi, didn't it? So how could it be wrong?

there was a refactoring on the last commit, wasn't there?

src/games/chessbase/res/fairy/tenjiku-shogi-picto-sprites.png     [deleted file]

Impact on tenjiku-set-view.js ?

thank you for the clarification I'm still learning...

Indeed, that doesn't seem correct. I moved the file to */res/shogi/tenjiku-shogi-picto-sprites.png, and the tenjiku-set-view.js should have used the new link. I guess it worked in my tests because the old file was still there.

I believe that the view-as bug comes from

jocly/examples/browser/js/control.js line 236

I think adding a test like could solve it. I didn’t dare doing it.

if(viewAs===undefined || Object.is(viewAs, null) || viewAs==="null")
      viewAs="player-a";

It probably comes from string like "xxxx.view-as": "null" in window.localStorage

I played Tenjiku Shogi and I encountered the following message : "Undeclared Zobrist array index -1 as param board"

You might reproduce it with the following game after attacking the black phoenix with the white fire demon :

Computer(B) level : strong

I have alo seen that message, but only in the state where the view is upside-down. It then also couldn't read its book. Fixing the view made the problem disappear.

I think there's something odd about this particular case, because after the phoenix is taken, the black king is threatened.
This doesn't stop the black fire demon from attacking elsewhere and threatening the white king over the kirin. The fire demon doesn't have a flying diagonal, does he?
It's not the view-as bug, if you look at the local store ([f12]  then application tab in chromium), everything's normal.

I have no idea how such a game can be loaded into Jocly. The Load button doesn't seem to work; it gives me a file-browse window, but doesn't see any files.

if you right click on this link + select "save target as" : you shoukd be able to get the file tenjiku-chess-demon2phoenix.json on your disk

then select it from the load button and your browser should be able to initialize the game.

OK, I see why it didn't work: Instead of downloading the file I had copy-pasted the text on the into Notepad, and saved that. But then I had to pick the filename myself. In the file-browse dialog that opens upon pressing Load, the file-type pulldown was by default set for *.js files. So I saved it with .js extension. But then I never saw the file, only folders.

Turns out the pulldown did not say .js, but .json, but that the "on" part was clipped off because of the button width. When it had .json extension as in the downloaded one, I had no trouble loading it into Jocly. I still haven't figured out how I could view the entire game, other than playing it in reverse through takebacks. But at least I can see the final position where the trouble manifests itself.

I think the problem is that Jocly's test for being in check (through base-model's cbCollectAttackers function) cannot see attacks through burning or area moves. So it happily plays on in this checkmated position. Which in the look-head by the AI of course leads to the King being captured. The Jocly code chokes on that, because it assumes that a King is always present. It keeps track of where it moves, but that tracking is left at the square where it was last seen before it got captured. But that square is then empty (code -1 on the board), and when it tries to update the hash key for a piece of that type it gets out of bounds in the Zobrist table, as -1 is not a valid piece type, so that no keys were defined for it.

The playing-on seems acceptable here, as officially Tenjiku games do not end by checkmate but by King capture. (Purists might complain that with normal checkmates, not involving burning or area moves, which Jocly does recognize, it really terminates the game one move too early.) That it then crashes is of course not acceptable. The pullreq branch contains a commit that fixes that; the evaluation in base-model now tests for presence of the King, and considers its absence a game-terminating condition as well. That prevents further processing of positions without King, and thus the crash. But of course the version you are playing here is not based on the pullreq branch. The tenjiku-chess-model.js still contains the original base-model.js. I could of course hack the patch for detecting King absence in there.

This touches on an issue that has bugged me from the beginning; the Jocly AI really is an extremely inefficient search engine, as far as chess engines go. Michel coding skills in JavaScript are uncountably many leagues above mine, but he obviously is not an engine programmer. The largest flaw is that in the search he generates legal moves only. This has enormous computational cost, as he does it by playing all pseudo-legal moves one by one, then looking with cbGetAttackers whether the King is under attack, and taking the move back. And then delete the move if it was illegal.

The point is that normally only a very small fraction of the moves puts your own King in check. So most of the time the test for this was a waste of time; the move is legal and you have to try it anyway to get its score. Almost all chess engines therefore use pseudo-legal moves in their search; if they occasionally try an illegal move the opponent will see he can capture the King, which gets maximum score, so that the illegal move will have maximum negative score, and would be discarded. On most moves this would not happen, and you would have saved the time for separately testing whether the move was legal; even in cases where the move was illegal it is a question of whether detecting that by letting the oponent generate all his pseudo-legal moves, than by using the dedicated check test.

Now the problem is that this cbGetAttackers function can get horrendously complex in a game with unconventional pieces. It works by reversely tracing all paths in the move graphs of all pieces that visit the square, to see if it finds the corresponding piece at the origin of that path. To this end it initializes a ThreatGraph, which combines these reverse paths into a tree (so that coinciding parts just before they hit the King only have to be traversed once). If you are dealing with orthodox Chess there might be some merit in this; you only have to deal with Knight jumps and Queen slides, the latter quickly finding an obstacle in their path when you step through them from the King, during most of the game. But even then the case for the Knight is dubious: you would have to test 8 squares around the King for Knight presence. The alternative method of just generating all opponent moves would make you generate 8 moves for each Knight, to test for King presence. If the opponent has two Knights, that is indeed twice as much work. But if he has none...

The point, however, is that when the variety of moves in the variant gets larger, this threat graph gets unweildly large. If Xiangqi Cannons participate, you cannot stop tracing the reverse path at the first obstacle, but will have to look beyond it for Cannons. If Tenjiku-style jumping generals participate, you have to trace the Queen moves all the way to the board edge. If Griffons participate you have to follow paths around corners. Camels, Zebras, Antelopes each give you 8 extra squares around the King to test. Before you know it, you have to test almost any square on the board for presence of a particular piece. And when you don't keep track of which pieces are stil present, (as Jocly doesn't), you have to keep doing that for the entire game, even if the pieces that could make these strange moves are long gone.

I think the Jocly AI would benefit enormously by just abandoning this legality testing, and let it search until King capture, the huge value assigned to the King taking care of the illegal moves never being preferred. For testing the legality of the user's move it would remain essential to do it, though. So there should be a way to let cbGenerateMoves know whether it is generating for the AI's search, or for highlighting user input moves; in AI mode it could then just return the cbGeneratePseudoLegalMoves result, and do away with this costly cbQuickApply / cbGetAttackers / cbQuickUnapply loop.

Another silly design characteristic is that the material scoring in the evaluation fuction is done by looping over the entire board to add up the value of all pieces it finds there. This is something that can very cheaply be updated incrementaly, by just subtracting the value of pieces that get captured in cbApplyMove. It already does such incremental updating for the hash key zSign, so why not for the material score? Same for counting pieces of each type. This really makes Evaluate orders of magnitude slower than it could be.

Ummm, I hacked in the king-capture test, but it doesn't seem to prevent the problem. And testing also showed a basic flaw of combining imperfect legality testing with king-capture termination: when you put the AI in check or mate through an undetected move, it would still think that capturing the King is illegal when it counter-checks you with a check that is detected.

This also confronted me with what you had already seen: it tries to keep me in perpetual check with the Demon. But it appears to think the Demon has jump-capturing ability. That it could check my King through the Kirin didn't strike me as strange, as it can capture the Kirin and burn teh King in the process. But when I evade that check with K-i2, it thinks the Demon can check me from d7, through a Pawn and Lion!

This is weird. For Tenjiku I hacked special code into cbGetAttackers to see the jump attacks: it scans the Queen rays from the given square (using the GG graph), and looks whether it encounters pieces that have a 'rank' in the jumpers[] array. This array is not supposed to specify a rank for the FD or +WB, though.

thanks for the explanation, I had a feeling it wouldn't be easy to solve.

It is even stranger than I thought. It thinks the Demon attacks h1 from d5, but not from e4, c6 or b7. After K-i2 it thinks the Demon attacks it from d7, but not from b8, and not even from f5, where it has a direct line of sight. And from d7 it thinks Q-h3 or even Ln-h3 will block the check; from e6 it thinks it is checks that cannot be blocked. This is all very erratic.

Also strange is that after loading the game, it highlights thw white pieces. But also the black +WB, and when I click it, it thinks it moves like a Pawn! I must do TakeBack and replay the WB promotion to make it understand the +WB is not a white Pawn.

OK, I figured it out. The problem was in the graph of the Demon, created by a modified version of cbLongRangeGraph. In this version you could ask to suppress FLAG_CAPTURE and FLAG_MOVE in the first N moves of a slide, and the Demon used this for N=3 to prevent double generation of moves that would already be generated by the AreaMove routine.

But unlike what I thought at the time, clearing those flags would leave it unblockable at those squares, w.r.t. conversion to the ThreatGraph. So the Demon effectively was a super-ski-slider, which would directly jump to the 4th square  in any direction, and slide from there. What is needed to make it blockable is set FLAG_STOP on those squares. I do that now, and the problem disappeared.

The problem that after game loading it highlights the black +WB with the white pieces still exists.

The problem that it thinks it can defend against a King capture by perpetual checking with recognized checks also remains. But in this position that was not possible. So it doesn't check, which allows me to capture his King with a move it thinks legal, and the missing-king patch then makes it conceed that "A wins".

I guess the best solution for the "king capture by legal move only" problem would be to declare all pseudo-legal moves legal in Tenjiku Shogi. I can do that in the version on my website by suppressing the legality-test loop in cbGenerateMoves , and copy the moves from cbGeneratePseudoLegalMoves to this.mMoves entirely. (That should also speed up the AI enormously.) For the pullreq branch it might be good to introduce a parameter in base-model that the user could set in its game definition to switch the search to king-capture mode.

That would still leave the problem for variants that do terminate on checkmate, but generate special moves that cbGetAttackers cannot see. The Ultima Withdrawer was such a piece; it attacks adjacent squares, but only if there is room in the opposit direction to move.

[Edit] I now made it such that moves that capture the King are exempted from legality testing. That makes counter-checking pointless. As a side catch I also fixed the move of the black Iron General, which had its diagonal moves in the opposit direction.

I'm glad that this complicated problem has been solved. It seems a good idea to add a parameter in base-model to set to switch the search to king-capture mode in the pullreq branch.

I did some experiments with the search mode in Tenjiku Shogi. The test position was basically that after 1.P-j6 (except that I first did two Leopard moves to get it out of book). At level 'medium' it would normally see the mate threat, and play 1... SE-n11.

First I disabled legality testing altogether. Then it doesn't defend against the mate threat, and even after 2.VGo10# it plays on, and only conceeds after I capture the King. Not good. This could have been expected; King capture occurs two ply after checkmate, and GenerateMoves already tests for it when it discovers there are no legal moves. I moved the testing for missing King from the Evaluation (which would make it to be discovered only after the King capture was played) to the move generation, where it declares a win if a move is generated that captures a King. That did still not make it see the mate threat at this level.

Now chess games in general are not won because you see checkmate from a larger distance, but by gaining so much material that the opponent cannot see checkmate no matter how deep he searches, as he is too weak to inflict it, so that sooner or later you will stumble into one. But Tenjiku Shogi is sort of an exception to this, with these jumping generals that threaten mate even on a full board.

So I tried something else: test the pseudo-legal moves for legality until you find a legal one, then accept all others without testing. This way you will always discover it when you are (check or stale)mated. But in the common case (where you are not, and not even in check) the very first move you generate is already very likely legal, so that you on average will hardly subject more than a single move to this check test.

Unfortunately it still did not defend against the mate threat after this. But when I execute the mate though 2.VG-10o#, it claims a draw. Turns out that in the place where it tries the moves with cbQuickApply, to test them for legality, it also tests whether those that turn out to be legal do deliver check. It stores that in the move, and when the move is played to create a new position, it takes its in-check info from there. So by skipping this for most moves it would not know anymore that it is in check, and thus judges that the situation without legal moves is a stalemate. (And apparently I forgot to let it know that in Tenjuku stalemate is a win too.) It is thus hardly amazing that it doesn't worry about that; draw with gote is a good result.

So in the code for deriving the game result when there are zero legal moves I let it do a check test if the in-check status was still undefined. That solved it: it plays 1... SE-n11 again.

But that it doesn't check all moves for legality means that it will also highlight the illegal moves at game level, except when by coincidence it was the first move that was generated (or in any case not preceded by any legal moves). This allows you to step into check, or stay in check. (Unless you are already checkmated through moves that its check test understands. Then it declares game end and you cannot move anything at all.) In Tenjiku Shogi this would of course be allowed, and improves the uniformity of the highlighting, as you were already allowed to step into checks that the check test was blind to (burning and capture by an area move).

What is a bit odd is that when you do step into check, it declares game end, without actually performing the King capture (or allowing you to do it, in case you win).