Comments/Ratings for a Single Item

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.