Great to hear this!

You know what? I will add type-differentiated promotions to the Diagram as a standard feature. So you won't have to use any custom-supplied WeirdPromotion() routine for that. This is easy to do: I will allow suffixing any piece ID in the promoChoice string by a number. Which, when present, will be taken to mean the number of ranks (counted from the back) where it can promote. Pieces not suffixed like that will use the value given for promotionZone instead. So by writing in the Diagram definition

holdingsType=1
promoZone=3
promoChoice=!P*N*B*R2*Q1

the pieces N, B, R and Q must be in the hand (where they get by being captured) to allow promotion to them, due to the asterisk. (The P has no asterisk, because it is not really a promotion, so nothing has to be available. It is just forbidden on the last rank because of the !.) But even when the piece is available, Q would only be allowed on the last rank, and R on the last 2 ranks. B and N can be chosen on rank 1-3, P only on 2 and 3.

[Edit] I have uploaded a version of the Diagram script that implements this now. A beneficial side effect is that it now does the correct highlighting in the piece table for the pieces that can be chosen. With WeirdPromotion you could reject some choices after they were made, but it did not have any effect on the prior highlighting. It can be tested in the Gross Chess diagram.

By shuffling i meant like in 960 indeed. I remember you doing the shuffling especially for this game but I then lost it when I lost the device where it was saved. Once I get to the interactive diagram on apothecary chess I will ask this favor of you. Thanks!

