Comments by HGMuller

@HG: it is really a mess to recover this!

Yes, I am very sorry about this. I do know this site should not be used as a alpha-test facility. But the include file did contain a bug that had to be fixed, and I was dealing with some apparently illogical and therefore unpredictable behavior of GAME code itself.

@Fergus: wouldn't it be better to include the application of the PHP intval operator in the implementation of piececount itself, so that it would return the expected 0 for pieces that are not on the board?

It might also be useful to apply intval to the operands of arithmetic operators such as +. (Or is that very detrimental, performance-wise?) I was really baffled by that 1 + undefined = 0.

I have now upgraded the content of this article to the new version, which also allows you to define morph and captureMatrix by filling the corresponding cells with pieces from the table. Other differences with the previous version is that under "Specify more rules" you can also define what are the royal types, and select a spell.

Note, however, that the generated GAME code does not support capture matrices or spells yet, and morphing only to other piece types. (No confinement or win squares.)

If you already use the name Kirin for one of the pieces, it would be better to use Phoenix for the WA.

'Warmachinewazir' might be a good mnemonic name for an image, but it is a horrible name for a piece in a game. I think 'Woody Rook' would be better, despite its high Waffle content. Or something like (Seige-)Tower.

The double undelining of links cause a larger line spacing with the next line, which is a bit ugly.

Very nice. On such a wide board the Bishop will be significantly more valuable than a Knight or any of the other 8-target short-range leapers. And the Dragon Horse will benefit similarly. This gives it an almost ideal value spectrum: 16 Pawns, 8 Knight-class pieces, 4 Bishop/Rook-class pieces, 1 Queen and two pieces between Rook and Queen.

would pO (with other appropriate modifiers, of course) allow castling with an intervening piece?

Sort of. I chose that as the notation of 'Fast Castling', which allows the King to jump over arbitrarily many pieces or attacked squares. The Rook would then move to the King's square of origin, though. So it is not normal castling that can hop.

The O atom is treated somewhat differently from other atoms. (E.g. the range indicator specifies the exact number of King steps, not the maximum as ranges normally do.) It had to, for making the combinations useful.

Is this fixable?

It is easily fixable, and I think fixing it is long overdue, as it looks very amateurish.

The fix is to display the piece images not as content of the table cells, but as background. So instead of something like

<td style="width:50px;height:50px"><img src="xxx"/></td>

you would generate something like

<td style="width:50px;height:50px;background-repeat:no-repeat;background-position:center center;background-image=url(\"xxx\")"></td>

(where the extensive style specification can of course be achieved through a CSS class). You can then highlight through a border with negative margins. This is how I got rid of these annoying expansion/contraction effects in the Interactive Diagram. (But there I highlight by small symbol images displayed as content of the cell.)

If the cell backgrounds have transparent parts, you see either the specified cell background color there. Or, when no valid color is defined, the background of the surrounding (<table>) element. So you can still use full-board images as background.

The problem is that browsers refuse to fit 50x50 images in 50x50 cells, because they align the bottom of the image with the text line it is on, and text lines need extra space below them for the 'true descenders' on letters like j, p and q. So they always leave some space below the image, even if there is no text at all in the cell. How much depends on the font size that currently applies, but it is not possible to set that to 0.

How about using the Prince fairy sprite for the Jeweled General?

Sorry I had so little time to spend on Jocly; there was an emergency at the talkchess.com forum, for which the hosting was terminated per March 1, and for which we had to set up a new server. We managed to do that in time, but there still are some imperfections that have to be ironed out. But I will try to update the shogi picto sprites.

The generated GAME code by default applies the 50-move rule. You can change that by appending a line

set rulemoves N;

to the Pre-Game code, where N is the number of half-moves. (So by default N=100.)

I believe at one time there was a rule that in cases where the theoretical distance to forced mate was known, you got 1.5 times that number of moves, if this was more than 50. They stopped doing that when solutions for larger end-games were calculated, and sometimes would require hundreds of moves to force the win.

Whether it pays to increase the number of moves where a draw can be claimed depends on how important the affected end-games are for the variant. In general drawishness is seen as a bad thing, so you don't want to increase the number of draws by making frequently occurring endings that could have easily been won in a larger number of moves draws instead. OTOH you don't want to force players to play exhaustingly long games when their opponent is too stubborn to accept he cannot win.

On a larger board games are naturally longer to begin with, so one can assume these are played by patient players, who do not mind to spend a little more time in the late end-game. In Team-Mate Chess I increased the limit to 64 moves, even though it is just 8x8, because the 3-vs-1 end-games you could get in were the crux of the design. So I did not want those to be spoiled by too tight a limit. In orthodox Chess most games would end in KQK, and that can be won way faster than 50 moves. I am pretty sure the choice for a 50-move rule was based on 1.5 times the number of moves needed foor KBNK.

OK, I pushed the reworked sprites to pullreq, under the name shogi-picto-sprites.png.

An N-move rule is in general a good thing to have, but so is a clock, and historic rules usually don't specify anything about that either. There do exist variants without irreversible moves, though, (e.g. Shogi), and there it becomes very difficult to formulate a sensible rule for terminating no-progress games. Even in Chess the criterion is not irreversibility, but progress. (Castling does not reset the count.) Pawn advance can be seen as progress towards promotion, but if a promoting piece does not move irreversibly, moving it back and forth obviously would not. Variants that forbid perpetual chasing can often have very long stretches of checks without repeating, (which would be allowed) with which they could delay the loss. In combination with an N-move rule with any reasonable N this would make the ban on perpetual checking ineffective. And games that are theoretical wins could take thousands of moves to reach it, because every move that progresses towards a promotion is followed by some 100 checks before the losing side runs out of non-repeating checks.

