Comments/Ratings for a Single Item

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.

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?

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.

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.

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.

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?

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.

your git server seems stopped

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

Well, this is a bit tricky, since the webspace I use there is not really my own, but is hosted by someone I cooperated with long ago for the development of XBoard. And the problem appears to be that someone (not that person, so presumably someone from the hosting company itself with root access) renamed the gitweb.cgi script to 'gitweb.cgi_disabled_by_HL'. Now I could of course rename it back, but I suppose they intervened with the private files of their customers for a good reason (probably to do with security), and don't want to anger the hosting company and create trouble for the person that allows me to use his webspace. So I am still trying to figure out what to do that would keep everybody happy.

BTW, that gitweb.cgi is no longer there should not prevent you from pulling from the repository.

So I am still trying to figure out what to do that would keep everybody happy.

Suggestion: Contact the admins at the hosting company, and ask. Barring anything else (meaning, if you don't get a reply after two tries), leave the "disabled" cgi in place but copy it to a new regular one.

Indeed, Pulling still works!

It might be interesting to add a 2d sprite for the berolina pawn since there's a 3d representation in the fairy set.

It could be inspired by alfaery sometimes like that

or may be a more pointed pawn to go with the 3d image.

I made a second attempt to find a 2d representation for the berolina pawn with less white on the black pawn.

I'd like to add it if the result is acceptable because i find it preferable to have a different representation instead of the ordinary pawn if possible.

Does Jocly currently support any variant that uses Berolina Pawns at all? The 3d realization was made mostly as a test case for the initial version of the Tube tool (it is a purely cylindrical design). In that sense the committing of it was a bit premature, like for the Flamingo.

The design you have here looks a lot like the Alfaerie design, which is a variation on the Alfaerie normal Pawn. But the Wikipedia set uses an entirely different Pawn design. If we want to add new Pawn types, I think we should use that as basis.

Spartan Chess is an implemented variant that uses a different Pawn type, for the Spartans. These 'Hoplits' are very close to a Berolina Pawn, but not exactly equal, because their initial double push can jump, and isn't subject to e.p. capture. They do have their own 3d image, (a Pawn modified to carry a lance), but also use the normal Pawn image in 2d. If we want to distinguish the Pawns in 2d it seems more urgent to do find a symbol for those. In the WinBoard implementation I use the Lance pictogram for those. We could also do that in Jocly (now that we added the Lance). But it would still not have its own picto-sprite in that case. (But who would want to use a Lance and a Hoplit in the same variant...)

I am not sure we should go for a double-head design in 2d if we did not also do that in 3d. An alternative would be to write a V on their breast, to symbolize their non-capturing move.

And what about the Asian Pawn, for the western skins of the Shogi variants? These now also use the normal Pawn symbol.

Let's just say that I thought it would be interesting to complete the fairyset, but if the idea doesn't meet with unanimous approval, we can think about it later.

As for spartan, it's a point of detail, since the set is already well developed, but it would probably be better to have a V or a spike on the top of the black pawn to distinguish them from the white.

In short, I'm not doing anything on pullreq, I'm just testing on my personal branch.

What do you think about switching to the Lance picto-sprite for the Hoplit in Spartan Chess? Then it would have a different symbol from the FIDE Pawns. And I doubt that any western variant will ever want to use a piece that moves as the Shogi Lance. (But they might of course want to use it for a piece with another move for which there is no dedicated representation available.)

Yes the lance might be suitable.

I'd also wondered about the captain, and you may consider using the machine that is used with the same movements in other variants. But the choice of the lighthouse is perhaps aesthetic, as its 3d representation is more successful or better proportioned than the machine.

I have uploaded François Houdebert's files for the Hectochess implementation to the site. I guess now it's just a matter of waiting for the server cache to clear, unless I need to do something else when uploadnig a new Jocly game to the site.

@Adam: you wrote "uploadnig a new Jocly game to the site." Which site are you talking about? The one linked to this comment brings to a page where the last update is from 2023. And that page has a hyperlink on "Jocly" word which is broken.

Where can your work on Jocly with François, HG, can be found?

Thanks

You also have to add a line to /play/jocly/dist/browser/jocly-allgames.js to make Jocly notice the files that you placed in /play/jocly/dist/browser/games/chessbase/ . I think Fergus exempted the Jocly files from CloudFlare caching, so you should see new games immediately after flushing your browser cache. To do that I sometimes have to access the modified .js files (including jocly-allgames.js) directly with the browser.

Unfortunately the wikipedia-fairy-sprites.png file on CVP is not entirely compatible with the one that is now in the source repository.

Where can your work on Jocly with François, HG, can be found?

That depends on what exactly you want. The source code is in my on-line git repository, but it is currently not possible to view that interactively on line because the hosting company disabled the viewer for that ('GtitWeb'), and I haven't had time to fix that. It is still possible to pull from the repository with 'git', to view the source code locally. And I suppose François has a mirror of it on GitHub.

If you want to see a running install featuring the newly added games, you can use the one on CVP (just select any of the dedicated variant links on the Jocly overview page, and then click 'other jocly games' at the bottom right to select a game), or the one on my website, which are old Jocly installs that I hacked to add some variants. I suppose that François has put up a version directly compiled from the most recent source code somewhere.

You also have to add a line to /play/jocly/dist/browser/jocly-allgames.js to make Jocly notice the files that you placed in /play/jocly/dist/browser/games/chessbase/.

I've done that. It shows up on the Other Jocly games panel, but when I try to load it, it doesn't work. I get the following error:

hectochess-model.js:257 Uncaught (in promise) TypeError: JocGame.LetsTwist is not a function
    at ZobristInit (hectochess-model.js:257:20)
    at Model.Game.InitGame (hectochess-model.js:354:3)
    at JocGame.GameInitGame (jocly.game.js:3:7385)
    at JocGame.Init (jocly.game.js:3:1572)
    at e (jocly.core.js:1:1233)
    at eval (jocly.core.js:1:2511)

Apparently the jocly.game.js was still the original one from 2017. The addition of LetsTwist (to make the Mersenne Twister random generator available to the game-specific code) is the only modification I ever made in the Jocly core. I have now replaced that file with the one on my website; this should make it work.