I am not sure what you mean by 'shuffling'. Something like in Chess960? The diagram just sets up the position that you specify. It would be hard for a general diagram to know what kind of shuffling is acceptable. (E.g. must the King stay between the Rooks? What if there even aren't Kings or Rooks? Or when there are multiple ranks of pieces? Or brouhaha squares?) And what should trigger the shuffling? Refreshing the pase, to re-initialize the diagram? Should there be a button for it, and if so, where?

It might be better to just start with the squares that contain shuffled pieces empty, and put all pieces in the 'hand' in the initial position. People can then first set up the shuffle the want by dropping the pieces, and start playing from there.

Of course it would also be possible to just embed a small JavaScript routine in the HTML page that does the shuffling in the way you want it.

BTW, I added a hidden feature to the Diagram. (This was really only for debugging purposed, and I am not sure I am wise to mention it. For people might take it serious, but they will probably discover it anyway.) When you click the 'move' header in the piece table, the column toggles to display the piece values estimated by the AI instead of the moves in Betza notation. Don't believe them; it makes exactly the same errors as most people do when guessing piece values!

Great work HG!

Intelligent Diagrams!

I now equipped the diagram with a simple generic AI, so that you can play against it as a demo. It is not very strong; just a simple alpha-beta searcher with a recapture extension instead of an all-capture Quiescence Search, set for a depth of 2 ply. Somewhat like micro-Max 1.6. Except that it doesn't even have good piece values; it guesses these by itself.

Any Interactive Diagram should now automatically have the clickable phrase 'Play it!' on the line below the diagram that also served to open the piece overview. If this is clicked, the AI is switched on, and a button bar will appear. Any move played in the diagram will then automatically be replied to with a move of the opposite color. The diagram will continue to do this until you hide the button bar by clicking the 'Play It!' again. The diagram will collect all moves (both yours and those of the AI) into a game, and the button bar will allow you to navigate through that game.

About your idea of including piece descriptions in the piece table:

Overall, including piece descriptions in the piece table is a good idea that I think should be implemented. Here are my thoughts on it:

First and foremost, including piece descriptions for a piece in this way should be optional, so you don't have to do it for every single piece in the table, which would be quite tedious, especially for larger games like Hook Shogi and Taishin Shogi. Of course, you can put in default descriptions for predefined pieces, but the programmer should also have the ability to override these. For null descriptions you could simply replace the empty string with a hyphen.

Regarding implementation, I recommend putting all the piece descriptions in an array so you can use JavaScript variables to hold piece descriptions if need be. And when setting piece descriptions in the diagram script, I would suggest putting the descriptions after everything else in the colon-separated list, like so:

name:id:move:image:startingHand:description

This way already existing diagrams won't get screwed up by this new implementation.

If you do implement this, make sure to update this page to include information about it.

Currently the diagram is limited to a single locust capture. Which already makes the Lion Dog of the large Shogi variants fall beyond its capabilities. If this were solved (e.g. by allowing an array of locust-victim coordinates), the XBetza notation could specify each number of victims separately, e.g. RcdafRcdafcdafR ... Which for a big board like Taikyoku's 36x36 becomes of course very cumbersome.

Perhaps there would be some benefit of extending XBetza notation with a 'repeat count' on a group of modifiers. This would then replace the 'a' modifier. A leading '0' on the number could indicate 'exactly that many', where otherwise it would mean up to that number. So cd02fR would then mean cdafcdafR. Where the expansion rule is that the repeat count would group with preceding modality modifiers, and following directional modifiers. (So that you could still slam an initial directional modifier on the first leg, and a different modality modifier on the last one. That would allow description of the Tenjiku jumping generals as multi-hoppers: Rp14cR or Rp0cR.)

I wonder if there is a way to make a piece capture everything in its path? For example, in Taikyoku Shogi there are range-capturing pieces that destroy everything in their path (including friendly pieces). In Betza 2.0 this behavior could be indicated using cd0. Perhaps the WeirdChain function holds the answer?

Oops... It seems there has been a mixup of versions at some point. This code was added as a hack to do Peace Chess, where pieces can combine to 'embracing pairs' coexisting on the same square. The IDs for these combinations are generated here automatically. Piece Chess of course only has 6 basic piece types, so for that purpose having the pair codes start at 64 located them well beyond 'nType', with a large safety margin. But I should never have used that hacked version for replacing the script that powers the diagram in general, at least not without modification. There is no reason why the 64 could not be replaced by (say) 400, to not wreck any variants with fewer than 400 piece types. (Without this hack the limit was 512 piece types; the 512 bit is used to indicate piece virginity, the 1024 bit for piece color.)

Thanks for spotting this; I will fix it soon.

Interestingly, I answered my own question. When looking at the source code, I found this line of code that was responsible for the pieces IDs being overwritten:

for(i=1; i<7; i++) for(j=1; j<7; j++) ids[64+8*i+j] = ids[i] + ids[j]; // combis

When I removed it from the source code, the problem disappeared. Honestly though, I have no idea why this line of code was in there. Logically speaking, wouldn't you want every piece to have the correct ID on it, instead of having the IDs of some pieces overwritten with something else?

I also noticed another thing about the diagram that I thought was very weird. When the diagram has at least 73 different pieces it starts combining the IDs of the first 6 pieces and replacing the actual ID of the piece with those. Specifically, it does this for the first group of 6, and then it skips two pieces. This process repeats until all 6 IDs have been used (So if the first 6 IDs are 1, 2, 3, 4, 5, and 6, the overwritten IDs would be 11, 12, 13, 14, 15, 16, 21, 22, 23, and so on all the way to 66). For example, the diagram in you page on Maka Dai Dai Shogi replaces the IDs of the Furious Fiend (+Ln), Buddhist Spirit (+DS), Teaching King (+Dv), Crown Prince (+DE), and Emperor (+K) with PP, PGB, PE, PSt, and PT, respectively. This is probably due to a bug in the source code, as I can't see any reason to think that it was intentional. However, this is only a guess. Do you have any suggestions as to what might be causing this?

Could be that I did that intentionally. The universal leaper moves are generated by a piece of code that is completely different from the code that generates other moves. (As they are not relative to the start square.) And this code doesn't test for the target squares being attacked. In the Maka Dai Dai Shogi diagram the Emperor was the only royal piece, (as it was the last piece mentioned), but I did not want any royal piece, (as there is no rule against putting yourself in check there), and the fact that it is a universal leaper now hides this. But later I added commands to the diagram to set the royal piece by hand, and allow multiple or none. So this kludge is no longer needed.

Interestingly, the diagram doesn't grey out the squares that would result in moving into check when the royal piece is a Universal Leaper (XBetza notation: U), like the Emperor in Maka dai dai Shogi.

The diagram is in the comments to the Xiangqi article: https://www.chessvariants.com/index/listcomments.php?id=33312 . From its page source:

        function BadZone(x, y, piece, color) { // enforce board zones
          if(touched) return 0; // not during ShowMoves()
          if(piece == 4) return (color ? y < 5 : y > 4); // Elephant: across river
          if(piece != 3 && piece != 8) return 0; // otherwise OK if not Advisor or King
          return x < 3 || x > 5 || (color ? y < 7 : y > 2) && (board[y][x] & 511) != 8;
        }
        function Shade(x, y) {
          var col = 0;
          if(y > 4) col = !col;
          if(x > 2 && x < 6 && (y < 3 || y > 6)) col= !col;
          return col;
        }

The argument 'piece' contains the type of the moved piece, and 'color' indicates its color (non-zero = 1024 = black). The routine is called for a proposed move, so board[y][x] at this point is still the victim. I suppose the exception made for allowing a King to leave his Palace to capture the other King is not really necessary when its move is defined as WfkR; King and Advisors could simply be allowed in either Palace, as they have no moves that would bring them to the opponent Palace other than the one that must capture a King.

The BadZone function is indeed very useful. For example, if you wanted forbidden moves of royal pieces into check (which are highlighted dark gray) to not show up at all, all you need to do is use this function in your script, which works with both moves that move directly into check and castling moves that land on or pass through check:

function BadZone() { return blockFlag; }

However, this function isn't elaborated on very well. It has four parameters - x, y, piece, and color. The parameters x and y can be used to track the destination square of a piece (i.e. typ = board[y][x]) but piece and color are shrouded in mystery.

You said that you used this function to "confine pieces to their zones in Xiangqi," which is very interesting and could be very useful, as I am reasonably certain that you all four parameters there, though I could be wrong. Perhaps you can show me the function that you wrote to do this?

Wow, you really dived deep into this. Thanks for the feedback. The 't' in XBoard was a kludge to allow approximate representation of moves that were too difficult to handle correctly, by making it possible to 'round up' the move to something that was doable, in the sense that it would include every pseudo-legal move and then some. That way the GUI would not block the entry of any legal move because it though it was not in the piece's repertoire. And then leave it to the engine to refuse the 'and some', should the user try to play it. (XBoard protocol allows engines to do such a thing.) But this strategy fails when XBoard would think one of the 'phantom' moves was checking the King. Enforcing the checking rule makes it that you have to be exactly right in your moves: if some moves are not supported, you cannot play those, but if extra moves are supported, you sometimes cannot move other pieces because it is imagined this would leave you in check. The 't' modifier was added to make it possible to selectively disable checking by all extra moves, so the latter problem cannot occur.

But the diagram does not test for full move legality; its purpose was to demonstrate how pieces move, and not showing some of the pseudo-legal moves because of checking restrictions only caused confusion. (I later added greying out King moves that directly stumble in check, to get a good representation of slider Kings that cannot pass through check, without obscuring what the pseudo-legal moves of the King really are, to do 'Caissa Brittanica'.) So the diagram does not really need the 't', as it accepts any move anyway, and the harm in highlighting spurious moves would not go away by it. And I did not know any variant that really had pieces that could not capture royals with one of their normal capture moves. So I figured the 't' was not needed.

In case of an 'emergency', there is a work-around, BTW: the diagram script looks for the presence of a user-supplied function

BadZone(x, y, piece, color)

which allows you to veto moves that the Betza encoding would allow. I used this to confine the pieces to their zones in Xiangqi, but it could also be used to veto a move because the indicated piece type cannot capture what is at square (x,y). Or to implement variants with restrictions on what can capture what, of which the 'tame' moves are just a special case. And this does affect the highlighting! (The 'k' I added to make it possible to implement the King-facing rule of Xiangqi, which was borrowed by some western chess variants as well.)

Triple moves are indeed a pain. XBoard supports those now. It would require a lot of messy code. I don't think that 'chaining' like in Paco Shako would be the simplest way to do it. It is definitely also on my wish list.

Custom definition of royal pieces is already possible, though the parameter royal=N . In the most recent version this is even implemented as setting a flag for piece type number N, rather than remembering the value of the parameter. So you can have several such lines in the diagram definition, indicating multiple royals. But since the diagram doesn't take account of the checking rule, there is not much effect of defining something as 'royal'. Only its own moves are then sometimes greyed out. And games like Chu Shogi, which do have multiple royals when you insist on representing Prince differently from King (as kanji pieces would), doesn't really have a checking rule, so that in fact the royals should not lose any moves even when they do stumble into check. The diagram doesn't test for game end.

These diagrams are a wonderful thing. They can easily describe various moves that Game Courier can't handle without using complicated code. However, I have a few suggestions that, in my opinion, would make the diagram even better.

• Tame pieces - The modifier t on a final (or only) leg of a move means that move cannot capture royal pieces in XBoard. In other words, it is the opposite of the modifier k on a final (or only) leg of a move, which means that move can only be used to capture royal pieces. This modifier should be relatively easy to implement.
• Custom definition of royal pieces - Currently, the only piece that is specified as royal by the diagram is the last piece on the diagram. Some variants may have more than one kind of royal piece (i.e. Chu Shogi), which makes this a useful extension, especially if the royal pieces must stay out of check.
• Triple Captures - This is without a doubtthe hardest extension to implement. Adding this would, in theory, require adding a lot more code to handle the second locust capture. However, this extension would be necessary for the Lion Dog, which can capture three pieces in a straight line, and other pieces that can capture three pieces at once. There might be a way to do this with the WierdChain function. However, that function hasn't been used in your diagrams other than in the Paco Shako diagram.

I have now implemented the 'hover method': when you are displaying a move diagram it will show the piece on an empty board. But if you hover the mouse pointer over a marked square it puts an enemy pawn there, and shows the moves in the presence of this Pawn. This can in particular be used to elucidate hop targets (grey background), to see what kind of moves the screen enables, and locust capture squares (cyan star), to show where you have to move to make the indicated capture.

On touch-screen devices, where you cannot hover, a touch when a move diagram is being displayed will count as hovering the square, and materialize a Pawn there. Switching back to the setup diagram

[Edit]

I now implemented a method to reduce 'collisions' between moves of different type to the same square in move diagrams. For normal moves and captures the highlighting system itself already takes care of this, by defining different colors/symbols for move-or-capture, move-only, and capture-only, and also showing the latter in empty squares. But for hopping moves and locust captures there was a problem, as these moves are never really possible on an empty board, but only indicate potential moves. These potetial moves can coincide with real moves on the empty board. The potetial moves therfore now use the opposite highlighting system as the others. When normal moves are indicated by symbols, the move diagram will use background color to indicate potential hops, and both a symbol and a color to indicate locust capture. In the latter case, the symbol will only be drawn if it does not collide with another symbol, irrespective of the order in which the correspoding moves are defined in the Betza move string. This way a normal move will never be hidden by a hop or locust capture, while it will always remain visible that there is a potetial hop or locust capture over the square as well. When color is used as principal highlighting method, the potential moves will be indicated by drawing a question mark in the square.

E.g. for a Checker the locust victims coincide with normal non-captures, and in the move diagram this will be indicated by the move-only symbol, plus a background color. The user is thus warned that other move potetial is present when this square would be occupied, and can then hover over the square to 'realize' this potetial, by materializing a Pawn there, and calculating the actual move through the square for this case. If it was a locust capture, the victim would now be marked with the locust-capture symbol, and the destination square would be highlighted as a normal move. For a hop, only the destination square would be marked.

I have implemeted the idea now to show potential hops in the move diagram as a separate symbol. (Currently I use the same marker as on the board is used for King moves that step into check. Which is also a case of "possible under other circumstances".) It doesn't really produce the desired effect; on the Grasshopper it is OK, but the betza1 piece was defined as an enhanced Pao, mRpcR. And because the move-only access to a square is defined by a different Betza atom as the hop possibility, the latter overwrites the former. So the information that non-captures to these squares are valid moves is lost...

This is a manifestation of a more general problem: what if the same square can be reached for different purposes? Currently only the last generated highlight survives, and I leave it to the user to decide what this should be (by writing the order of the various moves). By writing the Pao as pcRmR the potential-hop marker would be overwritten by the move-only marker. So far that didn't cause any problems in practical cases. E.g. a Rook that also jumps to the second square should be written as RD, and not as DR, so that the D jump overwrites the sliding move, and remains visible. You don't have to know that you could go to the same square through a blockable move if you can get there with a leap, after all. If you had a RmD it would be problematic, though. The capture to the second square is now blockable, the non-capture is not. There is no symbol for that combination of moves. For overlapping riders it is even more hopeless: suppose you had a Rook-Dababbarider RDD. It would show up the same as a Rook, which suggests that distant moves can be blocked on squares closer to the piece. That is true for access to the odd squares, but access to the 4th square (say) is not blocked by an obstacle on the 1st or 3rd square (because the DD leaps over those), but it would be blocked by an obstacle on the 2nd square. Having separate symbols for such weird situation is not productive, I think.

Giving the markers a black outline improves visibility on an e-ink screen. For something like the Cannon, you might separate two different markers by a slash. The slash could represent a screen, and one marker could indicate a move possible before the screen, while the other could indicate a move possible after the screen. For a Cannon's one-step move, the marker for a non-capturing move could be used by itself.

I am afraid this will get too complex to still transfer information. In general you cannot fully desribe every potential situation in a static picture. Suppose you had a piece like Mats' bifurcators, which change direction after (or before) colliding with a screen. There the number of squares you could reach if there was a screen in an undetermined position fills an entire sector of the plane, and it would be completely obscure what position a screen would need to be at to reach a particular potential target.

So I think the purpose of the markers should merely be to warn the user that something tricky is going on which would alter the picture in an unexpected way if the square was occupied. (The expected way being that it blocks the ray, and all symbols identical to it 'downstream' would just disappear.) Not to encode in detail what it is that would change. That the user can discover interactively, by indeed putting something on the marked square. He can already do that in the setup diagram, by moving pieces into a similar constellation, but a simplified possibility could even be added in the move diagram through the 'hover trick'.

That being said, it still seems bad to have a move diagram of a Pao only show non-captures without a hint of hopping, or only show hop locations without a hint it could simply move there. (A similar situation occurs in Quan Trung Chess, where there is a "grasshopping Rook locust"). So perhaps the potential to hop should not be indicated by a marker, but by a grey background color, so that it can combine with any marker, rather than erasing it. The move diagram is not checkered, so it would be the only deviating background color, so no problem on a grey-scale device. And when background color is the main method of highlighting, it could draw the grey cross marker in the hop squares.

Giving the markers a black outline improves visibility on an e-ink screen. For something like the Cannon, you might separate two different markers by a slash. The slash could represent a screen, and one marker could indicate a move possible before the screen, while the other could indicate a move possible after the screen. For a Cannon's one-step move, the marker for a non-capturing move could be used by itself.

However, something different would have to be done for a grasshopper, which could not move any distance past the screen. Perhaps a move that could be continued further could be represented by an arrow in the direction of the move, and a move that cannot be continued could be represented with an octagon, the shape of a stop sign.

OK, the marker images were just a flat color, which was a bad idea. I have now given them all a black outline, and have tried to make the inner colors brighter by mixing in some white for the darker colors red and blue. This should now be recognizable against any background.

As to the betza2 moves: the problem is that this piece is defined as a Grasshopper. So it has no moves on an empty board! Which is what the diagram shows, moves of the piece on an empty board. This is very nice for ordinary leapers and sliders, because you see their complete move potential, without anything being blocked. But for hoppers, which acquire moves only because of obstacles, it is not very satisfactory. That also holds for locust capture, which is not possible without a victim being present, but there (like with ordinary captures) the ShowMoves routine at least shows the location where a victim would have to be. But you still cannot see where the piece would end up if it makes such a locust capture.

I don't have any good ideas for how to solve these problems. For sliding hoppers, rather than making the board empty, the ShowMoves function could dump some platforms in their path. But then you would never know if the hopper could have moved beyond those if they had been absent. You can of course hope that if the platform is located far enough from the piece, the suggestion that it is an infinite-range sliding hop is correct. But in the case of a Dababba that mandatorily jumps (jD), you would have to place an obstacle next to it to enable the move, and you would not be able to see or even suggest that there could also be a on-capture to that adjacent square. For locust capture, a piece could have multiple possible targets (a Checker has two), and statically indicating where the piece ends up after such a capture would not reveal which final destination belongs to which capture target. (Think of the Chu-Shogi Lion, or Ultima pieces.)

How about the following?: When displaying the move diagram of a piece on an empty board, the mouse cursor becomes a 'virtual opponent piece'. If the user hovers it over the board, the diagram would be recalculated as if there was an enemy piece on the square he is hovering over. In particular, if he hovers over a square marked as locust victim, it will show where the piece can land after taking that victim. And if the square is in the path of a hopper, it will show the moves of the hopper with a platform there. (Where capture-only destinations are indicated in red even though the board is currently empty, as it now does for divergent normal pieces.)

When pieces get too complex, i.e. their moves depend on too many conditions in other squares, it is just ot possible to illustrate it in a static diagram. This is the whole idea of providing a diagram where people can move around pieces, rather than just responding to clicking on a piece name. They can then set up situations they wonder about, e.g. for the locust capture, to see what happens if they make it. But it is true that the move diagrams makes the user aware of locust captures, while potential hops remain completely 'silent'. Perhaps there should be a marker symbol (like an inverted white triangle) in the move diagrams to indicate squares where the piece could hop over something. The Grasshopper then would show up as a Queen. Not sure how I should do it for the Pao, which has both real non-captures and potential hops for capturing on the same squares...

CSS has background properties that will let you center a background image without any tiling. For example:

STYLE="background-repeat: no-repeat; background-position: center center;"

That seems to do the trick! Thanks! This is really starting to look good now.

2) The background images are positioned differently in the cells than the content images. The latter had margins, and to prevent board raks from expanding when you moved a piece to an empty rank, the square size had to be chosen a few pixels larger than the actual piece images (e.g. 53x53 for Alfaerie, which has 50x50 gif images). The background image always starts in the upper-left corner, and the cell is then tiled with as many copies of the image as are needed to cover it completely. This means that a few pixels eear the upper and left edge get repeated near the right and bottom edge. Some pieces are so big that they have visible parts this close to the edge, and then you get ugly artifacts rear the latter edges. This can be prevented by defiing the square size exactly equal to the image size (and perhaps make the marker images a bit smaller, and center those, to prevent their margins would cause cells to expand). But all existing images do not have that.

CSS has background properties that will let you center a background image without any tiling. For example:

STYLE="background-repeat: no-repeat; background-position: center center;"

You could also use the single background property for multiple values, such as background color, background image, background repeat, and background position.

I was just checking out the XBetza Sandbox on my Kindle. Some of the markers seem faint, and in comparison with my desktop monitor, the checker includes some yellow circles that do not even show up on my Kindle. Although using different colors for the markers might work well on a color display, it would be best to make them all black on a greyscale display.

Also, the betza2 does not display any moves on my monitor or on my Kindle.