Comments/Ratings for a Single Item

If you want to use the trident and save some time : you can get the sprites here.

Changes :

-remove red dot between axes

-use trident instead of whale and white horse

-remove few pixels below the white fire demon

I am not sure the trident should be used for both the Whale and White Horse. It would suggest that it points in the direction in which it moves, but for black this would just be the opposit. And if you pair the flipped versions for the same type, it would look all wrong when viewed from player B. I am not unhappy with the diving-Whale image; it also suggests something that goes down, without suggesting too much that 'down' would be a direction relative to the symbol. An upside-down symbol would strongly suggest the reason for displaying it in an unnatural way is that you want to indicate a direction with it.

I 'parked' the dot near the Axe for copy-pasting it onto pieces that needed it; the Axe is not used in the set. But the idea was indeed to remove it from the final set. I had not noticed the stray pixels near the Fire Demon.

I'm sharing some sprite tests for a charioteer or lateral and vertical soldiers, I don't know if we still need them because we already have a satisfactory result :

The rightmost chariot mightbe good for the Reverse Chariot. I admit it is more remaniscent of the name than of the move, but in this case that is not so important. Lance and Reverse Chariot are practically useless people, and players will quickly learn to simply ignore what is in the edge files, without paying much attention to how it looks. It is mostly the location on the board that identifies it.

tenjiku-set-view.js should probably use :

res/shogi/tenjiku-shogi-picto-sprites.png

instead of

/res/fairy/tenjiku-shogi-picto-sprites.png

?

concerning tenjiku, should the fire demon slide vertically? In wikipedia I have the impression that it's horizontally.

In Modern Tenjiku Shogi it slides vertically. This is another contested rule issue. The first western publication was by George Hodge's TSA ("The Shogi Association") and gave a vertical slide. IIRC it seems that only two historic sources are known that describe Tenjiku Shogi, and that one of those contains an inconsistency between the text and the accompanying image. (The text says vertical, the image and the other source consistenly say horizontal.) So it is 3 vs 1, as well as that it seems more likely to err in a text than in a picture. The best argument for a vertical move seems to be that "there could be yet undiscovered sources that also state it moves vertically".

But the modern rules do not claim to be the historic rules. I used the modern rules for the Jocly implementation so it could participate in the correspondence championship.

tenjiku-set-view.js should probably use :

res/shogi/tenjiku-shogi-picto-sprites.png

instead of

/res/fairy/tenjiku-shogi-picto-sprites.png

?

Well, it already worked for Chu Shogi, didn't it? So how could it be wrong?

there was a refactoring on the last commit, wasn't there?

src/games/chessbase/res/fairy/tenjiku-shogi-picto-sprites.png     [deleted file]

Impact on tenjiku-set-view.js ?

thank you for the clarification I'm still learning...

Indeed, that doesn't seem correct. I moved the file to */res/shogi/tenjiku-shogi-picto-sprites.png, and the tenjiku-set-view.js should have used the new link. I guess it worked in my tests because the old file was still there.

I believe that the view-as bug comes from

jocly/examples/browser/js/control.js line 236

I think adding a test like could solve it. I didn’t dare doing it.

if(viewAs===undefined || Object.is(viewAs, null) || viewAs==="null")
      viewAs="player-a";

It probably comes from string like "xxxx.view-as": "null" in window.localStorage

I played Tenjiku Shogi and I encountered the following message : "Undeclared Zobrist array index -1 as param board"

You might reproduce it with the following game after attacking the black phoenix with the white fire demon :

Computer(B) level : strong

I have alo seen that message, but only in the state where the view is upside-down. It then also couldn't read its book. Fixing the view made the problem disappear.

I think there's something odd about this particular case, because after the phoenix is taken, the black king is threatened.
This doesn't stop the black fire demon from attacking elsewhere and threatening the white king over the kirin. The fire demon doesn't have a flying diagonal, does he?
It's not the view-as bug, if you look at the local store ([f12]  then application tab in chromium), everything's normal.

