Comments/Ratings for a Single Item

I think so. The Stork, Elephant, Leopard and King are all in the fairy-sprites.

There only is the matter of diversifying the Quail. It is probably best to have the Left Quail look left for both colors. Then the pieces are flip-invariant. I does mean that in player A view the white Quails look inward, the black Quails outward.

I made the Tori sprites, and pushed those to pullreq. I did demagnify the Goose somewhat, as it seemed unreasonably large for such a weak piece.

To have the white Quails look towards the center, the Right Quail had to look to the left. I don't know if that should be considered confusing.

Good idea. Note That I have amended the rules of shogis included chu shogi.

I like it this way. It will make the game much more accessible. I've also added a draft file of rules that you should feel free to revise.

There are still some 'quick wins' for jocly, I'm thinking in particular of Team-Mate Chess. If you use phoenix, cobra and may be mortar sprites. It would be easier to start with.

After I know that you might use a spider for the acromentula, but if you don’t, a rhino would be easier than the eagle.

I was wondering if we could finalize the 2d and 3d visuals for team mate.

I have a feeling it's the last remaining important task for the pull request. It might be an opportunity to reconsider the choice of sprites for phoenix, cobra and acromentula, which might have also an impact on the rules as well. I can help if needed.

I was wondering if we could finalize the 2d and 3d visuals for team mate.

The following things would have to be done there:

• The 2d Cobra image would have to be improved. (There were complaints it looked too much like a tennis racket.)
• The Spider must be added to the fairy piece set. This requires:

1. Creation of a 2d Spider icon for in res/fairy/icons.
2. Adding that to the wikipedia-fairy-sprites.
3. Some hand-editing of the 3d mesh file, for shaping up the inner legs.
4. Making a visual of the 2d+3d representation for in res/rules/fairy.

• Making the team-mate view use those.
• Make 2d and 3d visuals of the team-mate setup.
• Making a new thumbnail.

I think I will start with the mesh editing.

Well, I think the existing cobra is okay. I don't know whether to look for a better one or make slight improvements to the existing one.

I'm going to try it out.

Would the existing spiders in the musketeer editor be suitable?

Here are some cobra tests:

• the same without the tongue
• another in profile
• the last one less round, I'd thicken the lines if it's worthwhile

The rightmost board-painter image looks like it would fit well within the set. But are we allowed to use it?

I will redraw the Cobra more like the opper part of the rightmost image.

I have already tweeked the 3d Spider enough to make it acceptable.

The inspiration comes from here. Same kind of drawing tutorial here.

I'd say you can take inspiration from a drawing tutorial to make your own drawings, as long as you customize them enough.

I made these SVGs:

But I am still not sure whether it wouldn't be better to only show the head+hood part. Like this:

I think I'd rather vote for the first, but frankly I'd be happy to go with the general choice because I like both.

I like both too.

Spider SVGs:

Perhaps the inner lining of the black one still needs some work. Maybe I should make it entirely black.

It looks good, but for the black one might expect the reverse color drawing for the hooks and mandibles.

yes, I would say entirely black for the black one. I think it's better. Or just the small top triangle in the head in white.

I now used the new pieces in Team-Mate Chess in the Jocly on my own website. (With an all-black Spider for the 2d.) The white Cobra might still have a little too fat outlines. I will still have to put the new sprites in the move diagrams in the rules description, and then I am ready to push it.

I also want to use Spider and Octopus in Scirocco; these occur there as promoted pieces.

Bravo you have graphic talents.

As for my understanding of the fairy set, I was wondering what the owl and flamingo would be used for.

I hadn't anything special in mind for Owl or Flamingo. I made these mainly as test cases for the Tube tool, to try out whether the newly implemented feature for tilting the rings and defining multiple tubes was workable. (The Owl used a second tube for its beak.) Up to that point I had only been able to make pieces that consisted of a single, vertical tube consisting of stacked ellipses. The Flamingo is associated with a (6,1) leap (which is pretty useless on an 8x8 board).

Another detail about minjiku: the rules don't match the sprite for the ninja. Even if you don't have time to make a 3d ninja, it would be nice to have an updated model.

I am afraid that it is more a matter of being tenacious and making long hours, than of talent.

