Comments by HGMuller

Well, what do orthodox Chess players know about variants?

Some practical considerations are that an explanation of the rules is redundant; any Chess player already knows you can lose castling rights, and very likely has experienced this himself more than once in a game. Special computer programs for it do not have to be created, because all existing engines for orthodox Chess that are in common use already can play it. Special servers for it are not needed, because it can already be played on all servers for orthodox Chess. (The server would not be fully rule-checking in that case, but who cares? We have presets here that don't check any rules at all, and it never discouraged people from playing these variants. Many servers do allow you to play from setup positions anyway, and there you could even set up a position without castling rights.)

The only thing that is new is that you cannot find books with opening theory on it. But the fact that a player has not memorized an opening line does not make something a variant.

Since when did 1.5 and 1 ply become an option?

Already a long time ago, when it turned out that some large games (Tenjiku Shogi?) took unacceptably long time at 2 ply.

It also had to do with an improvement in the AI. Originally I did not want depths so low that the AI would not be able to see checkmate in 1. And it only sees checkmate if it searches deep enough to see the capture of the King. More specifically, in a leaf node, when it generates moves to see if there still is any move it should search (but none other qualify), it would notice capture of a King (but then not search that, but just declare victory). That means it needed 2 ply to see if it can deliver such a mate, and 3 ply to see that the opponent could deliver it. But this is ameliorated by the fact that logical continuations of the previous two ply (i.e. moves that were not possible 2 ply earlier, also when this was in the game history) get an extension. So if you move a piece to a position where it can deliver checkmate on the next move, it would recognize the threat.

But at some point I made the AI aware of check in leave nodes that were delivered by the moved piece, by generating the moves of only that piece for the side that is not on move. And if this could capture the King, extend the search one ply to see if evasion was possible. This took off one ply of the depth needed to recognize checkmate. At least, if it wasn't delivered by a discovered check. I considered that justifiable, as humans can often also be tricked by discovered checks. So it makes the weakness of the AI more human-like.

I'm not sure that we should reject this 'variant' - would we be seen as snobs?

Yeah, let us behave like ignorants, otherwise the ignorant masses notice we stick out...

Well, that is not my philosophy of life.

Bruh can you just add No-Castling as a version of Chess on its existing page?

That is what we usually do for small rule changes that do not need any additional explanation.

Well, we have pieces with Persian names (Rook) and Arabic names (Alfil). And many people insist on calling a non-royal King a Mann (German). So why would a French name be a problem?

That would be true for a normal King, but for a Ghost King the 8 spaces around it have no special significance; it protects all its pieces everywhere on the board. (But they also suffer an extra attack by the opponent Ghost King, so this sort of cancels out.)

Umm, I see now what the problem is when you try to paste a Diagram specification directly from the Page Source into the PTA. It contains a lot of HTML tags that do not produce any visible output, which I could make show up by first replacing the < character by the escape sequence for it. I then got this as the pasted definition against which the PTA complained:

<span>satellite=conquer
<span id="line401"></span>files=9
<span id="line402"></span>ranks=8
<span id="line403"></span>maxPromote=0
<span id="line404"></span>promoZone=1
<span id="line405"></span>promoChoice=NBRQ
<span id="line406"></span>graphicsDir=/graphics.dir/alfaeriePNG/
<span id="line407"></span>squareSize=50
<span id="line408"></span>graphicsType=png
<span id="line409"></span>symmetry=none
<span id="line410"></span>baring=0
<span id="line411"></span>pawn (nasty neighbours):P:fWfcnD:pawn:a2,c2,e2,g2,i2,b7,d7,f7,h7,,b2,d2,f2,h2,a7,c7,e7,g7,i7
<span id="line412"></span>double knight:N:N2:knight:b8,h8,,b1,h1
<span id="line413"></span>double step bishop:B:nA7:bishop:c1,g1,,c8,g8
<span id="line414"></span>double step rook:R:nD7:rook:a1,i1,,a8,i8
<span id="line415"></span>double step queen:Q:nD7nA7:queen:d8,f8,,d1,f1
<span id="line416"></span>king:K:KisO3:king:e1,,e8
<span id="line417"></span></span><span></span>

I suppose the best counter measure would be to scan every line for the occurence of the substring 'span>', and then retain only everything that is beyond the last occurrence of that. I do that now, and it appears to solve the problem: I can directly copy-paste Diagram definitions from a Page Source. I also improved the error reporting: when the Diagram script gets a specification it does not understand, it will now first replace all < caharacters by their HTML escape sequence, so that the browser will no longer recognize any HTML tags in it, and display these as encountered in the error message.

[Edit] While at it, I also expanded the capabilities of the Move-Definition Aid to understand leaps to the 4th ring. (As I already did yesterday in the Checkmating Applets.) Originally the 4th ring was only there for seeing when you had defined a rider, or for cutting the range of a slider. Perhaps I should increase the size of the panel, so that you could also see or enter 5th-ring moves.

I am trying to do the split now, but in doing this I became aware of some bugs:

The routines cbShortRangeGraph and cbLongRangeGraph in the base model did not enforce brouhaha squares for special moves; moves with FLAG_SPECIAL should also be suppressed. Failing to do so allowed the Fire Dragon in Minjiku Shogi to enter an empty brouhaha square, as all its moves are special because of the burning, and eventually come from cbLongRangeGraph.

What is worse is that the way I implemented the brouhaha squares would suppress storing moves without any mode flags, (assuming that the brouhaha squares would have removed those that would normally be possible), while cbAdvancerGraph tries to generate the entire graph this way (in order to apply the flags later). I could rewrite the latter, but variant implementations we are not aware of might count on the old behavior of cbShort/LongRangeGraph. So I think it is better to change those, and store all-zero flags if this was explicitly requested in the call.

Yeah. But it isn't very urgent, as in the PTA the definition aid only serves to fill the Betza text entry, and you can type anything that the aid cannot make directly there.

It seems to me that this is irrelevant, as the the termination rules appear to specify that the game is finished as soon as such a capture would be possible.

It is not clear to me what 'putting your Wild Roses into check' means, though. Does that mean that both have to be not in check before your move? Or does this also cover the case where the opponent checks one of my Wild Roses, and that I then move the other to an attacked square? If not, then it seems not specified what would happen in that case.

Perhaps except in case of a promotion. The rules for that seem unnecessarily complicated. When you select an opponent piece to change to Rose, you could pick a piece that is under attack. And then you can do another move. Does that count for the opponent as leaving his Rose in check? When I use my move to attack one of his other two (or more) Roses, does that count as having put two of his Roses in check? What of the promotion move itself already delivered a discovered check, and I pick an attacked piece to change to Rose?

I think it would be much cleaner to just have the Pawn promote to an opponent Rose. That doesn't raise any questions as to when a turn ends, and consequently what 'putting' and 'leaving' in check means.

Oops! Forgot to commit the fix for that. I did that now, and pushed it again.

More usual names for the 'double-move Rook' would be 'lame Dabbabarider', 'lame Slip-Rook'or 'lame Panda'. Likewise there are the lame Slip-Bishop/Alfilrider and lame Slip-Queen/Alibabarider.

Indeed the bar is rather low on chess.com...

The problem I had is with the clarity of your description, and your latest message doesn't really solve it. You say there "if two of them are put in check AFTER YOUR MOVE, you win". The presence of the word put is what confuses me. Why is it there? Why don't you simply say "if two of them are in check AFTER YOUR MOVE, you win"? The latter is unambiguous, as it refers to a state. But when you say 'are put' it refers to a transition, and raises the question what should be the state before the transition. As there would not be any transition if that state was the same.

I was not doubting that  Roses are a liability, and giving the opponent more is to your advantage. I was just wondering why this had to be done in such a complex way. If the Pawn would just change into an enemy Rose on the promotion square, the opponent would also have an extra Rose.

Well, terms like 'Alfilrider' are very elementary, but refers to a piece that can jump over all squares it does not visit, like the leaper it was based on. The term Skip-Bishop is less commonly used for this piece; probably only when you want to stress its complementarity to the Slip-Bishop, (for which no other names are common), which boosts the rider move with a single step in the same direction, so that it can only go to the odd squares on the diagonal. (This is actually a much more interesting piece; the radial riders suffer from severe area binding, confining them to 1/4 or even 1/8 of the board, but the slip-sliders have the same board access as the slider they were based on.) The qualification 'lame' for a piece that cannot jump like it would normally do is also very common.

I think it would be better to stick to existing terminology when that is in widespread use.

I share the worry w.r.t. the severe area binding of the pieces, especially since you put most of them on the same area: all rooks and Bishops of one player are confined to the same 25% of the board, which is a different 25% from where the opponent's Rooks and Bishops are. The Bishops are furthermore confined to the same 12.5% of the board. Both Queens of a player are on the same 25% of the board. So basically the board factorizes in 4 independent quarter boards: one with two white Queens, one with two black Queens, one with two white Rooks and two white Bishops (the Bishops confined to the same half of that), and one similar for black. The conquer mechanism could transfer pieces to other areas, but only through capture by Pawns, Nightriders or Kings. Capture by Pawns you would of course avoid, and recapture by Pawns after trading would initially not happen, as the confined pieces cannot capture each other. So what remains is King and Nightriders.

We could re-order the board squares such that the confinement areas would become contiguous 4x4 areas. The Pawns and Nightriders would then get strange crooked move, leaping back and forthe between areas, but Q, R and B would become normal sliders, but confined to their 4x4 section. Looking at it that way, would you think that this game is winnable when only the two Nightriders are able to enter the enemy section? My feeling is that a player set on achieving a draw would just avoid the Nightriders from capturing any slider in their own two sections.

There's no way, in the current implementation, to represent the capturing abilities of the Coordinator or Pincher.

Pincher capture is a form of (conditional) burning. It is not a move, so I don't think it should be represented in the move notation. If the Interactive Diagram were to support it, it should be through the burnZone spec (and captureMatrix for indicating which piece burns).

Now there is of course a spatial aspect to a burn zone, and its extent can very well be defined in Betza terms. As the ID already does. In this definition it is implied that it specifies capture, or in fact rifle capture at all the indicated locations, as an automatic side effect (i.e. mandatory when possible, but not required to be possible). We could elaborate on this definition by allowing modifiers on the atoms. E.g. dK would specify burning of all adjacent friendly pieces. Then you could also specify multi-leg burning. Pincher capture is a form of bouncing grasshopper capture, [dD-bucW]. (This uses the d-u kludge for specifying friendly hopping over the D squares, to capture at the jumped-over W squares.) In a burnZone definition the capture would be understood to be rifle capture. (So perhaps the c should be omitted, as in burnZone specs it is implied that the destination indicates enemies there disappear.)

Coordinator capture (also a form of burning) would be harder to describe. It would be multi-hopping hook-mover hopping to the friendly King, followed by reversal of the second leg of the hook move to make the capture. Problems in expressing that in the current XBetza implementation is that there is no way to specify friendly King capture (so the capture-unload trick cannot be used for the friendly hopping): k captures the enemy royal, ck every enemy non-royal, but dk would logically mean every friend or the enemy royal, with is not redundant, so there is no justification for a special interpretation "every non-royal friend" in analogy with ck (which was otherwise redundant). And this would not be the interpretation we need (only the friendly royal) anyway. The second problem is that although multi-hopping can be indicated with the aid of parentheses, the 'iso' mechanism would not be able to exactly reverse a combination of hops. Not even if we specify that repeated use of i would refer to ever earlier previous slider legs rather than always the latest: a mechanism to force an equal number of hops in the reverse leg would also be needed. A simplification would be to allow pp as indication for "hops arbitrarily many". Then [ppcR-sppk'R] would do it, with the conventions that use of an explicit c in the definition of the burn zone indicates the victim of the one rifle capture it will do, and the apostrophy in k' means friendly King. (This use of apostrophe or double quote on mode modifiers could be used as a general mechanism for indicating friend-only or foe-only, so that it could also be used on p, and the d modifier would become redundant, and could be replaced by c'.)

Don't hold your breath until any of this gets implemented, though. It is already possible to do these captures  with the aid of additional scripting, as can be seen in the Ultima Diagram. Considering how extremely uncommon these pieces are, that seems good enough.

It appears that trajectories that go temporarily off board (the XBetza o mode) are not yet implemented in the GAME code. And the Advancer is defined through such a trajectory, as a multi-leg move that first overshoots its destination by one step, and then takes that step back. This as part of the test that there is no enemy there that should be removed; empty squares, friendly pieces and the step going off board would all be OK; they are not enemy pieces. But the GAME code does not implement the off-board case, so the furthest destination of an Advancer move that hits the edge would not be considered valid, as there is no room for the extra back-and-forth.

In the context of the Interactive Diagram this was easy, as squares are specified by coordinates, which automatically describe an infinite plane. In the context of GAME code this is a bit harder, as squares are specified by arbitrary labels, and there are no labels for 'virtual locations' beyond the board. So there is no instruction for stepping back onto the board, because there is no way to specify from where you should step back.

This means I can not literally translate the JavaScript code of the ID that handles this to GAME code, in order to fix the problem. A work-around would be to have the GAME code process the step-off, step-on legs at the end of the Advancer move as a pair instead of one by one: if it sees that the first of these allows o mode, and would stray off board, it should not try to make the step, but look ahead one leg, combine the two steps (which then should lead to an on-board square), and take that to continue.

This is not a trivial fix, so I will think more about it when I return from shopping.

[Edit] OK, I made a temporary fix, which allows you to fully use the Advancer: I made the betza.txt include file assume that any attempt to step off board by a move with o-mode would be the first leg of a back-and-forth step at the end of the move, and approve the move to the start square of that leg. This obviously would not work for cases where the move travels further, such as a reflecting Bishop.

I think the crucial phrase that is missing in the second sentence is "at the end of your turn".

"Giving check" already implies that it is at the end of your turn. But because of this fine distinction it might be better to formulate the whole thing in a more similar way:

If two or more(?) of your Wild Roses are under attack at the start of your turn, you lose (checkmate).

If two or more(?) of your Wild Roses are under attack at the end of your turn, you win (blossom roses).

Nice tags. I should use them in some of my articles too!

It seems a bit strange to attribute the 'stalemate is a win' rule to Grander Chess, while the original form of chess (Shatanj) already had that rule and the world's most popular decendent (Xiangqi) along with many others still has it.

That is quite easy: I just added the line shuffle=NBRQ . That causes all of the mentioned pieces to be randomly permuted over their initial positions. (Only when you press the Restart button of the AI, though; the initial Diagram always shows the 'nominal' position, which might be important for knowing what the castling partners are.)

Since this isn't really a shuffle but a placement game, you did not specify any restrictions on the shuffle, assuming that the common sense of the players would avoid undesirable positions (such as all your Bishops on the same shade, or an unprotected black piece attacked by white). A random shuffle of course ignores such considerations. A rule like 'no unprotected attacked pieces' would be too complex to enforce anyway. But people can always reshuffle if a position comes up they consider defective.

If you post in HTML, please take care that your Comment contains as many </div> as <div> tags. Otherwise it would mess up the remainder of the command list. I had to add an extra </div>, because all other Comments were appearing inside yours! (It could be worse; I have seen cases where unbalanced tags made the entire remainder of the list disappear, including the link to edit the offending post, which made it really hard to recover from that.)

The way you formulated

Pawns and Kings are the only pieces that remain in their own half of the board in Version 2 of the game. 

implies that all other pieces have to be put on the opponent half, which is of course not true. The sentence seems redundant anyway; you already stated that K and P have fixed positions, and readers are not so stupid that they would have to be told the positions in which the Diagram shows them are on their own half.

The representation of promoted shogi pieces as pictograms is one of the things I am in general unhappy with. It has some advantages to make a promotable piece distinguishable from a non-promotable piece with the same move. But using an entirely different pictogram in a game that already has so many different piece types is hugely confusing. So much that I even wonder if it would not be better to leave the difference invisible. (In over-the-board Bughouse players are used to having to remember whether Queens resulting from promotion revert to Pawns when captured, or just leave the Pawns on the board, having to remember they are Queens...) When I implemented Chu Shogi in pictogram representation if XBoard, I added special pictograms for promoted (Crowned) Rook and Bishop, Vertical and Side Mover, which were slightly less detailed versions of the normal pictograms. (Which for the Movers I took to be (standing or lying) Swords, because their shape is a good reminder for the move. In a similar spirit I took standing and lying narrowed Queen symbols for the Flying Ox and Free Boar.)

I think we should give Chu Shogi its own set of pictogram sprites. We could then take pictograms with red outlines or details for the non-promotable equivalents, like the kanji pieces do. And add a horizontal sword to it for the Side Mover. That set should then also made to be optimal for Tenjiku and Minjiku Shogi. (So the flying pieces should be in there too, some also in red.) Most pictograms can simply be copied from the wikipedia-fairy-sprites, and then reoriented or recolored as needed.