Comments/Ratings for a Single Item

The Jocly website isn't accessible for several days (I don't know exactly how much time), nor embeded games on other websites; and the Jocly Android apps seem to have disappear from Google store. It would be a pity if Jocly wasn't working anymore; it had a graphically beautiful interface. It was a great work from its developers.

Agreed, Jocly is a brilliant piece of software. Too bad I only discovered it two weeks ago, and that the server went off the air a few days later.

The news is about as bad as it can be: the server will be off line at least until mid 2019. Before it went off the air it was continuously crashing, and too messed up for easy repairs. Mi-g currently has no time to fix it. The 'easy-embedding' method through jquery unfortunately was dependent on the server for fetching the required library scripts, so any website that was using this method shares the fate of the jocly.com server.

I have installed the entire Jocly library on my own server, and ported the demo applets for the variants I had made to use that, rather than the now defunct jocly.com. (Mind you, this is not a replacement for the game server, which was not open source, so there is no connectivity with other users; only the Jocly interface works.) So if you want to play against the Jocly AI, you can do it at http://hgm.nubati.net/jocly .

I implemented some new chess variants there, and the mentioned page allows direct access to those. All standard Jocly variants (i.e. those you get with the sources from Github) still work too, though, and you can switch to them from one of the directly accessible demos. The new variants are:

• Spartan Chess
• Scirocco
• Elven Chess
• Werewolf Chess
• mini-Shogi
• regular Shogi
• Tori Shogi

More will likely follow soon (CwDA?, Chu Shogi?).

I now set up a minimalistic (turn-based) server for on-line game play using the Jocly interface. It supports the functions of registering as a user, logging a game request, subscribing to a game request (so it becomes a game), fetching a game, adding a move to an existing game and resigning a game. Offering draws and keeping track of time usage will soon be added. I am sure much more could be improved as well. It supports all games supported by Jocly, including the chess variants I programmed myself. The client page is at:

Comments and suggestions are welcome!

H.G.: When I click on the link you gave, the page is blank for me, at the moment.

Strange. For me it looks like this:

I am using FireFox. But I now also tried some others: it also works in Chrome, but in Internet Explorer I only get a blank page. Are you using IE?