A rule that I proposed to solve this was to limit the number of consecutive checks to, say, 3, unless you end the sequence with a capture. Then you can still make such sequences when they serve a purpose, but the delay you can achieve with the checks is limited. And checks+evasions can then be discounted for the N-move rule, without the total number of moves getting unacceptably high.

An alternative would be that the player that refuses a draw after a reasonable number of moves will lose when he does not manage to win within some unreasonably large number of moves. Then being forced to play the unreasonably large number of moves by a stubborn opponent who does not want to recognize the game-theoretical outcome is at least rewarded.

Looking at the Diagram definition in the Page Source I notice this:

• It says royal=K , but it really should say royal=KJLMOT .
• The non-royal Queen is defined twice, in the same way
• The promoChoice parameter isn't useful without zone or morphing to *, and could have been omitted.

The morph parameters seem to do what you describe in the text.

It is always a dilemma whether one should pick the representation based on the move or on the name. I tend to go for the move; names you can in principle do without. E.g. in Elven Chess the Warlock is represented by a Lion, not by a Wizard symbol.

A move-inspired pictogram representation for Tori Shogi would use the King for Phoenix, Leopard for Crane and Elephant for Falcon. The Goose, Pheasants, Eagle and Quails are unique to Tori Shogi. We happen to have a good Eagle pictogram, but for the others 'anything flies'.

Name-based pictograms offer the challenge to make many different distinguishable and recognizable birds. That is hard, as some of the birds would look very similar. The sprites you used are all very much out of style with the Eagle. We do have a Phoenix and a Falcon in the fairy-sprites, and as far as I am concerned the Stork we have there is indistinguishable from a Crane (other than by coloring, which the pictogram does not show). That also leaves Goose, Pheasant and Quails. For the Quails this one would be in style. (But is seems to be copyrighted...) For a Pheasant this one is the closest I could find. (But it is too wide; to match it in scale we would have to cut off the tail feathers. But a long tail is the main charcteristic for a pheasant; otherwise it looks like an ordinary cock. This one has the right style, but I don't recognize it as a pheasant.) This seems a good Goose. (But again a copyright issue.) Perhaps something based on the top-right drawing here (omitting the colors).

[Edit] This could also make a good Quail.

And the head of this one could be a good basis. I recognize it as a pheasant even without the tail.

The recommended way for making Querquisite-like pieces is morphing. This game is in fact a special version of Avatar Chess, with a more regular morphing patters. Except that in Avatar the King was not morphing, because it was too difficult to checkmate it in thet case.

This seems to be solved here by making checking the King the goal here, rather than checkmating it? Wouldn't that be to easy?

The Interactive Diagram doesn't support checking as a winning condition. Currently the AI is not even aware that it is in check. (Except sometimes in nodes that would otherwise be leaves, when the last-moved piece delivers the check.) Perhaps I should change that, at least in the non-leaf nodes. (It is a rather large computational effort to detect every check and doing it in leave nodes would severely reduce the search speed.) Then for games where checking is the goal it could declare game end when it detects one.

In fact there could be two flavors of this: checking with a pseudo-legal move could be enough (as for King capture), the move would have to be legal (as for baring). In the variant 3-checks only the third check wins. I suppose the whole thing could be implemented by subtracting one royalty quantum from the royalty counter that the I.D. keeps track of incrementally whenever there is a check, which otherwise only happens when a royal is captured.

I am in general against spreading misinformation; there already is so much of that on the internet, no one is longing for us to add more to it. The problem with posted piece values is that they are very often not rooted in reality, but spring purely from the imagination of the author. I don't see what value that would add to an article. Every reader should be able to make unfounded guesses without any help. And it is especially bad if people post values that contradict a large body of evidence.

If I were to edit the article on orthodox Chess, claiming that the piece values are P=1, minor=2, R=4 and Q=8, based on the theory that piece values are inversely proportional to the number of those pieces you have in a game... Should it be allowed to stand? Should it go accompanied by an explanation of how these were calculated? Or by a disclaimer like "virtually everyone in the world agrees that these values are very much off, but I present these here anyway for no other reason that I could calculate them through a method that did not require any experimental evidence"?

My brother always says:  "if you don't have anything to say, then don't do that here!". Information should flow from where there is knowledge to where there is none. It is only useful to publish information that is better / more reliable than what the reader already has. Sadly, for piece values that will usually not be the case.

I created a new version of the Interactive Diagram script, which currently is only used by the Tenjiku Shogi diagram to which this is a reply. It uses a different method for selecting Shogi promotions, and I would like some feedback on whether this is better than the old method ("Promote? yes/no" links above the board), or that it just is confusing. What happens now is that the destination and a square next to it get highlighted in red, and display the two pieces between which you must choose. Clicking one of those then completes the move. So double-clicking the destination is enough to promote.

The AI is now also searches deeper on lines with checks in them, with as a consequence that it even sees the mate-in-2-threat in Tenjiku Shogi after 1.j6 SEn11 2.BGi6 at a setting of 2 ply.

The I.D. (at 2.5 ply) beat Jocly (at 10 min) at the Modern Tenjiku Shogi correspondence championship!

[Edit] An alternative method for the promotions is to define special highlight markers for promotion and deferral, rather than highlighting by (red) color and displaying the pieces to choose between. That could be less confusing than just seeing pieces appear that don't belong there. The problem is that square-covering markers would have to be dependent on the square size that is in use. But using a red disk with a + on it for promotion, and a green one with an = for deferral, which just fit into a 33x33 cell might be usable.