I have no idea how such a game can be loaded into Jocly. The Load button doesn't seem to work; it gives me a file-browse window, but doesn't see any files.

if you right click on this link + select "save target as" : you shoukd be able to get the file tenjiku-chess-demon2phoenix.json on your disk

then select it from the load button and your browser should be able to initialize the game.

OK, I see why it didn't work: Instead of downloading the file I had copy-pasted the text on the into Notepad, and saved that. But then I had to pick the filename myself. In the file-browse dialog that opens upon pressing Load, the file-type pulldown was by default set for *.js files. So I saved it with .js extension. But then I never saw the file, only folders.

Turns out the pulldown did not say .js, but .json, but that the "on" part was clipped off because of the button width. When it had .json extension as in the downloaded one, I had no trouble loading it into Jocly. I still haven't figured out how I could view the entire game, other than playing it in reverse through takebacks. But at least I can see the final position where the trouble manifests itself.

I think the problem is that Jocly's test for being in check (through base-model's cbCollectAttackers function) cannot see attacks through burning or area moves. So it happily plays on in this checkmated position. Which in the look-head by the AI of course leads to the King being captured. The Jocly code chokes on that, because it assumes that a King is always present. It keeps track of where it moves, but that tracking is left at the square where it was last seen before it got captured. But that square is then empty (code -1 on the board), and when it tries to update the hash key for a piece of that type it gets out of bounds in the Zobrist table, as -1 is not a valid piece type, so that no keys were defined for it.

The playing-on seems acceptable here, as officially Tenjiku games do not end by checkmate but by King capture. (Purists might complain that with normal checkmates, not involving burning or area moves, which Jocly does recognize, it really terminates the game one move too early.) That it then crashes is of course not acceptable. The pullreq branch contains a commit that fixes that; the evaluation in base-model now tests for presence of the King, and considers its absence a game-terminating condition as well. That prevents further processing of positions without King, and thus the crash. But of course the version you are playing here is not based on the pullreq branch. The tenjiku-chess-model.js still contains the original base-model.js. I could of course hack the patch for detecting King absence in there.

This touches on an issue that has bugged me from the beginning; the Jocly AI really is an extremely inefficient search engine, as far as chess engines go. Michel coding skills in JavaScript are uncountably many leagues above mine, but he obviously is not an engine programmer. The largest flaw is that in the search he generates legal moves only. This has enormous computational cost, as he does it by playing all pseudo-legal moves one by one, then looking with cbGetAttackers whether the King is under attack, and taking the move back. And then delete the move if it was illegal.

The point is that normally only a very small fraction of the moves puts your own King in check. So most of the time the test for this was a waste of time; the move is legal and you have to try it anyway to get its score. Almost all chess engines therefore use pseudo-legal moves in their search; if they occasionally try an illegal move the opponent will see he can capture the King, which gets maximum score, so that the illegal move will have maximum negative score, and would be discarded. On most moves this would not happen, and you would have saved the time for separately testing whether the move was legal; even in cases where the move was illegal it is a question of whether detecting that by letting the oponent generate all his pseudo-legal moves, than by using the dedicated check test.

Now the problem is that this cbGetAttackers function can get horrendously complex in a game with unconventional pieces. It works by reversely tracing all paths in the move graphs of all pieces that visit the square, to see if it finds the corresponding piece at the origin of that path. To this end it initializes a ThreatGraph, which combines these reverse paths into a tree (so that coinciding parts just before they hit the King only have to be traversed once). If you are dealing with orthodox Chess there might be some merit in this; you only have to deal with Knight jumps and Queen slides, the latter quickly finding an obstacle in their path when you step through them from the King, during most of the game. But even then the case for the Knight is dubious: you would have to test 8 squares around the King for Knight presence. The alternative method of just generating all opponent moves would make you generate 8 moves for each Knight, to test for King presence. If the opponent has two Knights, that is indeed twice as much work. But if he has none...

