Comments/Ratings for a Single Item

Do you have a way to reactivate your git server, I haven't retrieved the patch from base-model.js yet.

your git server seems stopped

I did push the required patch of base-model.js now, so the current version should be fully operational.

Next I will make a similar evaluation function for Chu Shogi.

It's true that Jocly is not very strong, which is not necessarily a problem for introducing games to the general public. They need a game that is intuitive, beautiful and against which they can hope to win without too much research.

To assess relevance you need to select "strong" level to have realistic results. One day the jocly UI will perhaps serve as a basis UI for a more specialized application for chess variants.

Are you going to continue to improve the evaluations for your shogivars? Do I have to wait to push the latest changes to scirocco?

Yesterday I forgot to push the patch of base-model.js that Scirocco needs to work; for evaluating the promotability it needs the total army strength. Rather than having it calculate that again, I now pass it from the standard chessbase Evaluate function, (which already calculated it, but then only passes the difference of the two armies in evalValues), as the 4th parameter to the dedicated evaluate().

Perhaps everything that Evaluate() puts so much effort in calculating (by looping over all pieces) should be put into a single object, rather than just variables private to Evaluate(), so that the dedicated evaluate() can use that directly by passing it this object. Rather than having to rely on the often useles combinations that are made of the results and passed as evalValues.

BTW, I was a bit shocked how weak the Jocly AI is. I tried a game of Scirocco against the Interactive Diagram, with Jocly on level Medium (~10 sec?), and the I.D. at 2.5 ply (~0.1sec), and even though the I.D. did some trades I considered bad (but were good according to the piece values it guestimated) it massacred Jocly (until it finally lost with a huge advantage by not knowing that repetition is forbidden). It appears that Jocly at this level still overlooks quite elementary tactics, such as the only protector of a piece being traded away so the piece hangs, or by relying on protection from a piece that is soft-pinned.

I now have added a promotability evaluation to Scirocco that doesn't seem too idiotic. The idea is that the promotion gain of each piece is multiplied with the estimated probability the piece will promote. Sliders then get 90% of that value added to their piece value, while for leapers it ranges from 20-90% depending on how far they are from the zone. (Measured  in the difficulty to go there, considering the size of their leap, but also the number of forward moves with such a leap; a Dababba would be discounted more than an Alfil in the same location.)

The probability estimate assumes there is a certain minimum army strength required to defend the zone, and that you first have to reduce the opponent army to that level by equal trading before you can promote. What you have left at that point will promote.

This doesn't account for the fact that some pieces gain more on promotion than others, and that you will try to selectively preserve those in the unpromoted-trading phase. Because the opponent of course will try to preferentially trade your good promoters away, I am not usre how successful such a strategy can be on average.

Another subtlety is that there are fast promoters (sliders), which will start promoting as soon as the entire zone cannot be defended, and slow promoters (leapers), who will take some time to get there even if unobstructed, and can much easier be defended against because of their low mobilty. You would only have to defend the entrance of the zone, and can often even prevent they reach the zone by meeting them far before they get there with your own leapers.

In a contest where one side has fast promoters and the other slow ones, of equal total value and gaining equally on promotion, the player with the fast promoters would promote those before the slow ones can promote, and then try to trade those according to their increased value for the yet unpromoted opponent pieces, leaving him a surplus after the slow ones are annihilated. This is currently not yet accounted for. In Scirocco it might not be that important, as there are very few sliders in the initial setup there. (And the Scirocco's don't have such a strong promotion.) But it would be for Chu Shogi.

Yes, I am already working on the others. For some the custom evaluation was entirely wrong. (E.g. in Elven Chess the testing for insufficient mating material made no sense, as by using fairy-piece-model all type numbers had changed. And the bonus for advance Pawns did not take into account that the promotion zone was 3 ranks rather than 1, and was only awarding the bonus when the Pawns were already in the zone.)

And Aanca is indeed Acromentula. I thought I had replaced that everywhere, but apparently I missed some.

[Edit] I have now fixed the obvious evaluation errors in my non-Shogi variants. But:

• Makromachy has no dedicated evaluation at all. So it won't encourage Pawns to advance, no matter what set of eval parameters it uses, and it won't recognize insufficient mating material. (But it is so large that the latter might not matter.)
• Scirocco needs to encourage many other pieces than Pawns to advance towards the zone. Especially the very slow ones, such as Ferz, Wazir, Steward and Commoner, but to a lesser extent also the range-2 leapers Alfil, Dababbah, Stork, Goat and the enhanced Knights.
• That holds also for other Shogi variants without drops. (Scirocco is a sort of Chess-Shogi hybrid.)
• Minjiku Shogi currently also has no dedicated evaluation.
• Chu Shogi still has the unmodifed Classic Chess evaluation, basing its 'insufficiant mating material' judgement on the idea that piece types 4 and 5 are Knight and Bishop, and Pawns promote on last rank only.
• Shogi, Tori Shogi and mini-Shogi have empty evaluation functions. They would really need some King-Safety term to play sensibly.

well done, that changes everything. Do you want to change gameOptions in index.js on games like elven, spartan, werewolf, scirocco? even makromachy, minjiku?

The rules refer to aanca, is it the acromentula?

I implemented pair-promotion to Brutes in Team-Mate Chess, and updated the rule description accordingly. I also improves the evaluation, making it recognize insufficient material draws were all remaing pieces are color bound and on the same shade. I think that should finish it.

The name doesn't really speak for itself. Don't hesitate to make any necessary changes, maybe for the shako too.

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.

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

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

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

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

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.

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

Spider SVGs:

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

I like both too.

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 made these SVGs:

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