Comments/Ratings for a Single Item

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.

OK. It is not clear to me where everything is supposed to go. (And apparently that was sort of a common problem, as most people who made games made a mess of it.) I often did not make any supporting material at all, as control.html would not give access to it anyway.

Do all the images that are to be used in the rule description also go into res/rules? Or do they go to res/visuals?

Where are the thumbnails supposed to go? Unlike other visuals the bulding process appears to move them to chessbase, and when I moved model & view for a game elsewhere, I could not move the thumbnail there too (even if the new location was specified in index.js); they just would not show up when I did that, because the index.js kept pointing to the original location. So I moved some to res/rules, which is almost certainly not where they should go.

Description and credits go with model and view?

The Flamingo, the Phoenix, the Owl, the Stork are nice. I'm less enthusiast for the Rhino. I know, it's not easy because that animal has "an horizontal" body. I faced that problem when designing on Tinkercad too.

I know, it's not easy because that animal has "an horizontal" body.

I suppose we could ignore that, and just have it look straight up. The Seirawan Elephant does that, no doubt for the same reason.

An alternative is to let it look sideways. Some players prefer to let their Knights look sideways...

How about this Cobra?

Pretty good. Even toothless it would be nice. (I prefer some abstraction).

Yeah, I am not happy with the teeth either. They are too small to see in the normal view, and turn all black at intermediate magnification. Perhaps I  should only leave the hint of teeth, by post editing the mesh file to bring down two points of the body's surface. Similar to what I did for the ear plumes of the Owl.

The eyes in general  also need some work. I have done those now only through the normal map, changin the direction of the reflections and affect the shading. That is cllear enough in close up, but makes rhem unnoticeable otherwise. So I should apply some darkness in the diffusemap as well.

It is also very difficult to match the overall color of existing pieces. These appear to have some irregular large-scale color variation in the diffusemaps, while I use a plain color with spuper-imposed synthetic wood grain. This makes the black pieces look like they were made of chocolate...

A cobra would be usefull

