Comments/Ratings for a Single Item

I am not sure what this 'dir' argument is supposed to do. It is not needed; just specifying a 'game' as argument to control.html has always been sufficient for me.

It seems the Jocly library uses a summary file jocly-allgames.js that lists all the games by name, one line per game, with the most essential information on that game. This line refers to a file <game name>-config.js (also created during the compilation process that created the library), which contains an elaborate overview of all the 'resources' used by that game, and where to find those. For the chess variants these are also in the chessbase directory.

E.g. a few lines of jocly-allgames.js:

"courier-chess":{title:"Courier Chess",summary:"12x8 chess (12th century)",thumbnail:"courier-thumb.png",module:"chessbase"},
makruk:{title:"Makruk",summary:"Thai Chess",thumbnail:"mk-thumb.png",module:"chessbase"},
"elven-chess":{title:"Elven Chess",summary:"10x10 Chess with a double-capturing piece",thumbnail:"elven-thumb.png",module:"chessbase"},
"spartan-chess":{title:"Spartan Chess",summary:"An unorthodox Spartan army takes on the Persian (FIDE) army",thumbnail:"spartan-thumb.png",module:"chessbase"},
"werewolf-chess":{title:"Werewolf Chess",summary:"Queens are replaced by contageous Werewolfs",thumbnail:"werewolf-thumb.png",module:"chessbase"},
"team-mate-chess":{title:"Team-Mate Chess",summary:"Chess with pieces that can only force mate in pairs",thumbnail:"team-mate-thumb.png",module:"chessbase"},
"scirocco-chess":{title:"Scirocco",summary:"10x10 chess with many weak, bt promoting fairy pieces",thumbnail:"scirocco-thumb.png",module:"chessbase"},

I guess the 'module' field points to the sub-directory in 'games' where Jocly has to look for the <NAME>-config.js, which informs it on what it needs to run the game. Since the config.js files are created in the compilation process, they are uglified. But before I knew how to compile, and was hacking games directly into the library, I made some of these by hand (e.g. elven-chess-config.js).

I am not sure what this 'dir' argument is supposed to do.

It is needed for finding the description, rules, and credits files for each game, which are then displayed below the board. I have not found any means by which Jocly itself will display these.

I guess the 'module' field points to the sub-directory in 'games' where Jocly has to look for the -config.js,

Yes, I have made an array from it with just the directory information for each game. So, I modified the rewrite rule in .htaccess to just use the name of the game.

As I make database entries for the games, I want to get the credits right. When I used grep to find all the files with credits for Muller, the only games that came up were Elven Chess, Spartan Chess, Team Mate Chess, and Werewolf Chess. I thought you had coded more than this. Please let me know which other games you should be credited on.

I did indeed some more games, but I did not make rule descriptions of those. (Because they were not my own inventions, and since, like you say, Jocly did not display them anyway, I supposed people could find the rules elsewhere.) Which is why the grep doesn't find them. These other games are

• Scirocco (revised)
• Shogi
• mini-Shogi
• Tori Shogi
• Chu-Shogi
• Tenjiku Shogi

I made an inventory of how we are doing w.r.t. Jocly:

Variants for which we have pages that do work:

• 3D Chess (3D)
• Amazon Chess
• Baby Chess
• Brusky Chess (hex)
• Byzantine Chess
• Chess Attack
• Courier Chess (no thumbnail)
• Xiangqi

Variants mentioned on the overview page, which fail to start Jocly when you click the link. (Probably because these are implemented in the 'old way', using an off-site link to the Jocly engine on a website that no longer exists.) Those marked with * are supported by the Jocly version on CVP, and can be started by starting another variant, and use the 'Other Jocly games' link on the Jocly page:

• Capablanca Chess *
• Cavalier Chess
• Chess *
• Embassy Chess
• Grand Cavalier Chess
• Grand Chess *
• Grotesque Chess
• Modern Carrera Chess
• Univers Chess

Variants supported by the Jocly version on CVP, but which do not have their own (working) Jocly page (with rules and images), and are not directly accessible through links on the overview page:

