Check out Symmetric Chess, our featured variant for March, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Later Reverse Order EarlierEarliest
Zanzibar-S. A game in between Metamachy and Zanzibar-XL with 36 pieces per side. Preferred by some to the -XL version.[All Comments] [Add Comment or Rating]
🔔Notification on Wed, Jan 17 07:26 PM UTC:

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


François Houdebert wrote on Sat, Dec 16, 2023 11:56 AM UTC in reply to H. G. Muller from Fri Dec 15 11:02 PM:

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.


Bob Greenwade wrote on Fri, Dec 15, 2023 11:55 PM UTC in reply to H. G. Muller from 11:02 PM:

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. ;)


H. G. Muller wrote on Fri, Dec 15, 2023 11:02 PM UTC in reply to François Houdebert from 03:11 PM:

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.


François Houdebert wrote on Fri, Dec 15, 2023 03:11 PM UTC in reply to H. G. Muller from 01:04 PM:

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


H. G. Muller wrote on Fri, Dec 15, 2023 01:04 PM UTC in reply to François Houdebert from 07:32 AM:

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.


François Houdebert wrote on Fri, Dec 15, 2023 07:32 AM UTC in reply to H. G. Muller from Fri Dec 8 02:59 PM:

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.


François Houdebert wrote on Sat, Dec 9, 2023 11:48 AM UTC in reply to H. G. Muller from 07:55 AM:

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


H. G. Muller wrote on Sat, Dec 9, 2023 07:55 AM UTC in reply to François Houdebert from Fri Dec 8 03:21 PM:

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.


François Houdebert wrote on Fri, Dec 8, 2023 03:21 PM UTC in reply to H. G. Muller from 02:59 PM:

A cbBetzaGraph function would surely be usefull.


H. G. Muller wrote on Fri, Dec 8, 2023 02:59 PM UTC in reply to François Houdebert from 09:10 AM:

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.


François Houdebert wrote on Fri, Dec 8, 2023 09:10 AM UTC in reply to H. G. Muller from Fri Dec 1 08:17 PM:

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?


François Houdebert wrote on Fri, Dec 1, 2023 09:35 PM UTC in reply to Bob Greenwade from 09:21 PM:

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

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


H. G. Muller wrote on Fri, Dec 1, 2023 09:30 PM UTC in reply to François Houdebert from 08:55 PM:

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.


Bob Greenwade wrote on Fri, Dec 1, 2023 09:21 PM UTC in reply to François Houdebert from 08:55 PM:

You can clone my fork

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


François Houdebert wrote on Fri, Dec 1, 2023 08:55 PM UTC in reply to H. G. Muller from 08:17 PM:

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.


H. G. Muller wrote on Fri, Dec 1, 2023 08:17 PM UTC in reply to François Houdebert from Thu Nov 30 02:25 PM:

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.


François Houdebert wrote on Fri, Dec 1, 2023 05:56 PM UTC in reply to François Houdebert from Thu Nov 30 02:25 PM:

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


François Houdebert wrote on Thu, Nov 30, 2023 02:25 PM UTC in reply to H. G. Muller from 10:32 AM:

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.


H. G. Muller wrote on Thu, Nov 30, 2023 10:32 AM UTC in reply to François Houdebert from 10:03 AM:

Well, in jocly/dist all games are always in the chessbase directory, no matter where they were in jocly/src. So there should not be any problem.

[Edit] I added some more groups: famous (5), decimal (4), amazons (3), knighted (2) and standard (4). The latter three will absorb all variants with orthodox pieces, BN, RN, KN and QN (and flat boards based on squares other than 10x8 or 10x10). The 'famous' group takes regional variants plus Shatranj.

I thought of making a directory 'fairy' for variants that include other pieces, but that is basically everything that is now left in chessbase. So I suppose that is not distinctive in any way.


François Houdebert wrote on Thu, Nov 30, 2023 10:03 AM UTC in reply to H. G. Muller from 07:49 AM:

Usually I copy jocly/dist to joclyboard/app/node_modules/jocly/dist

but you are right, I should investigate more since It should be fixed easily if it is confirmed


François Houdebert wrote on Thu, Nov 30, 2023 10:02 AM UTC in reply to H. G. Muller from 07:49 AM:

Usually I copy jocly/dist to joclyboard/app/node_modules/jocly/dist

but you are right, I should investigate more since It should be fixed easily if it is confirmed


H. G. Muller wrote on Thu, Nov 30, 2023 07:49 AM UTC in reply to François Houdebert from 07:30 AM:

Ah, OK. But I see it is open source. So it could always be changed to do whatever is needed.

I doubt that something would be needed, though. The model and view files for the various games in src/games/chessbase would not work on their own; they must also use underlying models and views for piece sets and boards. The only place where it is indicated which piece set or board model must be used for a given game is index.js. And the latter contains the path name of the models and views specific for the games.

But that is assuming that jocly-board uses the source code. Building Jocly does not only create a library in dist/browser, (where for each game all required model and view files are combined, and put into dist/browser/games/chessbase in compressed form), but also in dist/node. I never used the latter (I always test the builds through the browser part), but I suppose this is intended for any off-line application.


François Houdebert wrote on Thu, Nov 30, 2023 07:30 AM UTC in reply to H. G. Muller from Wed Nov 29 09:27 PM:

Joclyboard is an offline desktop application https://github.com/mi-g/joclyboard quite convinient


H. G. Muller wrote on Wed, Nov 29, 2023 09:27 PM UTC in reply to François Houdebert from 07:16 PM:

What is jocly-board? Is that built from the project? One would expect it to use the library rather than the sources. There the config, model and view files are still all in one directory.

Anyway, I did some grouping. There now are directories shogi, 3d (2), hex (5), circular (3), mini (7), capa10x8 (3), tressau (2) and cazaux (5). I will probably add 'historical' as wel. Janus Chess should probably go into capa10x8, Los Alamos Chess into mini, and Wild Tamerlane in cazaux.

During testing I noticed that the new zobrist scheme broke Metamachy, because it is still directly calling the old scheme from its model code, to calculate keys for the initial setup. I will fix that later.


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.