Static ressources are used during the build process only if in the chessbase or in the chessbase/res/** dir

For instance, if you organise this way, you should be able to load your ressources in joclyboard or can link it in a modified version of control.html

*res/rules/shogi

• shogi-credits.html
• tori-shogi-description.html
• tori-shogi-description.html

*res/rules/scirocco

• scirocco-rules.html
• scirocco-description.html
• scirocco-credits.html

*res/visuals (screen captures) +tori-600x600-3d.png +tori-600x600-2d.png

Some ressources are shared among variants : for ex res/rules/graphs res/rules/pieces res/rules/fairy

Specific images might be keept in

res/rules/shogi res/rules/scirocco

• or res/rules/decimal if you have not a lot per variant

You can move your dist dir in joclyboard to test : replace in joclyboard/app/node_modules/jocly

I tried this, to investigate if it is better to have the Rhino look upwards. I believe it is: it keeps the ugly face where the head was cut off from the body out of view:

As for the Cobra below: I think the teeth indication looks more natural there then when I had defined the teeth as separate objects.

The cobra looks good like this

The Cobra is nice indeed. And the Rhino is far better than what was in Jocly before.

I have now started adding the new pieces to the 'trial' branch of my Jocly repository. I have also made some new fairy-sprites for them:

Very nice 2D icons.

Well done : the sprites are easy to understand and well within the theme.

I have pushed your contributions to github. you can pull the updates if you want to avoid too much divergence.

Thanks. I will pull as quickly as possible. At the moment I still have too many uncommitted changes that would collide with a merge: pieces I have not committed yet, but which are already in the fairy-set-view for testing them, and index.js for adding the piece display. Plus modifications in Minjiku Shogi for using some of the not-yet-committed pieces.

The directory chessbase/res/fairy is starting to get uncomfortably large as well. There the trick of using subdirectories is already used (even though in principle all *.js, *-diffusmap.jpg and *-normalmap.jpg could have coexisted together, as the piece name is also in the filename). But it is not really exploited well, with only 3 files per directory.

So perhaps we should combine some of the piece directories, so that they contain the .js and .jpg files for a group of pieces. I have already done that for the generals: rather than making separate directories gold, silver and copper in res/fairy I put them all in res/fairy/generals. In a similar spirit we could have directories for knighted pieces (cardinal, marshall, amazon), knightlike (ferz-knight, wazir-knight, nightrider, zebra) crowned pieces (rook & bishop, both old and new version), hoppers (cannon & cannon2, flying pieces), omega pieces (champion & wizard), birds (eagle, stork, phoenix, flamingo, owl), pawns (classic, hoplit & berolina)...

I also thought it would be a good idea to bring together prince, man and admiral, which are used for much the same purpose.

It's probably best to wait until we've merged the first part of our refactoring.

As I realize that you are capable of making good 3d realizations, here's a piece inspired by www.superchess.nl's femme fatale, which could be used as a duchess in some variants, and probably would find other uses :

http://biscandine.fr/variantes/pieces/Femme%20Fatale.stl

I hope you will find it useful or feasible.

I don't seem to be able to display .stl files. If I click your link my browser even refuses to download is, with the error message that it is dangerous. I do have the Superchess pieces, though, so I know what a Femme Fatale is. I suppose I could even do better, because the Superchess pieces suffered the restriction that they had to be strictly cylindically symmetric, while I can allow excenticity.

[Edit] Like this?

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

I now have debugged this (and pushed it). The numeric argument(s) after the FEN get a different meaning, though. For one they are optional. The first is the furthest rank where the Pawn has extra moves (which by default is everywhere). Only single-step moves can end in the opponent half, though. The other number can limit the push to even shorter distance than that. Note that for orthodox Chess the default is OK; for boards with 6 empty ranks between the armies you would have to specify the pawnRank if you don't want the Pawn to have a double-push after a single step, and maxPush if you want to prevent triple pushing.

The FEN in your example is 10x8, not 10x10. That would still work, but leave two empty ranks at the white end.

As to you suggestions: they seem logical choices for the letters, but I am afraid almost no one would use these pieces. (Or at least not with the move we endow them with; they don't have strong move associations.)

@ François and HG: no .stl are not dangerous, this is the most common extension for 3D printing. No, the fact is, François, that the link you sent is corrupted. For me too, it cannot open and I get a message that this file is dangerous. You can try this link:

https://www.tinkercad.com/things/6MCsUshBVm4-femme-fatale?sharecode=Q4U5-HZHlGiXscfJX1laJMcA2-jErKcuRTDSgozfEwg

For HG: indeed, this piece should be strictly cylindrically symmetric.

I have changed cbPiecesFromFEN() a bit: instead of returning the pieceTypes object, it now returns a larger object that has pieceTypes in it as one of its properties. This so that I can return also other stuff, such as a standard promotion routine. So a game definition using it would now look like this:

    Model.Game.cbDefine=function(){
        var p = this.cbPiecesFromFEN(geometry, "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR");
        return {
            geometry:geometry,
            pieceTypes: p.pieceTypes,
            promote: p.promote,
            castle:{...

Promotion would be by default on the last rank, to any non-royal non-pawn piece (i.e. not to P or S).

To make it possible to use this in combination with pieces that are not supprted, I also defined a few methods in the returned object to allow you to alter it. So in the example above you could use

type = p.addPiece({ ... });

to add a new piece type that you defined yourself in the old way. It would not automatically be added to teh promotion choice, but you could do that through

p.promoChoice.push(type);

It would also be possible to  completely alter the promotion choice by setting

p.promoChoice = [...];

with an array of your own choice. You could also alter the depth of the promotion zone through

p.promoZone=N;

To alter (or add completely new) properties of a piece that was automatically geneated from the FEN you can use

p.setProperty(abbrev, property, value);

Next thing would be to also provide a default castling table. That would in fact make it possible to just write

return p;

in the game definition.

Note that when the FEN has more ranks than the board size defined in the geometry, the pieces mentioned on the extra ranks will have their types defined, but will not be in the initial setup.

I still have to debug and push all this.

The stl can be imported in blender or opened with freecad for display.

Yon can‘t use it straight away unfortunately

The idea is to pay tribute to the classic piece without actually copying it (not opensource). The piece is well known and much appreciated for its turned wood look.

I think the choices you make will be influential for a long time to come, that is why it would be great to find designs that were appreciated as physical pieces to play with, like the falcon from musketeerchess or the femme fatale from superchess.nl.

The idea is to pay tribute to the classic piece without actually copying it (not opensource). The piece is well known and much appreciated for its turned wood look.

Do you think the design I made infringes on any copyright? Most of it is rather obvious: just the shape of a woman in a dress. Such elementary things do not cary any copyright. The only issue is perhaps the hat suggested by the rim around the head; I could change that to some other cover (or none at all).

Do you think the design I made infringes on any copyright?

I've delved a bit into copyrights and such, and as far as I can tell, even assuming that the piece does have a copyright attached, yours is pretty safe. It's an original piece that represents the same idea.

It's rather like the various "Spy" pieces and icons showing a guy with a forward-tilted fedora.

I now pushed a fully debugged version of fairy-move-model.js, and in particular the new cbPiecesFromFEN facilities, to my 'trial' branch. I also made a description of what it can do:

Facilitate definition of 'run-of-the-mill' chess variants

A routine this.cbPiecesFromFEN(geometry, fen, pawnRank, maxPush) is
provided, which will return an object that contains both the
pieceTypes object and promote function that you would have to return
in a game definition. The pieceTypes object is derived from the
provided FEN, which can contain many commonly used fairy pieces.
Such as Archbishop (A), marshall (M), (xiangqi) cannon (X), camel (C),
zebra (Z), elephant (E), champion (H), wizard (W), griffon (G),
rhino (U), vao (V), Shogi Pawn (S, for soldierw/soldierb), Lion (L)
and amazon (T).

The last two arguments are optional, and would limit the board area
where a Pawn can be pushed forward by more than 1 step, and by how
many steps, respectively. The default is that Pawns can be pushed
up to any square on their own board half only when still on the
starting rank (derived from the last white Pawn encountered in the
FEN). For variants with 8 board ranks and orthodox Pawns this default
suffices.

When no other unorthodox pieces are participating than those mentioned
above (all orthodox pieces are of course supported too!), and the
promotion rules are orthodox, defining the game can become extremely
simple. One can just feed the FEN of the initial setup to
cbPiecesFromFEN, and get the pieceTypes and promote values that
the cbDefine function has to return from there.

For example, if we use the function inside cbDefine() as

var p = this.cbPiecesFromFEN(geometry, fen);

the object with piece definitions will be p.pieceTypes. All pieces
occurring in the FEN string will be included in this. The FEN can
represent a board with more ranks than the actually defined board;
in that case only the pieces on the actually existing ranks will
be placed in the initial position as described. Other pieces will
not appear, but their type will be available for promotion.

All mentioned pieces other than King (K) and Pawn (P or S) will be
included in an array p.promoChoice, and a standard promotion function
that allows Pawns to promote on last rank to any of those will be
available as p.promote. If the default choice is not suitable,
one can assign another array to p.promoChoice, and still use p.promote.
Likewise, if the promotion zone contains N ranks rather than one,
this can be achieved by assigning p.promoZone=N.

The piece types defined with the aid of this function will all be
defined with a move graph for their usual move, and a piece value
suitable for an 8x8 board. If this is not desired, one can still
use the function to define them, but alter their graph (or any
other property) afterwards by calling

p.setProperty(name, property, newValue);

(Note that the name used for pawns is diversified by color: 'pawnw' or
'pawnb'.) This can also be used to add entirely new properties.
For adding moves to those the piece got by default we can use

p.addMoves(name, graph);

with 'graph' the graph of the moves to be merged in.

We can also define additional pieces from scratch, by writing

p.addPiece({...});

with the old-style piece definition on the dots. This function returns
the type number of the thus-added piece. If we want to know how many
types we have defined so far, we can find this in p.nr.

Note that the Lion and Amazon are now supported through L and T in the FEN. For the remaining letters I still have not decided. It only makes sense to add pieces that are frequently used, with a commonly accepted move. This sort of excludes quirks like Snaketongue and Ship. I am in doubt about Nightrider; it is well known, but not used very frequently. Grasshopper is well known, but virtually never used. (And Jocly currently does not support grasshopping anyway.) Perhaps the Crowned pieces after all (D and Y?). Or a non-royal King? The Steward (omnidirectional Pawn) also seems a reasonably popular piece.