Comments/Ratings for a Single Item

I have pushed a new fairy piece (leopard) on this branch : https://github.com/fhoudebert/jocly/tree/timourid/src/games/chessbase/res/fairy You can retrieved it if you are interested, musketeerchess has agreed to share the 3d export with the opensource licence of jocly.

@HG Muller: Michel Gutierrez told me today that he will integrate the pull requests en march 2024

I am certainly interested to add more 3d pieces to Jocly; it would be great if I could use the Wolf for Werewolf Chess. (I now use an Eagle.)

At some point I would like to integrate all your games in my branch too. I understand that on GitHub you put each game in a separate branch? I never used GitHub (other than to clone the Jocly master branch), so I don't really know how that works. Do you have a local git repository on your own PC, and push your own branches from there to GitHub?

I am working now on a new sub-model, fairy-moves-model.js, to simplify the implementation of some of my other games (in particular Chu Shogi). Games that incorporate that script in their model file would have access to some extra pre-defined Graph functions (Camel, Zebra, Alibaba, Champion, Wizard, Vao, Griffon, Rhino). It also activates the infra-structure for locust capture and double capture, and defines flags that you can pass to the various move graphs to implement Checker capture, rifle capture and Lion capture. (Perhaps I will add Advancer and Withdrawer capture too.) And it supports some anti-trading rules through a new member 'antiTrade' in the piece definitions.

You can clone my fork : https://github.com/fhoudebert/jocly.git and then checkout the timurid branch which contain all the games + pieces. I can push from my pc. Your fairy-moves-model file will be usefull, it is a good idea.

You can clone my fork

And here I am, watching for sentences that would make no sense 30 years ago. :)

If I understand things correctly, cloning your fork would give me a new repository, independent from any repository I already have. So I could not rebase your branches onto mine, because mine would not be in that repository. The operation to import another branch into my existing repository would be 'git pull xxx yyy', where xxx is a remote git repository and yyy the name of the branch there I want to import. But I am not sure how I can add your fork on GitHub as a remote repository for the Jocly project.

You might be interested with this link : https://thotsignlist.org/sign_gen

You will find SVG that can be used for 2d chess symbols.

I have found your file fairy-moves-model.js very interesting. I didn’t manage to integrate it yet in my variants. May be you could add a Rhino when it is ready for all to "new piece show case" variant to show how to integrate it?

The Rhino already existed as a piece in the fairy-set-view.js, in the main branch that I cloned from GitHub. The cbRhinoGraph function provides the move graph for the piece that is now customary called Manticore, but for which everyone appears to use the rhino image in 2d diagrams.

I wonder if I should make a function cbBetzaGraph(geometry, betzaString) that could be used to implement arbitrary moves. E.g. cbBetzaGraph(geometry, 'BN') to get an Archbishop.

I was able to implement Chu Shogi entirely with the aid of the fairy-move-model.js; it needed no special JavaScript code in its own model file (other than the usual promotion instructions). It is a bit annoying that Jocly does not automatically use a flipped graph for the black pieces. This means that many Shogi pieces need to be defined as different types for black and white. Which again causes complication of the promotion rules when a symmetric piece promotes to an asymmetric one. That makes it difficult to implement a simplification for defining shogi promotions.

Things I still want to add to the fairy-move-model.js are paying attention to the move/capture flag in the definition of the second leg of the hit&run capture (this.neighbors), which now always assumes both. And definition of a burnZone graph similar to neighbors, which would be used by moves with the FLAG_BURN set, where the burning would be an automatic side effect (like Advancer capture). By default it would then only burn enemies a King step away, but by redefining this.burnZone you could also make it burn friends, or even the moving piece itself (by including [0,0] in the step set) to support kamikaze moves.

I am still doubting whether it should include support for pieces that can jump arbitrarily many others, such as the Tenjiku Shogi generals. This seems to be very game-specific, especially if blocking rules exist that depend on a ranking.

A cbBetzaGraph function would surely be usefull.

The Jocly chessbase model works by tabulating all possible paths that go from each square, and assuming the pieces slide along those paths. It has a special provision for hop capture, but it does not appear to support hop non'capture. This makes it easy to support arbitrary trajectories, such as those of Griffon, Rose and Crooked Bishop. Partly coinciding paths can be made a bit more efficient by treating the duplicat as moved over by a lame leap, so that the duplicat path can be blocked there, but doesn't generate the same move twice. For a Crooked Bishop this would not be feasible, though, as you canot know in advance which of the two paths to distant targets on the orthogonals is blocked. Generating moves for pieces with long coinciding paths, such as hook movers or Sissa, would get very inefficient. For those it would help if move graph would be stored as trees, being able to branch after it has been established that the path to the fork is clear.

So perhaps I should enhance the base-model.js first, by adding a new flag to indicate the mentioned square is not a potential target, but an index in the array of targets where an alternative continuation of the path is described, next to the normal continuation that continues in the next mentioned square. And something to support hopping non-capture. That would allow full support of the original betza notation, and even support of multi-leg moves with m non-final legs for indicating complex bent paths for sliding or lameness.

Testing for attackers of a given square might become complex, though.

Seems interesting The more (piececlopedia moves and visuals) we can find in the fairy*.js file, the better il will be.

