Comments/Ratings for a Single Item

I pushed a first draft. I can easily improve some image if necessary

yes probably best in base-view.js

I have just pushed all visuals in res/rules/fairy for the fairy-set view, of the pieces not made with Tube. As I said before, the fr-terror seems broken, and does not render for me.

And indeed, base-view.js defines the default cbMidMoveZ. Currently as the simple average of initial and final height, which on plane boards would mean sliding. I will just put a more clever default there.

I will check that in the evening

for the terror : zip initial version and zip tested on my env

I still had a file dragon2.js in the terror directory, and when I renamed that things worked again. It was totally different. I guess I tried to download the file directly from GitHub when I committed the addition of the Terror, using wget, and this appears not to work. In fact accessing GitHub from the machine I develop Jocly on seems broken; I can for instance also not get to the joclyboard page. The browser then displays a blob page without content, and a waiting symbol that lasts forever. To get joclyboard I had to download it on my Windows PC, upload it to some website, and download the tar ball from there.

[Edit] OK, so I have JoclyBoard, now what? I can run it, but it does not offer any of the new games we made. And there seems to be no documentation on it at all.

Jocly v0.9.13 is the version they published after the recent pull requests. Joclyboard, which was broken, was recently repaired and now includes this version.

We are working on the next version 0.9.14 ? Joclyboard 0.9.14 will carry it.

Now (with gulp 4 et nodejs 18) we can work on any machine even a windows desktop as long as nodejs 18 is installed.

I use joclyboard to test (I copy fresly compile dist directory in joclyboard/app/node_modules/jocly) : thmbs, visuals, the 3 html files ...

You can access the documentation via the rules, credits, about button (test from this morning).

This is what they will use for each variant before accepting the next pull request. I also believe that the html and images will be used in the next mobile application.

I don't know if it's still time to talk about that. I have a new candidate for the 2d hawk sprite: a Falco peregrinus.

@Jean-Louis : Do you like it better than the aquila. Would a rounder eye be better?
@HG : At least if it was selected. It would be better to modify the sprites file on your side. It's up to you to decide to keep it or not.

@François: Yes I like this one better than the Aquila to represent the Hawk.

A rounded eye will look less aggressive, but it's up to you, I will like both designs

You can access the documentation via the rules, credits, about button (test from this morning).

That button only gives me the documentation on the currently selected variant. But I cannot even select that variant. What I need is documentation on how to use JoclyBoard.

if you install the expected version of node on another computer  while waiting to solve the problem :

https://nodejs.org/download/release/v18.19.0/

then you could clone http://hgm.nubati.net/git/jocly.git

then npm install

Turns out there also was a cbMoveMidZ definition in grid-board-view.js, which overrules that in base-view.js. So I made the improvement there. I think the new version should almost always be satisfatory. I just have to solve one tiney problem: when a piece slides to a destination a (2,1) leap away, the animation takes an orthogonal step first, This is wrong for the Griffon. (For more distant destinations of bent sliders it takes the smallest leg first, which is always OK.) I should still implement some guidance there, as it should be clear from the move graph what the first step of the move was.

I haven't had time to test it, but all the changes have been uploaded to github.

The only info I got is from https://github.com/aclap-dev/joclyboard

Note that there is a hidden(collapsed) menu at the bottom of the page when you play to control parameters.

I haven't gone into the details yet. But I'd like a few clarifications to make sure I understand.

Does this mean that when it's finished, I won't need to implement cbMoveMidZ in the views for standard variants built from a FEN string? Or is it broader than that, e.g. all variants that use fairy-move-model?

By the way, if you think it is usefull, I can make a documentation on how to use joclyboard for dev from scratch in the latest version.

Concerning the hawk/falcon visual, I asked Jérôme for help because I couldn't manage to make a decent one on my own. Here are his suggestions. what do you think?

They are ready to use, personnally I prefer the one with round eyes.

If usefull for minjiku or any other of your shogi variant, I Can send you the fortress / tiger piece which have beautifull visuals in 3d.

Does this mean that when it's finished, I won't need to implement cbMoveMidZ in the views for standard variants built from a FEN string? Or is it broader than that, e.g. all variants that use fairy-move-model?

The new default cbMoveMidZ for grid boards should be satisfactory for any variant with pieces that do not move too strangely, no matter how it was defined or whether it includes fairy-move-model.js. The algorithm I use is

1) if the distance moved (as according to the geometry, i.e. measured in King steps) equals 1, it slides.

2) It examines the move graph of the moved piece from the given square, to find the move's destination in it.

3) If the destination is the first square on a path, jump

4) If the destination is reached through other squares, but the move is a capture, and is indicated as a screen capture: jump

5) Slide, but if the first step of the path is not orthogonal, use a kludge that I buld into the animation function in Jocly's core to request diagonal preference as tie breaker.

One of the improvements I made in the animation function is that in case of sliding it splits oblique moves into an orthogonal and a diagonal leg, and then first animates the shortest of those, and then the longer, each in half the time. This to prevent Griffons and Rhinos to blunder through other pieces. But when the two legs have equal length (as on a (2,1) move), it would normally prefer to take the orthogonal leg first (as for the Xiangqi Horse). But cbMoveMidZ can revert that by specifying an invisibly small negative hop height. This is needed to also get the Griffin move to the N squares right.

I think the algorithm would break only if a piece has multiple ways to get to a square.

If usefull for minjiku or any other of your shogi variant, I Can send you the fortress / tiger piece which have beautifull visuals in 3d.