Does the standard Jocly demo (at http://hgm.nubati.net/jocly/jocly-master/examples/browser/control.html ) work for you?

Your latest link doesn't work for me either, unfortunately. I am using Internet Explorer, though. I used Firefox for a while, but my laptop had troubles with it, I vaguely recall (it was long ago).

In any case, I'd be curious to know if blitz time controls would work on your server, as they do with standard chess servers.

It seems that IE is not able to run Jocly, then. I just finished adding code to it to keep track of the players' time usage, but currently the clocks are always initialized to 10 days per player. Pretty far from blitz, I suppose... It was really designed as a turn-based server for correspondence chess (variants).

Of course everything would still work if you initialize the user clocks to a very short time, but the way the interface works would be pretty cumbersome: When your opponent moves you would not automatically get to see it. In stead you would have to keep loading the game by clicking it in the game overview until you see that it is your move again. The idea was that you would typically not sit at the keyboard anyway when your opponent moved, and that the computer might even be switched off. And after you made the move on the display, you would still have to press a 'submit' button before it gets sent, to give you the opportunity to verify it for mouse slips and the like. All that of course takes very significant time compared to a blitz game, slowing you down by perhaps a factor 5.

Of course this can all be fixed; I could of course add an option that would sent the played move automatically, which the user could tick when he considers speed of more importance than reliability. And I could have the web applet keep downloading the selected game automatically for as long as the opponent is still on move, every second or every 10 sec. (The frequency depending on how much time is still left on the clock; if it is days, checking every 10 minutes would probably be fast enough.)

The Jocly Apps are actually still available on the Apple App Store (but not on the Google Play Store). Of course connection to the server isn't possible anymore, but the IA works.

They actually managed to get the site back up. I though Jocly was permanently down.

Yes, strange. Not all the games are present, for example Gigachess and Terachess are missing. Jocly is reactivated times by times on other sites. I believe it is because it is mainly open source and some people are able to re-put it on line. I was told by the creator, who I met, that he had gave up because he was finally fed up and demotivated by many many consecutive attacks from hackers. Bad and sad. (His next project was to have Jocly coupled with virtual reality and I had the chance to have a demo. It was impressive to get really projected on the board and be able to fly above the board or move the pieces around yourself. So bad this has been stopped).

Well, 'permanently' is a relative notion. At the time when the crash happened the developer was too busy with more important things, for the foreseeable future. But perhaps that has changed now.

The Jocly interface itself is public, but the server software of the jocly.com website was private. So it was easy for many other websites to embed the Jocly interface, but that did not make them a site for on-line play. I also set up Jocly on my own website, and even implemented some new games for it. (Mostly variants with drops, like Shogi, or other variants that posed some challenge that was not supported by the standard code for chess variants, such as multiple royalty for Spartan Chess, multiple Capture for the Chu Shogi Lion, etc.) I even connected Jocly to my own turn-based server, so people could use it to play on-line, and some people actually did.

I also set up Jocly on my own website, and even implemented some new games for it.

Could we add local copies of these to the collection of Jocly games on this website?

I suppose this should be possible, by replacing the file tree that contains the Jocly 'library' by the corresponding file tree from my website (which supports the new games), and making a separate html page for each game, which embeds Jocly with parameters that request that game. I don't know if the version of Jocly installed here now is the standard version from GitHub, (from which I started), or that there are some additions (like extra games) we don't want to lose. In the latter case things would be a bit more complex, as we would somehow have to merge the additions.

I suppose this should be possible, by replacing the file tree that contains the Jocly 'library' by the corresponding file tree from my website (which supports the new games), and making a separate html page for each game, which embeds Jocly with parameters that request that game.

Would you provide me with the files for doing this?

I don't know if the version of Jocly installed here now is the standard version from GitHub, (from which I started),

I installed Jocly in 2016, and the version on Github is older than that. So, I'm presuming it's the same. I can find out whether it works after trying to install one of the games you programmed.

or that there are some additions (like extra games) we don't want to lose.

We just have the games I added to this site in 2016.

The entire tree for the Jocly files on my website is already present as a tar ball there: http://hgm.nubati.net/jocly/jocly.tar.gz . It should be enough to download and unpack that.

The entire tree for the Jocly files on my website is already present as a tar ball there: http://hgm.nubati.net/jocly/jocly.tar.gz . It should be enough to download and unpack that.

I copied that over with wget, but it did not contain the games you programmed, which is what I was asking you for.

Oh, sorry, I apparently have two such files there, in different directories. I suppose the one you got is the one I used for installing. The other one is at http://hgm.nubati.net/jocly/jocly-master/jocly.tar.gz . This is of later date, also later as the game files I added to the tree.

I installed your tar file to /play/jocly/temp/, and I can see that it has files for Shogi, Smess and other games. Assuming this would work as is, what URL should I go to in order to see a game in action? I see that on your site you use a page called control.html, but that page was not included in your tar file.

This control.html was a demo file that came with the Jocly source distribution, and it is included in the tree you installed ( /play/jocly/temp/examples/browser/control.html ). It seems operational there. I might have made a copy of it in another directory on my own website. By appending an argument ?game=... it is possible to change the initially-selected game. (But there is a link on the page that can be used to switch to any other game.) I suppose you can see the required game names for the games I implemented on my Jocly starting page.

It seems the other games you have on CVP use another method for embedding Jocly than just linking to control.html with a game-selecting argument; they have their own html page, invoking Jocly through some embedded script, but having a CVP header and some other info, plus some ads added. I am not familiar with this method of embedding. It might be an older one; I remember having seen an obsolete Jocly tutorial, which discussed a very simple method of embedding that was dependent on the jocly.com server. This could be that method, except that it seems to link to a local version of the Jocly library ( /play/jocly/jquery.jocly.min.js ) which the described method would fetch from jocly.com.

I suppose you could also create game-specific pages derived from control.html, by adding the CVP- and game-specific elements to it, deleting the game-switch link from it, and then linking to it with the argument that selects the game it describes. My turn-based server page http://hgm.nubati.net/jocly/jocly-master/remote.html is a similarly adapted version of control.html.

The Jocly version as it now builds from the GitHub sources seems much less monolithic than the jquery.jocly.min.js file; the latter seems to contain everything, while the version I build keeps the Jocly library distributed over a huge tree, and loads the required components on demand. E.g. there all games are in separate files jocly/dist/browser/games, which again has a subdirectory 'chessbase' that contains all chess variants. Where each variant then has 3 .js files (config, model and view), two .html files (description and rules) and a .png thumbnail image, and the config.js then indicates what other components are needed for more basic support (e.g. what type of board view, the general chess model). All the graphics for chess pieces is in a subfolder chessbase/res.

Although I was tempted to start with Shogi, I decided I had better start with something that doesn't require additional graphics. So, I started with Janus Chess. I copied over files for Janus Chess, changed named from janus-chess to januschess-custom, and adapted a page I had for Capablanca's Chess. The page I created starts up Jocly, but it doesn't display Janus Chess. So, I decided to compare the model and view files I have for Capablanca's Chess with the model and view for Janus Chess. Those for Janus Chess each contain the whole script in a single line, making them difficult to read. Besides that, they are so incredibly different and obfuscated that I cannot make heads or tails of them. It's more like something a compiler would output than a human would write. Since that particular game comes with Jocly, I checked out some that you had written yourself, such as Werewolf Chess and Shogi. These begin with a long block of unformatted text, and then include additional formatted text. These long blocks of text make it very difficult to learn how to program new games for Jocly by studying the code for other games. I think this is holding back the development of games for Jocly. In contrast, Zillions-of-Games and Game Courier both use code that's easier for the programmer to follow and adapt.

Those for Janus Chess each contain the whole script in a single line, making them difficult to read. Besides that, they are so incredibly different and obfuscated that I cannot make heads or tails of them. It's more like something a compiler would output than a human would write.

And that is exactly what it is. What you are looking at is the so-called 'uglified' library file, generated in the compilation process that created the library. This is common practice in JavaScript, to minimize the size, and thus the bandwidth use of the server that hosts it. The tar ball only contained that library. The source code is also on my website, at http://hgm.nubati.net/jocly/jocly-master/src/ .

Beware, though: that is the original source code I downloaded from GitHub. It doesn't contain any of the games I implemented. Initially I had so much trouble compiling the thing (I actually never managed that on Windows, and finally had to create a new Virtual Machine running a recent Ubuntu version to get it done), that I just started hacking the new games into the library. Unfortunately the compilation process fuses the general Chess code ('base-model.js') with the variant-specific model file in the compilation process. So what I did is take a file for normal Chess, and replaced the uglified code of the chess model by normal source code for the variant I wanted to implement instead. But leaving the uglified base-model.js that was also in the file just as it was.

In the end I mastered the compilation of Jocly on Linux, and back-ported most of the hacks I had done to decent source code. (But not all yet.) That source code can now be found in my on-line git repository (jocly.git section, 'hgm' branch). If you go to the 'tree' of the latest snapshot ('Fix castling and stalemate in Wildebeest Chess') in that branch, to directory /src/games/chessbase/, you will find the werewolf-model.js and werewolf-view.js files (and spartan, and shogi, and elven, ...) there as decent source code. Since some of these games require originally unsupported chess concepts (such as multiple royalty, double capture) those will only work together with files 'deeper' in Jocly (e.g. base-model and -view for general chess-variant support) that I also modified. You would have to use my versions for these as well, and I am not sure whether the method you were using for embedding Jocly would allow that. (It probably takes those from the jquery.jocly.min.js file, and you would have to somehow overrule that.)

I think it would be a far easier path to adapt the control.html that comes with the new Jocly distro; it is a quite simple page, as all the script to actually make Jocly appear and run it is in an external JavaScript file. It should be very easy to convert the look of that file to what you have for the games already on CVP. Just add the ads at the bottom of the column on the right, and put a description of the game at the bottom, and CVP headers and footers above and below it. The only thing that is dependent on the variant is the rule description. But all these Jocly games already come with rule-description files, and you could just copy-paste those there. Or, if you want to be really smart, put some JavaScript code there that would display the rule description for the variant that the argument in the URL requests in a frame. Then you can use exactly the same page for all variants.

I'm working on a php version of control.html a couple of directories lower at /play/jocly/control.php. I added an extra parameter to the query string to tell which directory a game is in. The following URL works:

https://www.chessvariants.com/play/jocly/control.php?game=xiangqi&dir=chessbase

Curiously, though, when I reverse the order of the two parameters, it gives me Chess instead of Xiangqi:

https://www.chessvariants.com/play/jocly/control.php?dir=chessbase&game=xiangqi

Bearing this in mind, I created a rewrite rule in .htaccess that lets me use the dir value as a directory name before the game of the name. Given that the following URL show the description and rules for the correct game, I can tell that it is being rewritten correctly, but when I use it, Jocly does not work:

https://www.chessvariants.com/play/jocly/chessbase/xiangqi

I added some code to pass the PHP variable's value to a JavaScript variable called game, but it didn't help. I also tried GAME, but that didn't help either. Any ideas about what I can do?

I solved the problem I described by including the original control.html in an iframe with the correct query string. However, this has introduced a new problem. The text underneath the iframe will not show up anymore.

I have no experience with iframes. But can it be a problem that an iframe must have a closing tag </iframe>? Once I forgot to put a </script> tag after an external JavaScript source, and that also made all following text disappear...

That was the problem. I forgot the closing tag to the iframe. Thanks.

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.

I have tested the model with bigorra on your branch. It worked fined :

Great! I will have a look at it shortly.

I managed to tweek the castling code in base-model.js and base-view.js such that it becomes possible to specify alternative final king and rook positions (compared to the one tabulated in the game definition for that king and rook) through the hitherto ignored t field of a castling move. In this case move entry must be done by clicking the destination of the king rather than clicking the rook to be castled with. (The latter is only used for the tabulated castling, so in case of ambiguity with a normal king move you should tabulate the castling with that destination.)

I added some code in the makromachy-model.js to generate 'fast castling', and this appears to work as intended. The only rule that has not been implemented yet is the ban on perpetual checking with an Eagle. But I already built in a mechanism to adjudicate perpetuals, for the benefit of Xiangqi, so this should not be difficult.

BTW, what I forgot to mention in the fairy-move-model description is that this also contains a new routine

this.cbInitialPawnGraph(geometry,direction,initialPush)

where you can specify how far forward the Pawn can slide.

I more or less finished implementing Makromachy. (Some imperfections in the graphics remain: the two 3d Cannons use the same 2d image, and I still want to distort some of the 3D pieces.) Only three moves were not implementable through the graphs and flags offered by fairy-move-model.js: the Fast Castling (K jumps to any empty base-rank square, and R to the K-square), the Airlift Moves (slide up to the first piece on the ray) of Knight, Elephant and Champion, and the Warrior backward captures (because they should not have e.p. capability, while the forward captures should). These required defining the moves as 'candidate moves' only, and implementation of a customGen routine to 'mature' these candidates to push them to the moves list.

To this end the Warrior backward captures are defined with FLAG_SPECIAL_CAPTURE. Because the Warrior has the epCatch property, these candidate moves are also generated when they go to the (empty) e.p. square. The customGen code for Warrior moves then tests whether the capture victim of the proposed move is indeed at the destination square, and discards the move when it isn't.

The Fast Castling is handled by defining a duplicat type for the corner piece, which as extra moves from the corner square have a direct jump to the King's starting square, with FLAG_CAPTURE_SELF modality. As soon as they move they 'promote' to a type that doesn't have these moves in its graph. (The standard way in which Jocly handles initial-only moves, such as the Pawn double-push.) When these candidate moves are delivered to customGen it has to be checked whether the piece they 'capture' has moved. (If not, it must be the King, and the corner pieces themselves cannot have moved either, because then they would have lost the move.) And whether the side to move is in check, which would also be a show stopper. If both tests are passed, the base-rank is scanned for empty squares, and for each of those a castling would be pushed, describing King origin and destination, and 'rook' origin. (As Jocly encodes castlings. The 'rook' destination is taken from the castling table in the game definition, and thus must be the King square here.)

The Airlift Moves were most troublesome, in particular the fact that a minimum distance is required. The makromachy-model.js file contains its own routine for generating the graph, which is similar to cbLongRangeGraph, but generates the first two destinations on the ray with FLAG_STOP, and those further away with FLAG_SPECIAL_CAPTURE|FLAG_CAPTURE_SELF modality. This then produces candidate moves that end on the first piece they meet (whether foe or friend). The customGen then modified the destination to the previous square on the ray (which is always encoded in candidate moves).

The customGen routine distinguishes these cases by the abbreviation of the moving piece (which is always included in (candidate) moves).

The ban on capturing protected Terrors with Terror or Eagle is implemented by giving these pieces an antiTrade property (2 for the Eagle, 3 for the Terror, so that the Eagle itself is not protected). minimumBridge is set to -1 to activate this. (As there is no double capture in Makromachy itsactual  value has no effect, as long as it is non-zero.) cbPawnTypes is set to 6, to make Pawns (initial and other) and Warriors (of both colors) reset the 50-move counter.

The ban on repeating a position through an Eagle check is implemented by setting cbMaxRepeats to 2. This already triggers the repetition logic on the first repetition. The makromachy-model.js contains a routine cbPerpEval that is then called. This tests whether we are in check, and if so whether the preceding move was an Eagle move, and adjudicates a win in that case. In other cases it test the repetition count; if it is 3 it adjudicates a draw, if it is 2 it refrains from adjudicating by returning undefined.

The only rule left unsupported, of which I am not sure how I can implement it, is that Eagle checks and the following evasion should not increment the 50-move counter. This counter has always been a weak spot of Jocly; the current master branch doesn't even reset it on Pawn moves. I made it slightly controllable through the introduction of cbPawnTypes, but it would be better if I fudge in some way for the game's model to manipulate the counter in a more intelligent way. Perhaps by providing a routine for it, so that you could adapt it in an arbitrary way.

The result can be tried at: http://hgm.nubati.net/jocly/jocly-master/examples/browser/control.html?game=makromachy

[Edit] Oh, and I had to assign a King graph with FLAG_MOVE modality to Model.Game.neighbors, for correct implementation of the Terror's hit & run capture: this does not allow double capture or rifle capture, as would have been the default for moves that use the FLAG_HITRUN modality.

Megalomachy next?

Megalomachy next?

From a programming POV that would just be more of the same. So no!

I will probably try Minjiku Shogi first. This has burning and brouhaha squares as a novelty. Active burning should already be supported by the fairy-move-model.js file; I tested that in a modified version of Chu Shogi. There is still one problem with that, though: the function cbGetAttackers would not consider a square that can be burned as attacked. That means the King would be able to expose itself to burning. This is hard to fix, but not an issue for games that do not have a checking rule. (And not really an issue for careful players anyway.) As long as losing your King would be noticed as a loss. (Which currently isn't the case in Jocly; it only tests for checkmate/stalemate.)

I should also make some progress on piece graphics. One of the problems of starting to modify other people's software before you are fully acquainted with it is that you might do things in a way that goes against the design philosophy of doing similar things. I have for instance added slightly resized 3d pieces to the fairy set, because I was not happy with the initial design. But I am starting to discover that this could have been done not by changing the size of the piece file itself, but with instructions in the game's model file. That would be much cleaner and much more versatile.

My first contributions to jocly have been accepted on github. I'm now thinking of trying to reorganize the code base along the lines of Chessvariant to bring the sources as close together as possible. How do you think this could be done? Do you plan to upload fairy-move-model.js or other modifications to github? Do I start moving variants into directories? Is it worth waiting a little longer to finalize the changes on CVP before transferring them to github? let me know your preferences.

OK, I see your games were added to the master branch at github.com/mi-g/jocly. First question: how did you manage that? If I knew that, perhaps I can manage it too.

Since the mi-g/jocly repository was my original source, my git directly communicates with it. If I do "git remote -v" I see:

hgmuller@hgmuller-VirtualBox:~/jocly/src/games/chessbase$ git remote -v
nubati    ssh://[email protected]/~/hgm.nubati.net/git/jocly.git (fetch)
nubati    ssh://[email protected]/~/hgm.nubati.net/git/jocly.git (push)
origin    https://github.com/mi-g/jocly.git (fetch)
origin    https://github.com/mi-g/jocly.git (push)

The fetching from 'origin' works; I just switched my local git to the master branch, and did a "git pull origin". This first drew a complaint that I had to remove a file "package-lock.json", which turned out to be owned by 'root'. I figured that this was a kind of safety measure to ensure my master branch would remain in sync with some Debian package, so I dared to get rid of it by renaming. After that the "git pull origin" did work, so all your commits now also appear in my local master branch. And I subsequently pushed that to my own git repository at hgm.nubati.net.

Now I am not really a git wizard, but I think the proper procedure would be to first "rebase" my hgm branch locally onto the new HEAD of master. If all the changes in the commits since the fork were independent (i.e. separated by more than 2 unchanged lines) this will not involve any changes in the data at all, it just changes the way git orders the commits.

Even if that would be the case it is no guarantee that the changes were compatible on the JavaScript level; one of us might have changed routines that the other was calling from a different file. And when we both have been editing the same file (like adding new games to the end of index.js) git will complain about dependencies during the rebase, and I would have to specify the desired outcome by hand.

But since we have been working on different games, and I tried to avoid changing the more basic Jocly files as much as possible, and then mostly in a backward compatible way, I don't expect many problems here. Main issue is the zobrist hashing for repetition detection; there are more files that directly accessed the Jocly API for this than I imagined, and to not break those I would have to adapt them when I commit my patch of the base-model.js for this. In my local git I did not make a systematic effort for this, and just fixed some games that I accidentally noticed were broken (such as Metamachy).

Anyway, after I rebased my hgm branch locally, and made sure everything still works, I can push it to the nubati on-line repository. Currently I have no idea how it could go to github from there; "push origin" does not work, as I have no account on GitHub, and even if I did it would probably only allow me to push to my own files there, not to mi-g/jocly.

Yes you could send your contributions to github too. I don‘t think you can push straight away to mi-g/jocly but you can send him a pull request from your own fork on github.

1/create a fork on https://github.com/mi-g/jocly fork / create a new fork

2/Select your fork create a branch : add whatever you like on it

when you are ready : click contribute : create a pull request

Michel will receive it and might take time to deal with it.

Note that he has upgraded the build file (gulp 4) and the dependencies (node 18). You will have probably to empty : node_modules directory and launch again npm install.

You might add your github fork in your remote repos list :

origin https://github.com/yourgithubuser/jocly.git (fetch)

origin https://github.com/yourgithubuser/jocly.git (push)

This could be worth a try. I have added your github repository as a remote source to my local git ("git remote add github http://www.github.com/fhoudebert/jocly.git"):

hgmuller@hgmuller-VirtualBox:~/jocly/src/games/chessbase$ git remote -v
github    https://www.github.com/fhoudebert/jocly.git (fetch)
github    https://www.github.com/fhoudebert/jocly.git (push)
nubati    ssh://[email protected]/~/hgm.nubati.net/git/jocly.git (fetch)
nubati    ssh://[email protected]/~/hgm.nubati.net/git/jocly.git (push)
origin    https://github.com/mi-g/jocly.git (fetch)
origin    https://github.com/mi-g/jocly.git (push)

I tried to pull one of your branches ("git pull github elephantine"), and this seemed to work in principle. But I get a lot of complaints that it cannot automatically merge some of my files with yours. I suppose this is because I try to import them in the wrong branch. If I try it after checking out 'master' it just said I am up to date.

hgmuller@hgmuller-VirtualBox:~/jocly/src/games/chessbase$ git pull github elephantine
warning: redirecting to https://github.com/fhoudebert/jocly.git/
From https://www.github.com/fhoudebert/jocly
 * branch            elephantine -> FETCH_HEAD
warning: Cannot merge binary files: src/games/chessbase/res/fairy/wikipedia-fairy-sprites.png (HEAD vs. f13d4b0bfbeb74d7517ed517817fef3d3beddb92)
warning: Cannot merge binary files: src/games/chessbase/res/fairy/icons/w-crowned-bishop.png (HEAD vs. f13d4b0bfbeb74d7517ed517817fef3d3beddb92)
Auto-merging src/games/chessbase/res/fairy/wikipedia-fairy-sprites.png
CONFLICT (content): Merge conflict in src/games/chessbase/res/fairy/wikipedia-fairy-sprites.png
Auto-merging src/games/chessbase/res/fairy/icons/w-crowned-bishop.png
CONFLICT (add/add): Merge conflict in src/games/chessbase/res/fairy/icons/w-crowned-bishop.png
Auto-merging src/games/chessbase/index.js
CONFLICT (content): Merge conflict in src/games/chessbase/index.js
Auto-merging src/games/chessbase/fairy-set-view.js
CONFLICT (content): Merge conflict in src/games/chessbase/fairy-set-view.js
Automatic merge failed; fix conflicts and then commit the result.

But anyway, pulling seems to work. So I suppose that if I had write permission to your github repository, I could push my branches there too.

The more conventional solution to do this is that you would pull from my repository. Then you would not have to give write access to anyone, and reading is public.

The main problem is to make the branches compatible, in particular rebase my branch on the current HEAD of master, now that master has grown compared to the point where I forked off. The merge problems it flags are those that were more or less expected: we both modified the fairy sprites, we both added a (different) Crowned Bishop, and we added different variants to index.js and pieces to fairy-set-view.js. This should be reasonably easy to solve; the more tricky thing is whether there would be incompatibilites in the code. The update to gulp 4 might be a problem, as my Ubuntu is so old that it has no longer access to repositories.

Minjiku Shogi now also seems to work. It makes use (and is the first real test) of the support for burning in fairy-move-model.js, and for brouhaha squares in the base-model.js. It uses the cbSkiGraph function in fairy-move-model.js for the ski slide of the Ninja. It was also the first test for having a hierarchy of flying pieces, like in Tenjiku Shogi. (In Makromachy they all blocked each other.)

BTW, I improved that function a bit, so that it can now also be used for pieces like Osprey (B after D). It accepts a bend angle (in units of 45 degree), and separate modality flags for the corner square and the remainder of the path. This allowed  specifying the corner square as FLAG_STOP for a lame ski-slider (such as the Tamerlane picket) or as -1 for skipping it (true ski slider, or Grant Acedrex Unicorno if you specify a bend angle). Or give it the same modality as the remainder (e.g. for a Griffon). What is new is that it now also would accept -2, -3, ..., which puts the corner 2, 3, ... steps away from the origin, and gives it the same modality as the remaining path. So orthogonal starting steps, a bend angle 1 and corner flags -2 now produces an Osprey graph.

The only thing I had to program in the minjiku-shogi-model.js itself was the area move. (Which in minjiku Shogi fortunately consists of only 2 King steps, rather than the 3 of Tenjiku Shogi.) I provided a customGen routine for that, which is triggered by giving the pieces equiped with an area move a null-step self capture as special move (a graph with step [0,0] and modality FLAG_CAPTURE_SELF). This reveals their location to customGen, and from there I follow a Knight graph, checking if one of the two squares over which the destination could be reached (these will automatically be on board!) is empty as a necessary condition for accepting the move.

I uploaded the result to my website: http://hgm.nubati.net/jocly/jocly-master/examples/browser/control.html?game=minjiku-shogi.

I have added a branch cvp with your fairy model + elven + shogis from your git to start the fusion.

I have just added extras western sprites for me, I can’t cope with kanjis but you can remove them if you don‘t need them.

I can add you as admin if you have a github account to give or I can send an admin token so you can do whatever you like on this branch. let me know how I can give you that token securely enough.

Here is a link to the necesseray node modules for gulp 4 (ubuntu)

http://biscandine.fr/variantes/test/fairy-move-model/node_modules-linuxx64-gulp4.zip

OK, I'll let you know when the time comes. First let us make sure there is something worthwile to push.

I have tried to rebase my hgm branch onto the new top of master. I hope I did not mess up the index file; normally merging is not such a problem, but because all the game definitions there were cloned from each other, and look still much the same, the automatic proposal tries to eliminate all text they have in common. I hope I did manage to avoid any deletions.

I did push the result to a new branch in my repository, called 'trial'.

Problem is that due the upgrade to gulp 4 I cannot build it anymore. Could you test (perhaps from the latest snapshot) whether it builds for you?

Yes it builds well. It needs a second 3d crowned rook for elven chess however. I had the same on the branch cvp and i have 2 diffusemaps now.

OK, I discovered that I can build when I revert the commit "update to gulp 4" in my local branch. I especially looked at the pieces, as this is where we had most merge conflicts. (And unresolvable merge conflicts, as these were binary files.) I checked Gigachess II, and it looked OK both in 3D and 2D. It uses the new Crowned Bishop in both cases. So I suppose your games are all OK. I think it just kept the fairy-sprites file from the master branch when it could not merge, but you had already adapted that to both of our needs before you merged with master.

Like you noticed, the old 3D Crowned Rook seems to have disappeared. The old 2D sprite still displays, however. (But for mysterious reasons Chu Shogi displays a Small Rook for that!?) The mesh file for my Crowned Bishop was called tiara.js, and it seems to have survived. I will rename it to fr-saint, and modify my variants to use it. (They now all use the new Crowned Bishop.) Most of my variants used a scaled version of the old Crowned Rook, which I had called fr-proper-crowned-rook, so I think there is no problem to make the two versions coexist. It is just that the mesh file for this proper-crowned-rook seems to have disappeared during the merge, so it cannot display. But it should be easy to get it back.

We probably should confer to decide which pieces we want to keep, and under what name. As far of 2D images I am sorely missing an image for the diagonal Cannon (fr-cannon2). In 3D these Cannons look very different, and there are games where I use both of them. But they use the same fairy-sprite. Now that you added so many new pieces, I will probably modify some of my games to use these. (E.g. the Wolf is of course ideal for Werewolf Chess.)

What I would also like to have is winged versions of the Q, R and B. I will see if I can fabricate something. (But it is not easy to create new 3D pieces with gedit as only tool...)

I will restore the 2 crowned bishop. I found how to clone your repo : I will fetch from origin http://hgm.nubati.net/git/jocly.git

and push on origin https://www.github.com/fhoudebert/jocly.git (branch trial).

Note that all the hmtl and images in directory (like chessbase/capa10x8, chessbase/decimal... ) have to be moved to chessbase/res/rules

I pushed some modifications on github / branch : trial.

The Crowned Rook should be back.

Chu Shogi doesn‘t display a Small Rook anymore. ... Can you easily retrieve them? If so, I could move the html and images and modify the index.js accordingly

Let me know, if it is usefull or not.

Well, I already have changed that too. (And pushed it.) All my variants now look as before, and I even use the Wolf in Werewolf Chess. (And the new Crowned Rook/Bishop for the promoted versions in Minjiku Shogi.)

I will have to think how I can make use of the new 3D pieces for improving the piece assignment in Minjiku Shogi and Makromachy, which sometimes was awkward for lack of choice. But perhaps I should defer that until after I managed (or failed) to add wings to some of the pieces. I really would love to have such winged pieces for representing the flying pieces in Minjiku Shogi (Jumping General, Orthogonal Jumper and Diagonal Jumper) and Makromachy (Eagle, Raven and Bat).

This site could really use a tutorial page for building for Jocly.

I suppose you meant 2D pieces. Indeed Board Painter has a nice diagonal cannon, and th Wikipedia non-royal King should replace my improvization. The Greek helmet also looks a useful addition, e.g. for the Omega Champion.

It is always a dilemma whether pieces should look to be reminiscent of their name or of their move. I usualy prefer the move. So Elven Chess uses a Lion for the piece called Wizard, because that moves like the Chu-Shogi Lion. The renaming was just to fit the theme. (And I had nothing that looked like an Elf or Goblin either...) Likewise, I would prefer the flying sliders to be similar to their normal counterparts, even when they are called Eagle or Raven. Since these are both birds they would look too much alike. (And I have no Bat anyway, and it seems difficult to make one.) A poor-man's solution would be to use larger or taller versions of Q, B and N, by transforming the vertex coordinates in normal ones with the aid of a program. (This is how I made the Nightrider.) But it should not be impossible for me to add wings to existing pieces, like I added spears to the Pawn to make Hoplits.

I never got to learn Blender, because at the time I got involved in Jocly the required export was no longer supported. So it seemed futile. I did study how the pieces are encoded, though. For simple, mostly cylindical chess pieces it would not be impossible to generate the mesh file with the aid of a simple program, which takes a list of  diameters and heights as input. I suppose I could even make windows bitmaps for the normalmap and diffusemap, and MS Paint should be able to convert that to jpeg. The main difficulty would be to calculate the darkness from the surface orientation. I created the shogi tiles from scratch, but these had only flat surfaces, so I could take a homogeneous normalmap and some wood image on which I wrote kanji for the diffusemap.

A Sword, Spear/Lance or Axe should also be relatively easy to make.

BTW, .js means JavaScript, not JSON.The piece mesh files are in fact just JavaScript objects.

Well, the documentation should be in the project jocly : https://github.com/mi-g/jocly

If the install/ building section is not enough clear enough to start I can answer some questions by mail if I can and we could extend the doc afterwards

I mean 3D pieces : on https://musketeerchess.net/p/tools/boardpainterV2/

click Open 3D board on the top right link Wait until it loads

Type tiger in the filter section drag the first icon on the board

You were right to use the lion in Elven Chess. Because it is very confusing when you are used to a piece to change its visual.

JoclyBoard will soon be repaired and easy to install for windows, linux and mac. In joclyboard the rules are well integrated with the game, it will brings more newcomers to chess variants. I have learned this way recently.

That’s why if we don‘t find a blender expert in chess variant, we might consider launching a small crowndfunding campaign. With a few hundred euros we could probably add a few missing important pieces. If you think it is a good idea : which piece would be important for you (bat, raven) to finish the branch?

By the way : we already have an axe (check in fantastic XIII). and musketterchess editor have a 2d icon for bombard and an an other for canon.

For diagonal long distance attack, I find the bow very clear. May be you should search a good representation for the phoenix and the kirin since you often use them, that would leave the archer/bow for the vao.

OK, sorry. I missed that 3D button. The Tiger looks nice. Most of the pieces in the table don't exist as 3D yet, though. And another concern: are we allowed to use the pieces there in Jocly? The Musketeer Jocly branch is proprietry.

Kirin and Phoenix are very popular shogi pieces, I guess for the lack of oblique leaps there. So their choice for 8-target leapers isn't so large. And many of my variants were shogi-inspired; this whole idea of flying pieces was taken from Tenjiku Shogi. In Minjiku Shogi I used the Rhino for Kirin, because I understood it is a horned mythical beast. But I don't particularly like the 3D realization of that . (Now that we have Giraffe I could use that instead, as this is the modern meaning of the Japanese word 'kirin'.) For the Phoenix I used the Stork, which is not one of my best creations, though. (It doesn't really have enough resolution.) I made it by replacing the vertex coordinates of the upper part of some other piece, (so it could keep using the same uvs and maps) with the aid of a small program to generate a set of tilted rings.But the piece I started from did not have enough rings in it to get a smooth effect, even though I like the overall shape.

Something completely different: In the latest version of fairy-move-model.js I added a (yet untested) function Model.Game.cbPiecesFromFEN. This is an attempt to automate the creation of the pieceTypes object in the game definition. You just pass it a FEN of the position you want, and then it would put standard descriptions of all the pieces that occur in the FEN, with the corresponding initial coordinates. For variants without very exotic pieces this then would be all that is needed. For orthodox Chess you only would have to write:

pieceTypes: this.cbPiecesFromFEN(geometry, "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR", 2);

and then continue with the castle: and promote: definitions.

One can allways add pieces to it later with statements like pieces[N]={ name: "xxx", ... };. Or perhaps I should put a method for that in the pieces object, so that you could write pieces.add({name: "xxx", ...});, which automatically puts it at the next number.

How useful this is depends of course on the 'palette' of pieces that are recognized. I now have the orthodox pieces P,N,B,R,Q,K, knighted A and M, Omega W and H (for Champion), bent sliders G and U (for Unicorno), hoppers V and X (for Xiangqi Cannon), Elephant, Camel and Zebra. S is the Asian Pawn (Soldier). If we stick to single letters D,F,I,J,L,O,T,Y are still left. Do you have any suggestions for how to assign those? (T could be Terror, and alternative name for Amazon.) It should be for pieces that have a well-established move only.

I also have some misgivings about the cumbersome way conventional Jocly programming implements initial Pawn pushes. Which clutters the function needed for promotion. This is totally unneeded, because Jocly's graphs intrinsically have position-dependent moving. So initial Pawns and normal Pawns could very well have been the same piece, using a graph with different moves on the 2nd rank than on other ranks. So I am thinking of generalizing the cbPawnGraph function to produce a graph that by default always allows the Pawn to move up to the mid-line of the board, but where an extra numeric parameter could limit the rank from which this is possible. (Which would usually be the starting rank.)

The 3d Musketeer pieces are proprietary. But If we find a good usage of some pieces, Zied would probably accept to opensource them. He has always accepted to do it so far for Jocly. I am not sure that they will add new pieces in the future. It is the easiest way to add new pieces with 3d support.

I Will try to test your new revolutionnary function cbPiecesFromFEN.

If you find a way to improve the pawn behaviour, it would be usefull because it is more a bypass than a choice.

You could also use the 3d antelope for kirin. The unicorn is rarely used and could be an alternative for some piece.

I have started a variant to test cbPiecesFromFEN.

For a 10*10 chessboard, is this syntax valid? pieceTypes: this.cbPiecesFromFEN(geometry, "rnbqkbnrrr/pppppppppp/10/10/10/10/PPPPPPPPPP/RRNBQKBNRR", 2),

I have this kind of error : locations[c] is undefined in line if(sqr<geometry.boardSize) locations[c][c==cc?0:1].push(sqr);

Concerning your default palette : I would suggest :

L : lion

F : falcon / hawk

T : Terror or tiger as in shogi or troll as in fantastic XIII

D : Dragon or terror with a dragon aspect or dragon king

Y : Snake like its tongue

The 3d pieces are nice. The 2d are rather low-quality: some have very much thinner lines than others, some even have fat white outlines, and the level of detail is very inhomogeneous. Some (such as Lance) have very little substance, which makes it hard to distinguish their color. I would prefer the XBoard symbol for that.

This 2nd skin is a very nice trick. I should definitely learn how to do that.

In the mean time I have been tinkering a bit with the 3d Queen, to see if I could equip it with wings. As a 'proof of principle' I put a hand-made attempy in Minjiku Shogi. It looks a bit amateurish, because I still don't quite understand how the diffusemap is used: I gave it uvs in a homogeneously colored section, but the wings show a lot of detail. When I had mapped all trianges to the same uvs triangle (out of laziness, figuring that for homogeneously colored images it would not matter where I cut out the part) it looked like a mosaic. Now I layed out the shape of the wing also in the uvs, and the triangles are no longer obvious. But it is a mystery where the coloring is coming from.

I think it is important to understand this, if we ever want to create 3d pieces by alternative means.

If you want to add a second 2d style for shogi with your sprites, here is an example : only a few lines in these 3 files (search western) https://github.com/fhoudebert/jocly/blob/cvp/src/games/chessbase/shogi/shogi-view.js

https://github.com/fhoudebert/jocly/blob/cvp/src/games/chessbase/shogi/shogi-set-view.js

https://github.com/fhoudebert/jocly/blob/cvp/src/games/chessbase/index.js

Shogi Beginners like me would find it easier to use it.

Modifying generated diffuse map seems hard. May be we should invest time in blender to learn how to bake diffusemap.

OK, great. My regular Shogi implementation and Tori Shogi now use bare kanji, and Chu Shogi pictograms. But I will probably make bare-kanji sprites, pictograms and the mnemonic piece set of each of those. For the pictograms I can use the XBoard pieces.

Modifying a diffusemap is not really different from creating one from scratch. Provided there is enough unused room in the existing map to paste the newly created stuff there.

The problem seems to be that the maps you create are not the actual maps used on the piece, but that Jocly still seems to modify them before use. I think this is what causes the dark bands on the wings I made. The Machine also has such dark streaks on its outside. But when I look at its diffusemap these aren't there. I had to squeeze a wing image in a pretty small area of the diffusemap, so any detail in that map will get magnified a lot; this is probably why the dark band on the wings are so wide.

I had some success in creating cylindrically symmetric pieces. How about this:

Now I don't see any disturbance on the diffusemap, which was evenly colored. While the normalmap had color #8080ff, which should code for flat surfaces. (But I put in enough resolution that even without reflection trickery the construct looks reasonably smooth, 16 points around the circumference, and 23 levels.) The shadow is purely due to the rendering algorithm paying attention to the lighting.

A next step would be to let the program also generate the normalmap, in such a way that it creates the illusion of roundness; then 8 points around the circumference would probably be enough.

The uvs the program generates are such that the entire 512x512 area of the maps is mapped onto the surface: one coordinate is the height, the other the distance around the circumference. This is probably not the smartest thing to do: it would be better to measure the distance on the surface along a 'meridian', to paint nearly horizontal surfaces with sufficient resolution.

I have done some refactoring on branch trial to use the fairy move model. I will do more to move the hmtl and images to res/rules if you can retrieve my modifications without conflicts.

You can add package-lock.json in .gitignore if you want.

I have done some refactoring on branch trial to use the fairy move model. I will do more to move the hmtl and images to res/rules if you can retrieve my modifications without conflicts.

You can add package-lock.json in .gitignore if you want.

I can see the wings on the queen now. I had a cache issue before. The result seems acceptable to me. The dark band look like shade and light. On my browser the result is OK.

I wonder what kind of 2d sprite you will choose for phoenix/kirin. It is an important choice since It should always be kept for this kind of piece in Jocly. Will you choose a new bird icon for phoenix or ferz/elepahnt composed icone?

I think shades like those on the wings are caused by the normalmap. But I thought I had made that completely neutral too. As I made them by hand I might have mesed up, and the mapping to the uvs might not be continuous.

Anyway, I just arrived at the bottom of the learning curve, and in a few days I can probably do much better. E.g. the wings now are razor sharp, which makes them invisible when viewed edge on. (You would still see the other, but it still looks unnatural.) This can be avoided by not making them completely planar, and give them a thickness. (The need two sides anyway, as all surfaces act like one-way mirrors.)

I have created some 3d pieces with the piece-creation tool I am developing. It can now also make elliptic and excentric levels. (But still all strictly horizontal.) This increases the possibilities. It also creates the maps, as uncompressed Windows BMP files. (But with the Linux command 'convert'  I can then turn them into JPG. On Windows I would do that with MS Paint.)

At the moment it still creates a completely neutral normalmap, and it uses false colors (red, green and blue) for the diffusemap. Teese colors alternate between horizontal sections of the piece, so that you can use a drawing program to fill them with the desired colors. With a sufficiently advanced drawing program you might even create smooth color gradient. (But I don't seem to have such a program; GIMP is either very primitive or I don't know how to use it.) Of course the generation tool could very easily create the color gradients, if it only knew what colors to use.

I suppose we could derive a mapping tilt-ange to color from the existing Jocly pieces, and then let the program smoothen those with a gradient when the angle between neighboring surfaces is small (but keep discontinuous jumps when the angle becomes acute). The same way it should do it for the normalmap.

I made some new pieces, which I intend to use for the Shogi generals and the Omega Champion. I currently replaced the N, B and Q of the Staunton set with those ( http://hgm.nubati.net/jocly/jocly-master/examples/browser/control.html?game=classic-chess ). With a little improvement of the maps I think they would be very acceptable. I still intend to paint stars on the caps of the generals to better distinguish those from each other.

As for the Phoenix: I am quite satisfied depicting the Phoenix as a Stork. (After all, it was a mythical bird, so no one knows exactly how it looked. But it was not a bird of prey, so it would not have looked like an Eagle!) Like I already do in 3d (even though the Stork there still needs some work). I would try to match that in the 2d graphic. Even if it means I have to draw it myself. Using an Elephant for Phoenix strikes me as horrid. For the Kirin I am quite happy with the Giraffe, which is good quality both in 3d and 2d. (And in 3d it is about equally tall as my Stork, which is also nice.)

I am not sure if the representation has to be constant over games. In Makromachy I used the Bow for the Phoenix, because that fits with the theme of the flying pieces. I can always use the excuse there that it is not a normal Phoenix, as it blocks flying pieces, onlike any other normal piece.

The 2d stork idea sounds good to me.

Here is a svg on the hieroglyph H18 : meaning to speak, to say in Ptolemaic egyptian

It looks small but it can get bigger easily (svg) :

https://thotsignlist.org/images/pictures/shapes/H18.svg

There's an artistic dimension to the hieorglyphs that could help you to make good sprite for jocly.

By the way, we have received an application for the position of 'terror' in minjiku shogi, let me know if you think the profile is suitable :

http://biscandine.fr/variantes/test/examples/browser/control.html?game=elephantine-chess

It might become opensource if you think it is worth asking.

I definitely like that one a lot more than the old Dragon. (Which is hardly recognizable.) The 2d Stotk is also nice, but it would not fit in a square very well. I  would prefer one looking down diagonally.

With the aid of MS Paint I could put some more details in the diffusemap, and the pieces really start to look usable already:

Ok I'll add it to github when I get the musketterchess agreement to put it under the license of jocly :

https://creativecommons.org/licenses/by-sa/3.0/#

2024 is the Year of the Dragon in China. We will be ready, we've just received our 2nd dragon in branch trial

The piece-creator tool now produces reasobly good results. I created a number of pieces: Wizard, Champion, Gold & Silver General, Scout and Berolina Pawn:

The tool takes a list of measures, like this:

16
0.000 0.720
0.075 0.755
0.211 0.660
0.337 0.710
0.705 0.521
0.992 0.342
1.571 0.241
1.620 0.413
1.750 0.264
1.830 0.348
1.955 0.420
2.115 0.450
2.273 0.420
2.400 0.348
2.433 0.310
2.440 0.480: 0.75 0.165
2.520 0.320
2.710 0.360
2.711 0
out: gold
ridge: 0.700 -0.08 0.10
ridge: 0.800 -0.08 0.05
ridge: 0.384 0.15 -0.08
ridge: 0.384 -0.15 -0.108

and then produces the mesh file and the diffuse and normal maps. The diffusemap looks like this:

It can be post-edited, like I did here to paint the cap's overhang black, and inscribe a star on the top of it. The red/green markers indicate the various sections of the piece.

I replaced the Staunton set in the Jocly on my website by this. (But you might not be able to see it without directly refreshing all the /res/staunton/*/* files in the dist tree to flush the ordinary staunton pieces from the cache.)

http://hgm.nubati.net/jocly/jocly-master/examples/browser/control.html?game=classic-chess

It is not yet a Phoenix, but I am getting proficient now also in the fabrication of birds:

I now also made it possible to give color instructions for each section separately in the input file. These come in two kinds: a hexadecimal number after a 'paint:' keyword would force the corresponding color homogeneously on the section. That would also overpaint any wood grain. The number given after a 'shade:' keyword would just be added to the default coloring everywhere in that section.

I also added a command for specifying eyes (by height along the surface, angle along the circumference and size) ad dips in the normalmap.

Great work, H.G.!

Nice Goose piece!

I see a nice Flamingo here!

Some new creations: Stork, Owl, Rhino, Flamingo and Phoenix.

The pieces I make this way are much more similar in style to Staunton pieces than the Musketeer pieces. The latter are much too detailed. (Staunton King and Queen don't even have eyes!) I consider abstraction a good thing in a chess piece; details just distract from the game. The Rhino that was in the Jocly fairy set was a bit too abstract for me, though...

@Aurelia: I am nearly done with the Jocly pieces, and then I will help you.

Those look delightful, H.G.!

(Clearly, though, the Owl here is not the same Owl that I use.) ;)

Are there suggestions for pieces that we are still sorely missing in Jocly? A Kirin seems to be a chimera of a dragon and a deer, but since no one probably knows that anyway we might as well stick to a Giraffe for that. Antlers would still be difficult to do for me. In Mechalomachy I use a Ram; the horns of that would also need a fair amount of post editing of the mesh file.

Hello H.G.

I fully agree with you about the needed level of abstraction in chess variant set.

You have rapidly improved your skills in 3D drawing, this is impressive.

The Rhino in Jocly was awful and I'm glad you have re-done it. Actually, it looks a bit offside in the image you posted. Do you have a link of a Jocly board so I can see it from different angles?

Kirin/Giraffe is OK. In case it is needed, you had also a nice horned dragon that you have shown few days ago I think.

I don't know if it can be useful, you might have a look on my own work on Thingiverse with a selection of CV pieces needed for my own games.

https://www.thingiverse.com/kazo65/designs

BTW, is there any possibility of exporting or at least linking a piece for Jocly and a .stl file?

If I consider the usage of the lighthouse (a piece used when we miss the right one) : I think we need a feminine figure : (for the duchess for instance) may be like this one :

http://biscandine.fr/variantes/pieces/t4/blanc/2-femme%20fatale*1.stl

It would be usefull to have a mage or a champion as well :

https://cults3d.com/en/3d-model/game/omega-chess-champion/similar-designs

We miss also a snake, (half rhino) It would be better to use a snake than the dragon for this usage.

And You will probably add silver and gold general for your variants

I've moved rules, descriptions to res/rules for all variants except those in the decimal and shogi directories to avoid conflicts with your modifications. I hope you'll be able to retrieve them easily from :

https://github.com/fhoudebert/jocly

The existing antelope 3d with a different 2d picture was an option for the kirin, we are used to kirin as a fantastic deer in Miyazaki animation film or japanese beer.

But a giraffe is also an acceptable compromise since if I remember correctly, giraffes brought back to China were presented as kirin in the past.

For a distinctive Kirin (in case someone *koff koff* wants to do something with both a that and a Giraffe), my image searches have come up with a dragon-unicorn, sometimes (this being the case for my models/icons) with the single horn headed straight back off the forehead.

(That said, for some reason my current search is bearing out your description, even though my earlier searches showed mainly my latter one.)

Also, since you have a Flamingo (1,6), you might as well have an Ibis (1,5).

Anything else I can think of would get too little use to be worth the work.

The Rhino in Jocly was awful and I'm glad you have re-done it. Actually, it looks a bit offside in the image you posted. Do you have a link of a Jocly board so I can see it from different angles?

I uploaded all new pieces to my website now, and created a dummy game to show them all:

http://hgm.nubati.net/jocly/jocly-master/examples/browser/control.html?game=piece-display

(This is a clone of Scirocco where I replaced the images without regard to what the original pieces was, so don't be surprised if they move in a very funny way.)

BTW, is there any possibility of exporting or at least linking a piece for Jocly and a .stl file?

I don't know enough of Jocly to answer that. All I did was look at how the pieces that did come with Jocly were encoded, and mimic that. My guess would be that this is not possible.