The point, however, is that when the variety of moves in the variant gets larger, this threat graph gets unweildly large. If Xiangqi Cannons participate, you cannot stop tracing the reverse path at the first obstacle, but will have to look beyond it for Cannons. If Tenjiku-style jumping generals participate, you have to trace the Queen moves all the way to the board edge. If Griffons participate you have to follow paths around corners. Camels, Zebras, Antelopes each give you 8 extra squares around the King to test. Before you know it, you have to test almost any square on the board for presence of a particular piece. And when you don't keep track of which pieces are stil present, (as Jocly doesn't), you have to keep doing that for the entire game, even if the pieces that could make these strange moves are long gone.

I think the Jocly AI would benefit enormously by just abandoning this legality testing, and let it search until King capture, the huge value assigned to the King taking care of the illegal moves never being preferred. For testing the legality of the user's move it would remain essential to do it, though. So there should be a way to let cbGenerateMoves know whether it is generating for the AI's search, or for highlighting user input moves; in AI mode it could then just return the cbGeneratePseudoLegalMoves result, and do away with this costly cbQuickApply / cbGetAttackers / cbQuickUnapply loop.

Another silly design characteristic is that the material scoring in the evaluation fuction is done by looping over the entire board to add up the value of all pieces it finds there. This is something that can very cheaply be updated incrementaly, by just subtracting the value of pieces that get captured in cbApplyMove. It already does such incremental updating for the hash key zSign, so why not for the material score? Same for counting pieces of each type. This really makes Evaluate orders of magnitude slower than it could be.

Ummm, I hacked in the king-capture test, but it doesn't seem to prevent the problem. And testing also showed a basic flaw of combining imperfect legality testing with king-capture termination: when you put the AI in check or mate through an undetected move, it would still think that capturing the King is illegal when it counter-checks you with a check that is detected.

This also confronted me with what you had already seen: it tries to keep me in perpetual check with the Demon. But it appears to think the Demon has jump-capturing ability. That it could check my King through the Kirin didn't strike me as strange, as it can capture the Kirin and burn teh King in the process. But when I evade that check with K-i2, it thinks the Demon can check me from d7, through a Pawn and Lion!

This is weird. For Tenjiku I hacked special code into cbGetAttackers to see the jump attacks: it scans the Queen rays from the given square (using the GG graph), and looks whether it encounters pieces that have a 'rank' in the jumpers[] array. This array is not supposed to specify a rank for the FD or +WB, though.

thanks for the explanation, I had a feeling it wouldn't be easy to solve.

It is even stranger than I thought. It thinks the Demon attacks h1 from d5, but not from e4, c6 or b7. After K-i2 it thinks the Demon attacks it from d7, but not from b8, and not even from f5, where it has a direct line of sight. And from d7 it thinks Q-h3 or even Ln-h3 will block the check; from e6 it thinks it is checks that cannot be blocked. This is all very erratic.

Also strange is that after loading the game, it highlights thw white pieces. But also the black +WB, and when I click it, it thinks it moves like a Pawn! I must do TakeBack and replay the WB promotion to make it understand the +WB is not a white Pawn.

OK, I figured it out. The problem was in the graph of the Demon, created by a modified version of cbLongRangeGraph. In this version you could ask to suppress FLAG_CAPTURE and FLAG_MOVE in the first N moves of a slide, and the Demon used this for N=3 to prevent double generation of moves that would already be generated by the AreaMove routine.

But unlike what I thought at the time, clearing those flags would leave it unblockable at those squares, w.r.t. conversion to the ThreatGraph. So the Demon effectively was a super-ski-slider, which would directly jump to the 4th square  in any direction, and slide from there. What is needed to make it blockable is set FLAG_STOP on those squares. I do that now, and the problem disappeared.

The problem that after game loading it highlights the black +WB with the white pieces still exists.