Apart from Minjiku Shogi (which does not feature a Tiger) all Shogi variants use kanji tiles. It would be nice to have a 2d Tiger, though, for the Chu Shogi (and later Tenjiku Shogi) Blind Tiger. I now use a Buffalo for that...

That's a nice present for Jocly.

This means we can test it simply by commenting cbMoveMidZ in a view like bigorra-view.js, which contains almost all the pieces.

right?

This means we can test it simply by commenting cbMoveMidZ in a view like bigorra-view.js, which contains almost all the pieces.

Exactly. This is what I did for Makromachy, which also has a very diverse set of pieces, to test it. I just pushed the thus debugged version.

I am having some second thoughts about this old patch of the animation routine. This was in base-view.js, btw, so only affecting chess variants. But this code is also used by hexagonal variants, or variants with irregular board topologies. There the way I use to detect oblique slides, and break them up into on-ray legs, would not work at all, and probably break things. The original default cbMoveMidZ at this level would always slide. Only when you use a grid board this would be overruled by one that jumps for all obliques, and slides otherwise (and which I now replaced by a more advanced one).

So this animation patch in its current form is probably not acceptable for Jocly in general. The animation routine consults cbMoveMidZ to calculate the trajectory along which it will move the piece during animation. So a solution would be to only break up the trajectory into two legs when cbMoveMidZ requests this, as each board topology would have its own cbMoveMidZ. So the latter would then not only be used to define the Z coordinate half-way, but also the (x,y) coordinates.

Since the (x,y) path of a move that hops over other pieces is irrelevant (and thus can be the normal straight line it is now), we could use negative value of the number returned by cbMoveMidZ to specify the intermediate for a slide. (I cannot imagine you would really need jumps with negative height...) E.g. minus the number of the square over which the slide should go, minus 1. Then a jump height of 0 would indicate a normal slide, as the original use of cbMoveMidZ intended. The default cbMoveMidZ for the grid board would then recognize oblique slides, and determoine the intermediate square itself. I guess for the moment it would be good enough to just take the first square on the path as the intermediate. That would work for Griffon, Rhino and Osprey.

It would even work somewhat for the Grant Acedrex Unicorno (which would squeeze itself between the pieces shielding it from its first target). It might even be nicer if in that case (i.e. a path starting on a non-adjacent square) would be animated as a jump in the first leg, followed by a slide. That would also be good for the Osprey. The animation routine would then have to determine a default height for that, though, as the value returned by cbMoveMidZ would indicate the horizontal intermediate. Perhaps we should make it possible for cbMoveMidZ to return an array, with both a height and an intermediate.

I have to say I'm going to defer to your analysis because, apart from distinguishing irregular board from regular board, I wouldn't really know how to go about it.

@HG and François: Congratulation for your work on Jocly!

A remark on the 2D icon for the Snake. It is a cobra's head seen from face. But when reduced at the size on an icon on a board, it is not straightforward that it is a snake. It looks like a sort of racket or a balloon or... Well. Why don't you use the icon which is used on Alfaerie (maybe drawn by HG?) which is much clear imo?

It might be a bit early to test, but I thought it might help to get some initial feedback.

Jean-Louis helped us to check the moves on bigorra without custom cbMoveMidZ in the view:

Snake: When the Snake does a non jumping "Knight" move (2,1) to its right, and only in this case, it starts by the diagonal step prior to the vertical one, which is wrong.

Rhino: sometimes, it starts also by the diagonal step when making a non jumping Knight move. But not always, it depends on the square it starts! (For example Black Rhino on j11 to go on k9 or k13)

Camel: it's sliding, not jumping Sorceress,

Canon: sliding for capturing instead of leaping (Archer is correct)

Marshall: does the opposite: slide as N and leap as R

By the way, I posted the hawk sprites may be a bit too early. It is better to retrieve wikipedia-fairy-sprites.png to avoid a clash on the binary file before the next pull command.

I agree the Snake icon is not very good. (My fault, I made it.) The Alfaerie one is much better. I was hesitant to grab Alfaerie icons, though, as the piece set Jocly uses is really CBurnett.

Snake: When the Snake does a non jumping "Knight" move (2,1) to its right, and only in this case, it starts by the diagonal step prior to the vertical one, which is wrong.

I noticed that too. I made some changes now (and already pushed those), both to the cbMoveMidZ default for grid boards, and the animation routine that uses it in base-view.js. This should cure any problems the previous animation patch had with hex boards. (Assuming no one would use jump heights -1 or -2 there.) And as far as I could see it now does all Griffon/Ship and Rhino/Snake moves correctly. As to the Osprey and the Unicorno there still is a problem that it makes the first leg a slide too, even though it really is a jump. In both cases over the Wazir squares.

It is a bit hard to let cbMoveMidZ tell the animation routine that the first leg is a (possibly oblique) jump, as the animation works purely in pixel coordinates, not in terms of board squares. Perhaps I should allow fractions on the -1 or -2 that request bent trajectories, for indicating at fraction of the long side of the rectangle containing the move would be the start of the animation, and possibly jump there if that is not immediate. E.g. a Snake (2,3) move would require a hop height -2 for ordering an orthogonal-first bent trajectory (so via (0,1)). But if it was a Unicorno using a hop height -2.666 could be taken to mean that the slide starts at 2/3 of the 3, i.e. at (1,2), and (ideally) that it should first jump there.

I redeployed your change.

@Jean-Louis : do you have time to take a look?