I am still not entirely happy with the eyes drawn by the Tube tool. The mapping of the tube surface onto an 80% x 80% area of the diffuse/normalmap sometimes causes very poor resolution in one of the dimensions. Especially in designs with long legs, such as Spider or Octopus. It divides the entire height of the maps over the sum of all the lengths, while each tube can use the full width of the map, no matter how tiny the tube diameter. I already improved the situation a bit by allowing parts that need little detail to be vertically compressed, to make more room for other parts, but this doesn't help enough, and can still result in eyes being drawn with very poor vertical resolution.

What is really needed is to keep track of the ratio of the total tube length (along the surface) and the maximum circumference. If that gets extreme (say > 3), it would be better to map it to a rectangle that is 4 times higher than wide, and split that into an upper and a lower part, which are then displayed side by side to fill a square. The maps nor also always leave room for a disc in the upper-right 20% x 20% to which a cone segment can be mapped, even if no such segment is used. (And I hardly ever use it...) Without the disc the map could be structured as two side-by-side 50% x 100% areas, and even with a disc the left part could be 50% x 100%, and the right part 50% x 75%.

It would probably a bad idea to have discontinuous mapping of a single tube onto the maps, but very long tube length typically occurs because there are multiple tubes in the design. So it can roughly split the tubes into two approximately equally long sets, one going into the left part, the other in the right part. It might also be useful to make it pay attention to the diameter of the tubes. Those with very small diameter, such as the Spider legs or Octopus tentacles could be mapped into a narrow area on the right. Perhaps it would in general be better to not split the width of the map 50-50, but 70-30, mapping the narrow tubes onto the 30% half.

I will take a look at Minjiku.

There also is the issue that I amended the rules of Team-Mate Chess here on CVP with the possibility of a 'double promotion' to a pair of inverted Silver Generals. And that the Jocly implementation still uses the old rules. This would require extra code. While Team-Mate Chess so far was the only variant I did for Jocly (and therefore did first) that didn't need any code modifications.

Another detail about minjiku: the rules don't match the sprite for the ninja. Even if you don't have time to make a 3d ninja, it would be nice to have an updated model.

I now used the Gate in the game implementation as well. This is not such a bad choice, as this piece was intended to represent the Ski-Rook, the hole at the bottom symbolizing it would skip the nearest square. I used it in Scirocco for the Wagon (which is a lame Ski-Rook). And the Ninja has a sideway Ski-Rook move. The only good idea for having a dedicated easily recognizable Ninja representation was to use a shuriken, but this is not tube-like, and would have to be made entirely by hand. (But we could have used the Star...)

Unfortunately there was a lot more wrong with Minjiku Shogi. Apparently I broke the SkiGraph routine for doing ski-slides when I enhanced it for doing the Osprey. So it was doing a normal Rook move rather than a ski-slide. This must be fixed in locust-move-model.js.

And that is not all; the flying generals do not respect the ranking as promoted pieces. The ranking is part of the piece-type definition, but to make testing of it more efficient, I copy that to the piece object, so it can be easily tested by the move generator or GetAttackers function (which is called really often). But promoting a piece just alters the number of the piece type (piece.t). It does not add or change the ranking number if that new type had a ranking. This must be fixed in base-model.js, which handles the flying pieces.

And when I am at it, I might as well provide a method for requesting 'double promotion' in base-model.js as well. Perhaps I should allow specification of negative numbers in the promotion-choice arrays returned by the user-supplied promote() routine. The base model could then interpret these as their absolute value, but whenever such a promotion is applied to the board, call a user-supplied custom routine for adapting the game state. In the Minjiku case this routine could then set the ranking of the promoted piece, and in Team-Mate Chess it could add the extra promotion piece to the origin square of the move. (Problem: the legality testing, (through cbQuickApply), which ignores promotion, might reject the move if it doesn't realize the origin square is not evacuated. But I guess it even has that in common with the ranked pieces; the promoted piece might block a flying attack that the unpromoted piece would not. This will require some careful thinking.)

it's a good point to detect and be able to make this type of finish now.

It appears that the configuration of all the variants I added still needs fixing in index.js. I never realized that he AI's evaluation is controlled from there, and always just cloned the same game definition, only changing the build scripts and filenames of visuals and such. But I just found out that the weights of the various evaluation terms are controlled in the property config.model.gameOptions, in a property levelOptions.

It appears that the version I cloned was referring to config_model_gameOptions_2, which is a setting for Shatranj or mini variants, and doesn't award advance of passers very much. Most of the variants would need the settings used for classic-chess.