• 360 Chess
• Basic Chess
• Capablanca Chess
• Carrera Chess
• Chancellor Chess
• Chess
• Chess960
• Cylinder Chess
• De Vasa Chess (hex)
• Demi Chess
• Duke of Rutland Chess
• Elven Chess
• Gardner MiniChess
• Gigachess
• Glinski Chess (hex)
• Gothic Chess
• Gustav III Chess
• Hyderabad Decimal Chess
• Janus Chess
• Kaiserspiel
• Los Alamos Chess
• Losing Chess
• Makruk
• McGooy Chess
• Metamachy
• MicroChess
• Mini Chess 4x4
• Mini Chess 4x5
• Modern Chess
• Modern Circular Chess
• Modified Chess
• Musketeer Chess
• Raumschach (3D)
• Reformed Courierspiel
• Rollerball Chess
• Romanchenko's Chess
• Scirocco (no thumbnail)
• Shafran Chess (hex)
• Shako
• Shatranj
• Shogi (no thumbnail)
• Smess
• Spartan Chess
• Sultanspiel
• Sweet 16 Chess
• Team-mate Chess
• Terachess
• Tori Shogi (no thumbnail)
• Tutti-Frutti Chess
• Werewolf Chess (no thumbnail)
• Wild Tamerlane
• Wildebeest Chess
• mini-Shogi

Variants that are supported by the Jocly version on my website, but not on CVP:

• Chu Shogi
• Tenjiku Shogi

@HG: maybe not a useful info for you: I can access to some games by this site, below the example for Gigachess. On my Mac it works only on Firefox, not on Safari.

https://mi-g.github.io/jocly/examples/browser/control.html?game=giga-chess

Thanks. But I think what we have here is the same thing:

/http://chessvariants.com/play/jocly/examples/browser/control.html?game=giga-chess

It is just that there appears no link to it on the Jocly overview page. Or from the Gigachess article. So you can only play it here by selecting something that does work (e.g. Courier Chess), and then using Jocly's own "other Jocly games" link to select GigaChess.

Okay, so it looks like the only Jocly games that are working are those originally supported by Jocly, and the ones I added support for are no longer working.

Probably because these are implemented in the 'old way', using an off-site link to the Jocly engine on a website that no longer exists.

Is there an easy fix for this?

I looked at my pages for playing Jocly with Cavalier Chess, and I found no links to the Jocly website. So, the problem must be in the Jocly code itself, which I found too hard to follow when I looked at it, as it is unformatted and in JQuery, which I've never learned. Maybe installing the latest version of Jocly would help.

The recommended fix for this would be to implement it the new way, which is to include the *-model.js and *-view.js files in the Jocly library that we host here. I don't think the current Jocly version supports including 'external' game definitions anymore. So it would not help to redirect the link to the Jocly engine on the server that no longer exists to the Jocly we have here. (But I could be wrong about this.)

If we could lay our hand on an old version of the Jocly engine, from the time when it did support external game definitions, and install that here in addition to the newer Jocly, we could link to that. But I am not sure such a Jocly version was ever released; this support for external definitions might be from the time when Michel wanted to keep the source of the engine private.

An additional problem is that to include anything new in the Jocly library, Jocly would have to be recompiled. And when I first used Jocly I was not able to do that. So I just hacked a few variant implementations of my own directly into the library. After I learned how to compile Jocly I started backporting those hacks to the Jocly source code in my own on-line repository. But I never fully finished that task.

