Comments by HGMuller

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.

The spellZone is defined as a bitmap held in an integer, so the number of squares is limited. The N option was in fact already extra, since I didn't know any variant that would need anything else than K. or a subset thereoff. In absence of variants that actually use it, I would not extend it. (And that doesn't count variants that are intentionally designed to break the limit, as that could be done for any limit...)

Spells do not affect the piece that casts them, and I don't see why they should. The piece is always in the spell zone, so whatever the spell does simply becomes a piece property.

Ah yes, I apparently missed some of the print statements I put in for debugging when removing those, after the problem suddenly ceased to exist before I found out what it was. In short games like I tested on this is not noticeable.

I removed them now.

I have now overruled the piece values that the Diagram itself would guestimate, and set N=150, B=100, R=50, Q=-10. The Diagram does not yet apply that consistently, though, as it does not take the value of the pieces it unloads into account. I might fix that later.

Indeed. The Ko Nets are problematic, as are other Gorgon type of pieces. Because the don't really cast the spell as a fixed zone, but as a sliding move that can be blocked. So the zone doesn't only change on their own move, which is what the Diagram's implementation of spellZone assumes. The Gorgon effect is similar to the rule that you cannot castle out of check, which is again related to e.p. capture; one could say that the latter is en depart capture. Castling creates e.p. rights not only on the squares the King passed through, but also on the square it came from. And any piece type can use those rights, not just Pawn. This is how the Diagram's AI implements the ban on castling out of check; it makes it look like exposing the King to (e.p.) capture.

Gorgons could be implemented in a similar way, by adopting the rule that a Gorgon move to the origin of the preceding move must be scored as an immediate win. The square of origin becomes a kind of e.p. square for exclusive use by Gorgons, while a thus captured piece counts as absolute royal. I guess this could be specified in the captureMatrix as a new symbol, so that you could specify in a type-selective way which pieces are paralyzed by a Gorgon. An alternative is adding 'Gorgon capture' as a new mode to XBetza.

As to the spell zone: pieces are always immune to thir own spell, specifying a zone of only the square they stand on would have no effect. How would you imagine a piece that (passively) burns itself? Or freezes itself, or brakes itself, or protects itself? The latter three already exist as pieces without moves, steppers and iron pieces.

So, adding another convention to be learnt just to save 1 letter is arguable.

This is certainly a valid concern, and I would not have done it just for saving one letter. But, as Bob already showed, it can save a lot more in descriptions of multi-leg moves through the bracket notation. There it was a constant annoyance that trajectories involving larger leaps had to be split up in separate orthogonal and a diagonal parts. E.g. the compound of Griffon and Manticore can be written as [K?fsQ], but the compound of Osprey and its pseudo-rotated counterpart A-then-R would have to be written as [D?fsB][A?fsR] this can now become [S?fsQ]. So these new shorthands are mainly intended for use in the bracket notation, I would not recommend writing the Squirrel as NS or the Lion as KNS. The A was already taken, so I could not really find a natural abbreviation for the Alibaba move; not so many letters are left anyway, and it was pure coincidence that there was one that could be associated with a verbal description that at least has some mnemonic value. That this then also worked for the GH compound, in exactly the same way, was in fact an incredible coincidence, which I could not resist. (Although I don't think any piece that is already in use would actually need this.)

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.

Through the Play-Test Applet?

Indeed, 'Spider' would be a very fitting alternative name for the Alibaba. So AD = S = Spider and GH = T = Tarantula.

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.

Basically anywhere theat is not inside the definition of another array. Just adding it as a line at the bottom should do.

If you want help in making a preset, it would be useful to post a link to it...

I had completely forgotten this is possible. But looking at the code it seems intentional. It must be from before I started to (somewhat) support bracket notation.

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

That could actually be unintended.

It must be in the Pre-Game section, not the Pre-Move section. It was just that the unset should not have been within the if-clause, but done unconditionally.

Yes, you are right, 'ring' might be confusing. Better to say 'second square'.

I had a similar problem with the Black Soldiers in the one game I played. I was going to take tomorrow to ask H.G. to take a look at what's up with it.

This appears to be a bug in the betza.js script itself, albeit in something it does only for the benefit of generating GAME code: when it reads the XBetza descripttors it determines whether a piece is symmetric or not, and stores that info in an array. The PTA uses that array to see if it should create different versions of the piece for white and black in the legdefs move table.

The bug was that it would only base this on the last atom in the XBetza descriptor. For the Sergeant this was sW, which is symmetric. So it decided white and black could use the same Sergeant. Which for black of course means it now moves in teh wrong direction. I now changed it such that it pays attention to the symmetry of all atoms in the descriptor, and if one of those is asymmetric, it will create an extra flipped version for black.

After refreshing the browser cache the PTA should now generate the correct GAME code.

I am not sure what isn't resolved in that respect. if I capture the Phoenix, at level Medium Jocly plays FD-e4 (which checks by burning), and prints "A wins", which should be considered a resign. This behavior is different from what it was, but not wrong. It is a consequence of that it now detects the king capture earlier, when it generates the moves for white after it moved his Demon, rather than detecting it only afterl the King capture has been played (by the user).

I think this is acceptable behavior in games where you win by King capture, although it might be considered a bit peculiar that it plays a move together with the resign.

What still isn't resolved is that after loading the game in Self/Self mode, the black Demon is highlighted in white's turn, and that white can move it as if it is a Pawn.

Oh, and there are no separate sprites for unpromotable Falcon and Eagle. I forgot those, because in Chu Shogi it isn't in issue.

The promotion zone in the Diagram is always the furthest N ranks. So if you set it to 9 on a 9x9 board it would be the entire board. If you want just your own back-rank you must use a morph for the promoting piece, with which you can define any irregular promotion zone. Like

morph=///////*

on an 8x8 board (7 ranks without promotion, one with the normal choice, counting from the furthest rank). Add this after the Pawn line of the Diagram, and then paste it back into the PTA, and generate GAME code.

[Edit] On second thought, morphing with choice might not be implemented yet in the GAME code. In that case I am not sure what is best, also because I don't know what exactly you want.

I vote against that. For one, I consider it dubious practice to 'migrate' accounts. And I don't think it is a better idea at all; in fact I think people should post under their real name here. There should be better ways to 'link' your e-mail address. (Whatever that may mean...)