I would like to try the integration of one of the games (fantastic XIII for example) on your hgm branch to test more your fairy-move-model.js. But I still have compilation issue.

On the jocly of github, I had to fix in my path :

VERSION=v10.24.1
DISTRO=linux-x64
export PATH=/usr/local/lib/nodejs/node-$VERSION-$DISTRO/bin:$PATH
before launching: gulp build

Is there anything to do to build your hgm branch locally: fix a node version,  pass a parameter, launnch a specific script?

If I believe the comments, you must be very busy at the moment. As there is no emergency to study the reconciliation of the different git branches of jocly, we could see this later. Congratulations in any case.

Well, life is turning back to normal, and working on Jocly was the first thing I took up again (as it was also what I was doing just before I left to Stockholm, with several open ends left).

I build locally on a Linux virtual machine (Ubuntu 18.10 running under VirtualBox), using the command

gulp build --prod

That takes about 2 min to build the entire project. I am not really an expert on building; I never succeeded in building under Windows, despite the fact that Michel was advising me. And I forgot what packages I had to install to make it work; this was many years ago, and then I got stuck on the repetition-hash problem.

I run 'http-server' in the jocly root directory from another terminal window. After a successful build I can then go to http://localhost/examples/browser/control.html to test things. (It does not work if you open that directly on FireFox as a file.) An annoyance is that FireFox appears to cache .js files, and that the normal way to bypass the cache (pressing the Shift key during refresh) does not work, most likely because Jocly loads most of the .js files on demand later, when all is forgotten about the Shift. So what I do is open the .js files that I changed in other browser tabs, and do a Shift+reload of these after the build, before restarting Jocly. That then has forced the most recent version into the browser cache. When developing a game usually only /dist/browser/games/chessbase/GAME-chess-model.js changes; first time you add the game /dist/browser/jocly-allgames.js must be refreshed too for the game to become selectable.

I had achieved the stage where Chu Shogi worked well through fairy-move-model.js, but this was not an exhaustive test. So now I am working on implementing Makromachy (one of my own designs), and encountered many more bugs. (Zebra moves were crazy, I had swapped the moves of Griffon and Rhino, the AdvancerGraph, which did pass a test before, got somehow broken...) I also needed some new features for Makromachy, in particular asymmetric anti-trading rules, 'flying' pieces, custom-generated escape moves for hit & run capture, and the customGen function for programming 'airlift' moves.

I will shortly push everything I have; most of it tests OK now. But I am still working on the flying captures. These were so close to what the existing code in base-model.js already did for 'screen captures', that I decided to implement it there. As far as generating moves this already works, but I still must adapt cbGetAttackers so that it can see flying pieces amongst the attackers. As it is, it happily moves his king onto squares attacked by a flying piece when more than one piece blocks the line of sight.

Thanks for the news. I will wait the next version then. ctrl+f5 pour js reloading might help

OK, I pushed my latest changes on fairy-move-model.js and base-model.js, and I think these are pretty well debugged now. At least everything appeared to work as intended on the Makromachy game that I am developing, and that uses most of the new features.

En-passant capture is still a problem, though, with Pawns that can be pushed more than two steps. The original chessbase code only allows the pawn to be captured on the square directly behind it. I suppose the best solution is to make epTarget not just a square number, but an array of square numbers, so that there can be more than one e.p. square. This would be a change in base-model.js.

A problem specific to Makromachy is that e.p. capability is currently specified per piece. There is no way to limit the capture to a subset of the captures; any capture-only move can also e.p. capture for a piece that has epCatch:true. It would be more logical if this could be controlled by a mode flag of a move graph rather than a piece-type property. In Makromachy I have Warrior pawns that also have backward Knight captures, and the latter are not supposed to e.p. capture. I suppose I could create a work-around by allowing other values for epCatch, e.g. epCatch:2 meaning 'only the forward captures'.

Another thing I don't have yet is 'fast castling'. But I am not sure that should be supported through fairy-move-model.js. Perhaps I should just write some code for it in makromachy-model.js, using an initial type for the corner pieces, and add capture of their own king to their normal graph (through a FLAG_CAPTURE_SELF mode that would push them as candidate moves to the special moves stack, so that it can be vetted and possibly pushed on the normal moves stack by a routine customGen.)

Also still missing are 'brouhaha squares'. I suppose these could be implemented by using a confine on the moves, so that only captures can reach the brouhaha squares. (Except that confines also suppress moves that start outside the confine region.) I suppose that more subtle interpretation of non-zero values in a confine array could indicate some squares as "cannot move to there, but can capture". By taking a weird value to mean that, the chances of breaking anything existing will be very slim.

By taking a weird value to mean that, the chances of breaking anything existing will be very slim.

Unless, of course, I get my hands on it. ;)

I've started to digest all the innovations in the file. Well done, it's going to open up a whole new world of possibilities for Jocly. I've managed to move the model to one of my branches and also to build the hgm branch. I'll be able to try things out next week. I think there's still something to fix on the locust capture. It can be reproduced by playing chu shogi computer vs computer. I didn't really understand the origin of the issue yet.

The author, Jean-Louis Cazaux, has updated this page.