If I still remember the procedure, I could try to hack your implementations directly into the library too. IIRC iy was needed to place the model and view files in the jocly/dist/browser/games/chessbase/ folder, together with a config.js file, and html files for a description, credits and rules. (These HTML files seemed to be optional, because when you use the control.html example to run Jocly, there doesn't seem to be a way to display those.) The model.js file had to be fused with the standard chessbase.js file. (Easiest way would be to just take one of the games I put in, like spartan-chess.js, and replace the easily-recognizable model part by another model file. The chessbase.js file part in there is 'uglified'.)

To make the game selectable a line for it had to be added in jocly/dist/browser/jocly-allgames.js file. Of course any new 'resources', like new 3d pieces, would have to be placed where the implementation expects them.

BTW, I now started experimenting with the control.html page of the Jocly page on my own website, for making the rules HTML page viewable. To this end I added a button 'Show Rules' in the Control section, which opens the rules in a new browser page.

If we could lay our hand on an old version of the Jocly engine, from the time when it did support external game definitions, and install that here in addition to the newer Jocly, we could link to that.

I have version 0.1.0 installed in /play/jocly/, and I have version 0.0.1 in /play/jocly-master/. I think I thought I was putting a newer version there, but apparently I wasn't. I have found 0.9.12 on github. There are also 23 forks of Jocly. So, maybe someone is still working on it even though its creators have abandoned it.

I made an attempt to hack Cavalier Chess into the Jocly library.

But of course there is no way to test it, as Cloudflare prevents us to see any changes I make. It just keeps delivering the old jocly/dist/jocly-allgames.js that does not have cavalier-chess in the list when Jocly requests it, so Jocly will deny the game exists.

I just purged https://www.chessvariants.com/jocly/dist/jocly-allgames.js from the cache at Cloudflare.

However, I don't see https://www.chessvariants.com/jocly/dist/jocly-allgames.js in the file system with WinSCP, and it gives me a 404 error in the web browser. Did you report its address correctly?

I have now purged https://www.chessvariants.com/dist/browser/jocly-allgames.js from the cache.

It looks like I successfully purged the right file from the cache, because Jocly is not working anymore. I have now put chessvariants.com in Development Mode, which will suspend use of the cache. This should allow you to test your changes.

Well, I have managed now to port your custom files for Cavalier Chess to the Jocly installation on my website ( http://hgm.nubati.net/jocly/jocly-master/examples/browser/control.html?game=cavalier-chess ), from which I think the installation here was cloned. I uploaded the same files to the CVP server, but I cannot see the changes even if I access the files directly through the browser and refresh the browser cache. I can see the changes with SCP, so I know they must be there. (Even on my own website it is a pain to make changes active; normal cache flushing on the Jocly page by Shift+Reload does not affect the browser caching of .js files that are not directly linked from the page, but which are accessed by JavaScript. So I have to surf to the changed .js files themselves, and then do a Shift+Reload on those, and then run Jocly again.)

Anyway, the relevant files are:

• /play/jocly/dist/browser/jocly-allgames.js
• /play/jocly/dist/browser/games/chessbase/cavalier-chess-config.js
• /play/jocly/dist/browser/games/chessbase/cavalier-chess-model.js
• /play/jocly/dist/browser/games/chessbase/cavalier-chess-view.js

The way it works is this: Each new game needs to be declared through a line in the jocly-allgames.js file, which provides enough information to generate the entry in the list of "other Jocly games" (so a thumbnail image, name, and short description), and allows Jocly to find the *-config.js file that defines what other 'resources' the game actually needs. I have the feeling that the config file might only be used during 'compilation' (i.e. creating in jocly/dist/ the 'library' of uglified .js files from the source code in jocly/src/), but I am not entirely sure. To run the game Jocly needs a *-model.js and a *-view.js file, but these files in the chessbase directory are not just uglified versions of the custom files supplied by the user, but an uglified concatenation of all files that the *-config.js (or the html page, in the old way of embedding) mentions as necessary for the model or the view. This uglified concatenation must have been created during compilation as  per specification in the *-config.js file; Jocly is then perfectly able to derive the filename of the *-model.js and *-view.js filenames from the game name, as it would create the filename of the *-config.js file from it.

Anyway, my procedure for hacking in new games is that I once identified the uglified part of the custom model and view source files in the uglified model and source for that game, and deleted that part. I can then replace it by the custom source files of other games. This only works if the new game uses the same standard files in addition to the custom code. (So I could not do hexagonal games, because the variant I used as a template has a rectangular board. One should start with uglified files that use the same standard files.)

The cavalier-chess-model.js and cavalier-chess-view.js are now excellent templates for other chess variants with 'regular' rules; almost all variants I had added this way have some rules that were not supported by the standard Jocly scripts (like piece drops in Shogi, extinction royalty in Spartan Chess, locust and multiple capture in Chu Shogi) so that I also needed to hack the chessbase.js part of the model files for those (or even redefine routines in the Jocly core). Even for Team-Mate Chess I had to redefine parts of the Jocly core for getting more natural move animation of bent sliders (turning a corner in the right place, rather than moving in a straight line through other pieces). So these make less suitible templates.

[Edit] The changes in the files eventually became effective; there must have been some caching going on along the way through the internet. Anyway, Cavalier Chess now works in the Jocly we have on CVP (if you start it through the 'other Jocly games' link). I also copied Chu Shogi and Tenjiku Shogi here. (I had implemented those on my own Jocly install after it was cloned here.)

I now also ported Embassy, Univers, Modern Carrera's, Grotesque and Grand Cavalier Chess to the CVP Jocly install. This puts all variants that were embedded by the old method in the category 'works in Jocly, but link in the overview page points to non-working page'.

I suppose these pages could be made working again, by replacing the script that is there now by an iframe invoking Jocly with the proper ?game=... argument (like the Courier Chess page already does). I wonder if this makes sense, though, as this would still only cover a small fraction of the chess variants that Jocly now supports. I understand that these 'relay pages' served the purpose of exhibiting the illustrated rule descriptions contained in Jocly, but not accessible through the control.html demo that we use to run Jocly.

But I think a better solution would be to modify the control.html to make that info accessible; on my own website I am already experimenting with a button for summoning the Jocly rule descriptions in a separate browser window. We could then abandon the /play/jocly page we have now, and replace it by an alphabetical list that links directly to control.html for all supported games.

Well, I have managed now to port your custom files for Cavalier Chess to the Jocly installation on my website, from which I think the installation here was cloned.

No, I installed Jocly here, and I didn't clone it from your website.

I now also ported Embassy, Univers, Modern Carrera's, Grotesque and Grand Cavalier Chess to the CVP Jocly install. This puts all variants that were embedded by the old method in the category 'works in Jocly, but link in the overview page points to non-working page'.

Very good. Is there any way we can get thumbnails for them to show up?

I suppose these pages could be made working again, by replacing the script that is there now by an iframe invoking Jocly with the proper ?game=... argument (like the Courier Chess page already does). I wonder if this makes sense, though, as this would still only cover a small fraction of the chess variants that Jocly now supports. I understand that these 'relay pages' served the purpose of exhibiting the illustrated rule descriptions contained in Jocly, but not accessible through the control.html demo that we use to run Jocly.

Like with Game Courier, we should have separate web pages for each game playable on it. This lets us index the pages, which lets us show them in search results, post comments to them, and include a menu item in the Play menu for games playable on Jocly. We could add more pages for the other Chess variants supported by Jocly so that they get the same benefits.

No, I installed Jocly here, and I didn't clone it from your website.

Then that is not the version that we actually use. Because the latter one contains lots of variants that are otherwise only available on my website (e.g. Tori Shogi).

Very good. Is there any way we can get thumbnails for them to show up?

Yes, copy those to the directory play/jocly/dist/browser/games/chessbase, with names like cavalier-thumb.png etc.

Like with Game Courier, we should have separate web pages for each game playable on it. This lets us index the pages, which lets us show them in search results, post comments to them, and include a menu item in the Play menu for games playable on Jocly. We could add more pages for the other Chess variants supported by Jocly so that they get the same benefits.

Well, it seems pointless to me, and needlessly clutter the alphabetical index. As a user I would prefer to find each variant only once there, to get to everything we have about it when I follow that link. The GC presets, Zillions file and Jocly applet could conveniently be accessed through links in the article that explains the rules. Having to go through extra intermediated pages is just annoyingly cumbersome, and needless duplication of information.

But as long as you make these extra pages, it is fine with me.

Then that is not the version that we actually use. Because the latter one contains lots of variants that are otherwise only available on my website (e.g. Tori Shogi).

The comments on this page indicate that I installed it in 2016, and then I later copied over files from your installation, using wget to get a tarball you had created.

As a user I would prefer to find each variant only once there, to get to everything we have about it when I follow that link.

You can filter a query to the Item table by "Type=Game" to get a list of just game rule pages. One of the advantages of including other type of pages in the Item table is that you can also search for just Game Courier presets or just games you can play on Jocly.

The GC presets, Zillions file and Jocly applet could conveniently be accessed through links in the article that explains the rules.

They are, and that's made possible by including them in the Item table.

Having to go through extra intermediated pages is just annoyingly cumbersome, and needless duplication of information.

We could have a Jocly table that associates games supported by Jocly with the name Jocly knows it by, then use that to add a Jocly link to appropriate pages. I'm supposing that including these links would be enough to allow search engines to pick up on them. However, using the Item table, as we do now, would make it easier for people to identify new games supported by Jocly. So, maybe we could just update the table to include URLs that directly call Jocly, such as /play/jocly/cavalier-chess, instead of .html pages, such as /play/jocly/cavalier.html.

We could have a Jocly table that associates games supported by Jocly with the name Jocly knows it by, ...

The Jocly names are not very difficult to guess, even though a bit strange at times. It turned out that Jocly was not able to recognize the *-model.js and *-view.js files in the chessbase directory if the name of the variant did not end in '-chess'. Normally that is automatically what you get when replacing all the spaces in the commonly used names by hyphens. E.g. team-mate-chess, wild-tamerlane-chess. When the name contains 'chess' as a suffix (like Gigachess), you still need the hyphen (giga-chess); the rules file and thumbnail then usually don't carry the hyphen (giga-chess-model.js, but gigachess-thumb.png).

When the common name doesn't contain the word 'chess', it is usually added (shako-chess, kaisergame-chess). When it is a Shogi variant (which were all implemented by me, as the standard Jocly chessbase module did not support piece drops), I either appended the -chess suffix (so regular shogi became shogi-chess), or replaced the word 'shogi' by 'chess' (chu-chess, tenjiku-chess). I did not do this entirely consistently, though (Tori Shogi is tori-shogi-chess). But it is not too late to change that. (Just a matter of renaming the files, and put the new name in jocly-allgames.js.)

I have been writing a short description of the features offered by the fairy-move-model.js module, and how these can be used:

Programming with sub-models

To enhance the support for chess variants with fairy pieces,
several sub-models were created.

fairy-moves-model.js

This sub-model, when included in the model build with base-model.js,
will provide various forms of support that chess variants featuring
unorthodox pieces would often need. This ranges from new routines
for generating move graphs of often encountered unorthodox pieces,
move-mode flags for some common forms of locust capture (i.e.
removal of pieces on other squares than the destination of the move),
and anti-trading rules.

Move graphs.

Several new routines for creating the graphs for fairy pieces are
available. These are (as they would be used in the game's model file
for defining the piece moves):

this.cbCamelGraph(geometry, confine);      // [1,3] leaper
this.cbZebraGraph(geometry, confine);      // [2,3] leaper
this.cbElephantGraph(geometry, confine);   // [1,1] and [2,2] leaper
this.cbWarMachineGraph(geometry, confine); // [2,0] and [1,0] leaper
this.cbAlibabaGraph(geometry, confine);    // [2,0] and [2,2] leaper
this.cbWizardGraph(geometry, confine);     // [1,1] and [1,3] leaper
this.cbChampionGraph(geometry, confine);   // [1,0],[1,1] and [2,0] leaper
this.cbVaoGraph(geometry, confine);        // diagonal XQ Cannon
this.cbCardinalGraph(geometry, confine);   // Knight-Bishop compound
this.cbMarshallGraph(geometry, confine);   // Knight-Rook compound
this.cbAmazonGraph(geometry, confine);     // Knight-Queen compound
this.cbGriffonGraph(geometry, confine);    // R after F bent slider
this.cbRhinoGraph(geometry, confine);      // B after W bent slider

More general routines for creating graphs are:

this.cbSkiGraph(geometry, stepSet, flag, bendAngle, iflag, range);

This creates a two-leg trajectory, where the second leg can continue
at an angle specified by bendAngle from the first. Here 0 means
straight on, 1 a (symmetric) 45-degree bent, etc. The first step
will use the iflag, the remaining trajectory the flag argument
for its mode.

this.cbAdvancerGraph(geometry, stepSet, range);

This creates a graph for a rider in the given directions with the
given range, which makes Advancer capture (stopping just before the
piece on its trajectory that it wants to capture). These moves
are implemented as e.p. captures, so the user won't have to click
the intended capture target, just the destination.

Locust and double captures

There now is some automated support for moves that have set the
(new) this.cbConstants.FLAG_FAIRY amongst their flags. Some flag
bits that otherwise would be freely available to the user will
then specify in which way moves that were pushed on the special-
moves stack will be automatically processed and transferred to
the array of pseudo-legal moves. The available flavors are:

this.cbConstants.FLAG_RIFLE;   // capture target without moving
this.cbConstants.FLAG_HITRUN;  // capture is followed by king move
this.cbConstants.FLAG_CHECKER; // capture by jumping over enemy 

The latter should be used only by moves that step to the second
square, and would only be allowed if that square is empty. But
by combining it with FLAG_SPECIAL_CAPTURE it can be made to
also work for a double capture.

All these flags have FLAG_FAIRY set in their bit pattern.
Without that, when using FLAG_SPECIAL, FLAG_SPECIAL_CAPTURE
or FLAG_CAPTURE_SELF the move would be put in the array
'special' of candidate moves if the specified target square
was empty, or occupied by a foe or friend, respectively.
(Combinations thereof are possible.) This feature is already
supported in base-model.js. One would then have to provide
his own post-processing routine to convert these candidate
moves to real moves, and push those to the 'moves' array.

The move that is used to leave the capture square on hit & run
capture can be controlled by assigning a graph to the variable
Model.Game.neighbors (i.e. this.neighbors in the game definition).
By default it would be the King graph.

Entering these moves requires the capture victim to be clicked,
after which the possible final destination(s) will get highlighted,
and have to be clicked to complete the move. This way for entering
moves requires that multi-leg-view.js is included in the view build.

If the user wants to use custom code for processing special
moves in combination with the fairy-move-model.js file, he can
provide a routine this.customGen(moves, move, board, aGame)
to convert the given move from the special moves stack into
a real one, and push that to the moves array (or disgard it).
The final two arguments are the game state (a Board object) and the
Game object, which can be consulted to perform the transformation.

Like always, the candidate will contain a field x (apart from the
normal f, t, c and a fields for squares of origin and destination,
index of the piece at the destination in the pieces array (or null),
and abbreviated piece name, respectively), which contains the XOR
of the destination square and the previously visited square on the
path in the low 16 bits, and the mode flags in the high-order bits.

Flying capture

The base model already supports 'flying capture', i.e. the power
to jump over arbitrary many pieces for capturing, as a special
case of screen capture. Just for a reminder we describe it here.

Flying capture is indicated by FLAG_SCREEN_CAPTURE, just like
normal screen capture. What makes the difference is a non-zero
value in the optional 'ranking' field of the piece definition:

ranking: N,

In that case the move along a ray is not terminated with the
screen capture, but can also fly over it for capturing further
down the ray.

Whether a piece can be used as a screen at all is determined
by the ranking of the latter. This must be lower than that
of the piece making the capture, or equal if they are an even
number. This allows implementation both of the case where
equal pieces would block each other, and where they don't.

Note that normal screen capture (which has N=0) can use all
piece types as a screen, irrespective of the ranking of the
latter.

Anti-trade rules

There also is support for some anti-trade rules. Pieces can be
assigned to an 'anti-trade group' N with the aid of a field

antiTrade: N,

amongst the piece properties. Pieces in the same odd-numbered
group will then not be able to capture each other, if recapture
on the same square would be possible. (I.e., if the captured
piece was protected.) If |N| > 100 (and odd) it is even forbidden
to capture unprotected pieces of the same trade group.

Pieces with an even antiTrade value can always be traded for each
other, but cannot capture a protected piece with the next odd
anti-trade group.

If N < 0 'counter-strike' against the piece is also banned:
in the move directly following the capture of a piece from
such a group, pieces from the same group cannot be captured
by pieces outside the group.

The anti-trading provisions only get switched on by assigning
a non-zero value M to

Model.Game.minimumBridge=M;

The actual value you use for this will be significant when
anti-trading restrictions apply to a piece capable of double-
capture: all pieces of a type >= M captured as 'side catch'
to the trade will cause the ban on trading to be lifted.
(Note that the ban only appied for capturing on the destination
square to begin with.) To lift the ban for any side catch,
you can take M = -1.

I have tested the model with bigorra on your branch.

It worked fined : https://biscandine.fr/variantes/test/fairy-move-model/hgm-src.zip

You can retrieve pieces or model if you like.