The problem that it thinks it can defend against a King capture by perpetual checking with recognized checks also remains. But in this position that was not possible. So it doesn't check, which allows me to capture his King with a move it thinks legal, and the missing-king patch then makes it conceed that "A wins".

I guess the best solution for the "king capture by legal move only" problem would be to declare all pseudo-legal moves legal in Tenjiku Shogi. I can do that in the version on my website by suppressing the legality-test loop in cbGenerateMoves , and copy the moves from cbGeneratePseudoLegalMoves to this.mMoves entirely. (That should also speed up the AI enormously.) For the pullreq branch it might be good to introduce a parameter in base-model that the user could set in its game definition to switch the search to king-capture mode.

That would still leave the problem for variants that do terminate on checkmate, but generate special moves that cbGetAttackers cannot see. The Ultima Withdrawer was such a piece; it attacks adjacent squares, but only if there is room in the opposit direction to move.

[Edit] I now made it such that moves that capture the King are exempted from legality testing. That makes counter-checking pointless. As a side catch I also fixed the move of the black Iron General, which had its diagonal moves in the opposit direction.

I'm glad that this complicated problem has been solved. It seems a good idea to add a parameter in base-model to set to switch the search to king-capture mode in the pullreq branch.

I did some experiments with the search mode in Tenjiku Shogi. The test position was basically that after 1.P-j6 (except that I first did two Leopard moves to get it out of book). At level 'medium' it would normally see the mate threat, and play 1... SE-n11.

First I disabled legality testing altogether. Then it doesn't defend against the mate threat, and even after 2.VGo10# it plays on, and only conceeds after I capture the King. Not good. This could have been expected; King capture occurs two ply after checkmate, and GenerateMoves already tests for it when it discovers there are no legal moves. I moved the testing for missing King from the Evaluation (which would make it to be discovered only after the King capture was played) to the move generation, where it declares a win if a move is generated that captures a King. That did still not make it see the mate threat at this level.

Now chess games in general are not won because you see checkmate from a larger distance, but by gaining so much material that the opponent cannot see checkmate no matter how deep he searches, as he is too weak to inflict it, so that sooner or later you will stumble into one. But Tenjiku Shogi is sort of an exception to this, with these jumping generals that threaten mate even on a full board.

So I tried something else: test the pseudo-legal moves for legality until you find a legal one, then accept all others without testing. This way you will always discover it when you are (check or stale)mated. But in the common case (where you are not, and not even in check) the very first move you generate is already very likely legal, so that you on average will hardly subject more than a single move to this check test.

Unfortunately it still did not defend against the mate threat after this. But when I execute the mate though 2.VG-10o#, it claims a draw. Turns out that in the place where it tries the moves with cbQuickApply, to test them for legality, it also tests whether those that turn out to be legal do deliver check. It stores that in the move, and when the move is played to create a new position, it takes its in-check info from there. So by skipping this for most moves it would not know anymore that it is in check, and thus judges that the situation without legal moves is a stalemate. (And apparently I forgot to let it know that in Tenjuku stalemate is a win too.) It is thus hardly amazing that it doesn't worry about that; draw with gote is a good result.

So in the code for deriving the game result when there are zero legal moves I let it do a check test if the in-check status was still undefined. That solved it: it plays 1... SE-n11 again.

But that it doesn't check all moves for legality means that it will also highlight the illegal moves at game level, except when by coincidence it was the first move that was generated (or in any case not preceded by any legal moves). This allows you to step into check, or stay in check. (Unless you are already checkmated through moves that its check test understands. Then it declares game end and you cannot move anything at all.) In Tenjiku Shogi this would of course be allowed, and improves the uniformity of the highlighting, as you were already allowed to step into checks that the check test was blind to (burning and capture by an area move).

What is a bit odd is that when you do step into check, it declares game end, without actually performing the King capture (or allowing you to do it, in case you win).