Thanks HG for putting the effort into notating the castling in my game

OK, I implemented this new notation in the diagram script. (As yet untested.) The main difficulty was detecting when to use it; I don't want it to supercede the O-O notation in games with normal castling. And it must not be confused by asymmetric castlings as in Janus Chess, which do have two O atoms in the move descripion, but as rO and lO, so that they are still unambiguous. It also must not trigger it just because there is an sO and an sjO. So I wrote code to count the number of O moves for each of the sideway directions and each number of j modifiers separately. And if any of those on any piece exceeds 1, the game is flagged as having 'free castling', and will use the K~... notation for indicating any castlings. (Even those that might not be ambiguous.)

On input it will only treat the ~ as special in gemes that are flagged to have free castling; and input move that contains it will then only be matched against the castlings generated by the move definition in the current position, and will only match when the to-square of the King matches the square specified in the move.

P.S. I see no reason why the same noation couldn't be used also for Kevin's 'fast castling'. The castling rules (in particular for to how the Rook must move on castling) can be assumed to be known, so there isn't any reason to make those explicit in the move notation. They should be specified in the move definition. I don't think it would be useful to allow mixing of normal and fast castling, so if a move like K~b1 is encountered, it would unambiguously follow where the Rook (or other castling partner) ends up. Fast castling should be indicated in Betza notation by a different atom than normal castling. I am in doubt between V and OX. Perhaps it is better to reserve OX for Fischer castling. Which the diagram currently doesn't implement. An OX castling would then be specified just as an O castling, and define the result when it is performed from the nominal position. The extra X suffix would then indicate castling would also be possible in positions that shuffled K and R, but with the same result as from the nominal position.

How about using a special separator for castling? We now have x for captures, and - (or nothing) for non-captures. We could adopt ~ for castling. So in the orthoChess setup Kd1 or K-d1 would be a normal King move to (empty) d1, but K~d1 would be Q-side O1 castling. K~h1 would be K-side O3 castling.

This makes a lot of sense to me.

In Odin's Rune Chess (or Chu Shogi) the hit-and-run captures use notations like Fxh5-g4, while double captures are written as Fxh5xg5. (The interactive diagram, unlike the automatically generated presets for Game Courier, doesn't make a distinction between 'shooters' and double movers, so the extra victim of the Forest Ox should be entered and is written as an intermediate square.) But this only accounts for double-moves with the same piece, and castling doesn't fall in this class.

I guess the most natural notation for castlings for which O-O and O-O-O would be ambiguous is indeed as a double move. But now that I think about it, the fact that there is both jO castling (with the Rook) and O castling (with the Cannon) doesn't really cause any ambiguity: you can only castle with the nearest piece. The only problem here is the usual one for free castling, that you need to specify the King destination. It is sort of standard to make a sideway King move of more than one step imply castling in that case. In any case, O-O noation is no good for free castling. So I suppose I should make the diagram recognize the case where a piece has multiple O moves in the same direction and the same partner with different range. And in that case use the King's move for notation rather than O-O.

There still is the issue for how to distinguish O1 castling from an ordinary King move, and how to handle the case where the King ends on the Rook square. The KxR notation seems natural for the latter case, as it would indeed specify the square where the King ends. (There still is no need to specify the Rook move separately; it is fully implied.) But then KxR would not be available for O1. RxK doesn't seem such a bad way for indicating O1 castling, as you would specify a Rook move with a square where the Rook indeed ends up.

How about using a special separator for castling? We now have x for captures, and - (or nothing) for non-captures. We could adopt ~ for castling. So in the orthoChess setup Kd1 or K-d1 would be a normal King move to (empty) d1, but K~d1 would be Q-side O1 castling. K~h1 would be K-side O3 castling.

Your variant poses the problem that both the King destination and the castling partner have multiple options. This requires specification of two squares. A possibility would be to let the empty square where the King should move to capture the Rook. (Or have the castling partner capture itself, when the King would end there.) Perhaps Greg has ideas of how to best solve this.

I don't really consider this a "castling" problem.  What we have here is a rule where multiple combinations of pieces can move to multiple combinations of squares.  There could be use in addressing this for any game might want to do this, but if we want to support this, I think it should be done in a general way, not forced into the context of castling.  (So, I am not at all in favor of empty-space-captures-rook.)  I think the robust way to address is as two separate moves, like "a1a2,b1b2".  Doesn't the interactive diagram have a similar issue with the Forest Ox from Odin's Rune?  It also must record a third square.

Also, if we're going to do an a1a2,b1b2 kind of thing, it makes sense to me to consider a separate delimiter for multi-move games such as Mersaillias.  I think our life would be easier if "single moves" that consist of different parts are delimited differently than the separate moves of multi-move variants.  For example, if a double move variant has, as it's first move, one of these moves that requires two different annotations, perhaps something like "a1a2,b1b2;c1c2"

In any event, this is a large can of worms, and I don't think we rush a poor solution just because this expiremental game has a crazy castling rule.

By the way, Indeed castling is not that useful. Because of the 2 layer of pawns the king is quite safe in the middle. There would be situations where is useful, even if rare. Nevertheless it is an option for the player.

In my game on the edge files there there are berolina pawns. In the corner there is a chinesse cannon and on the 2 adjacted ortoghonal fields, rooks. The shorter castle is with rook, the longer one is with cannon.Here is an example:

<div style="float:left;margin:0 40px 20px 0;">
  <div class="idiagram">
    files=12
    ranks=14
    symmetry=none
    holdingsType=1
    promoZone=4
    promoChoice=!P!X*N*B*C*W*Z*R3*Y3*F3*J3*G2*Q2*D2*L2*T2
    graphicsDir=../graphics.dir/alfaerie/
    whitePrefix=w
    blackPrefix=b
    graphicsType=gif
    squareSize=54
    hole::::a1-l1,,a14-l14
    pawn:P:mfW*fceF:pawn:b4-k4,f5,g5,,b11-k11,f10,g10
    berolina:X:mfF*fceW:berolinapawn:a4,l4,d5,i5,,a11,l11,d10,i10
    king:K:KisO3isO4isjO2isjO3:king:g2,,g13
    rook::::a3,l3,b2,k2,,a12,l12,b13,k13:1
    queen::::f2,,f13:1
    bishop:B:B:bishop:c3,j3,,c12,j12:2
    knight:N:NmHmA:knight:b3,k3,,b12,k12:1
    wizard:W:FL:mage:d2,i2,,d13,i13
    champion:C:WAD:champion:e3,h3,,e12,h12:1
    cannon:Z:mRcpR:cannon:a2,l2,,a13,l13
    knightrider:Y:NN:nightrider:c2,j2,,c13,j13:1
    sangoma:S:BZ:/graphics.dir/alfaerie/%zebrabishop:f1,g1,,f14,g14
    vulture:F:afafafsKafsafafKafafraflKafaflafrKafraflafKaflafrafKmD:bird:d3,i3,,d12,i12
    joker:J:fI:fool:e1,h1,,e14,h14
    Dragon:D:FyafsF:dragon:f3,,f12
    Griffin:G:WyafsW:gryphon:g3,,g12
    Lyon:L:DB2afyasfF:lion:h2,,h13
    Tiger:T:AR3afafyasfW:tiger:e2,,e13
    symmetry=mirror
    shuffle=:B:N:C:F,QLT,DG,:W:Y
    maxPromote=2
    royal=3
  </div>
</div>

Standard notations for castling cannot deal with such ambiguity. An alternative notation that is used in UCI protocol is KxR (e.g. e1h1 or Kxh1 for O-O in orthodox Chess). But this would be problematic in the context of  a very general system, where capture of a friendly piece might be allowed. Furthermore, the KxR notation is sometimes also used for resolving ambiguity between castling and normal King moves, in games with flexible castling, to indicate the castling where the King makes a single step (i.e. O1 castling).

Your variant poses the problem that both the King destination and the castling partner have multiple options. This requires specification of two squares. A possibility would be to let the empty square where the King should move to capture the Rook. (Or have the castling partner capture itself, when the King would end there.) Perhaps Greg has ideas of how to best solve this.

BTW, I seriously wonder how the castling choice that you propose can be any good: castling was invented for bringing the King to safety without trapping the Rook. If you can castle with an 'inner' piece through the jO castlings, you would trap the outer piece. Unless that piece can develop by jumping over the Pawn shield (as it can in Omega Chess). But then castling with it serves no purpose. You would have to get rid of the inner piece first before the second becomes available for castling. And if that inner piece is a Rook, you would have to compromise the Pawn shield for that, in such a way that you would not want to castle in that direction anymore. While when both the corner piece and the inner piece were capable of jumping over the Pawns, involving them in a castling serves no purpose. In that case the only beneficial effect is to speed up the travel of the King towards a corner. But you could have achieved that by just giving the King an isR move.

Hello again HG. In the game I'm currently working, the king has the following Betza notation: KisO3isO4isjO2isjO3 I have only seen O-O and O-O-O for notation but there are 8 types of castling. For all of them the notation must be unambiguous. otherwise the game cannot be loaded. Thanks!...

HG, May you add on this article some info about how to save games, especially with shuffle variants? I know this can be found in comments section, but that is not always easy to find!

There doesn't seem to be very much to say about that. It displays the game, and you can copy that elsewhere, or back.

It is true that the diagram has many functions now, which are not always obvious. So I expanded the introduction of the article with a short description of what the diagram can do. (The article was almost exclusively about how to create such diagrams yourself, rather than how to use existing diagrams.)

HG, May you add on this article some info about how to save games, especially with shuffle variants? I know this can be found in comments section, but that is not always easy to find!

Yes Greg. Now it works!

put a forward slash at the beginning of your url

Ok, for some reason when trying this: graphics.dir/alfaeriemisc/compounds/%zebrawazir it results in this: https://www.chessvariants.com/rules/graphics.dir/alfaeriemisc/compounds/bzebrawazir.gif

OK, my bad. I was wrong about adding the file exension; this was already done at an earlier stage, before replacing the % by a color prefix. This means you should NOT specify an extension in the 'custom image', and that it then will always use the same extension as the regular images. That means you cannot use the cobra from the se in the Elven-Chess directory with alfaerie (because it is png, and alfaerie is gif). But you should not have problems using an alfaerie image from another directory. When you do not put the .gif in the custom name.

BTW, if it doesn't work, you can open the piece legend of the diagram, and right-click the 'missing image' symbol in it, and select 'View Image' from the context menu. This will give a 404 error, but in the adress bar of your browser you should then be able to see what the filename was that it finally made from the parameters you supplied. Which often tells you what went wrong.

I still could not make work. I cannot add the wazirzebra here:

https://www.chessvariants.com/invention/grand-apothecary-chess-alert

from here:

bzebrawazir.gif (49×49) (chessvariants.com)

Thanks HG!

Ok HG, I'll get to work. Thanks!

Oh, I see that the Diagram already supports a way to include 'custom graphics' for the pieces. I had forgotten all about that.

To include an image that doesn't use the specified graphicsDir or graphicsType, just write the full URL of the image, but with the color prefix replaced by a % sign. The script will replace that % sign by the whitePrefix or blackPrefix, as needed. So you are still limited to image names that use the same color prefixes. E.g. if you specify as image name in the piece definition:

/membergraphics/MSelven-chess/%cobra.png

you could use the cobra image there, no matter what graphics you specified for the other pieces. Note you should also explicitly mention the file exension.

Greg, Can you help me by drawing a ferz-alfil-trebuchet? I tried using my own tools but it goes kind of bad.

Honestly HG, I'd prefer that you manage to do the relative path. It would be very helpful!

Thanks for the input, HG!

If you create an article, this automatically creates a directory /membergraphics/MSarticle-name/ for any files you upload. So you could upload all the images you want to use to such a directory, and specify that as graphicsDir in the Interacive Diagram definition. You have to make sure the squareSize, graphicsType and white/blackPrefix match that of the uploaded graphics.

You cannot use sets that are scattered over several directories. Because the diagram builds the image filenames as prefix + root name + exetension (where the exension is the specified graphicsType). So giving the root name as a pahname, like subdir/quagga, would no work, because it will prefix the directory name with the color ('wsubdir/quagga.gif') rather than the image name ('subdir/wquagga.gif'). This should be easy to fix, btw; I could make the diagram split any given roo name at the slashes, prefix the last part with the color, and then put them together again.

How do I create a directory?

Also, How do I upload images?

All right, Thanks Fergus, I'll try it.

It's easier for an editor, but you can download images to your computer and use the file manager to upload them to a directory.

I assumed this cannot be done by a non editor.

When I used alfaerie pieces for an interactive diagram, I put all the images I needed in the directory for the game.

I'm not sure. It may not be possible to use images that are not all in the same directory. If it can be done, H.G. would have to tell us, but I haven't seen him around here lately. I hope he's OK!

I am not sure on how to put the file directory for a child directory. For example if I set graphicsDir to ../graphics.dir/alfaeriemisc/ then I need acces to it's subdirectories to acces the zebrawazir. How can I do it?

I probably can do it if I change to directory from default to: graphics.dir/alfaeriemisc/

It still does not work. Try for example : zebrawazir

Got it.

Use the images that ere there while you are designing. Then, edit the generated code to use different images.

How can I do it? I see only the default images. I need to somehow use the names for the other images.

The generated code has variables for updating the image format, folder, and filenames for each piece, so I see no reason why this should be an issue.

Is there a way to use the alfaerie many graphics from the diagram designer and game courier in the interactive diagrams?

It shouldn't be too hard to implement the majority of the features. The main problem I am currently facing is how to implement the display of legal moves from XBetza notation, which becomes quite complicated, especially when you take into account the way multi-moves work. Once the display of legal moves is fully implemented, the Universal Chessboard will enter its Beta stage.

Interesting! I took a look through your source code and it looks like you are off to a good start. Good luck on your ambitious project!

I've been working on a side project of mine called the Universal Chessboard, a stand-alone application designed to support as many chess variants as possible, within certain parameters. It is somewhat similar to and inspired by these interactive diagrams - for example it uses the same general format for its presets as the format that is used to parse these diagrams (albeit with some parameters added/missing/different). Although it is still very much in its infancy (as it is currently at version Alpha 0.0), it already has many basic features implemented. You can move pieces with the mouse or with text, navigate through the game, undo moves. reset the board, load board positions, load game presets, etc.

You can check out the application in its current state as an Eclipse IDE project or a runnable .jar file here: https://github.com/amdewitt/Universal-Chessboard.

I thought it was zero. I must have misunderstood an earlier comment of yours. But this is indeed a difficult problem. I can't even think on how to tackle it.

Where does it get a value 0? When I try your diagram in Apothecary Chess - Classic, it lists it as 455.

If this is not reproducible, then something can be done about that. I can for instance always make it mimic the royal piece, while taking statistics on the number of moves it has (from which the value derives).

I see that is part of the problem, but a value of zero is very naive. Thanks for the wonderful tool!

The problem is that giving it a value will not solve the problem of strange trades, no matter what the value is. Basically the Joker affects the value of other pieces. E.g. if both sides have a Queen and some Pawns, but one side a Joker (and one less Pawn) the side with the Joker probably has the advantage. At least, I would not trade it at the earliest opportunity for a Pawn. But trading Queens would make the Joker much less useful, and the player with the Joker should avoid it. But to do that it would have to understand that the Queens are not equally valuable. Otherwise it would happily trade them no matter what value was given to the Joker.

HG, If you have time please work towards giving a value to the joker.

Have you seen my last comment HG? Was I clear enough?

Hello HG, You have said a while ago that the joker does not receive a piece value. You have also said that the sum of the squares of the values of the opponent's pieces over the sum of the values of said pieces could be a good approximation. This should not be hard to implement, when you have the time, otherwise as the computer makes some funny decision.

Your program for pasting games works pretty well. To be honest, I didn't expect you to pull that off, though you probably aren't one to give up easily.

The problem with SAN is that it is very vague. It only shows you the piece ID, where that piece moved to, if it captured, a letter and/or number for disambiguation, and promotion choices, if any (and possibly if en passant capture was used). Basically, it shows you the minimum amount of information that required. However, this also makes parsing the moves very complicated (but not impossible). Game Courier has to deal with this same problem at an even larger scale, as some presets use different coordinate systems compared to SAN (i.e. Shogi and its variants). This is why Game Courier uses the notation it does. The notation my functions use an even simpler notation, with each move being a list of coordinates (and sometimes piece IDs) separated by hyphens, a character unlikely to be used in an actual piece ID. This allows the moves to be parsed quite easily using the following process:

• Split move string into components and pass to an array, with a space as the delimiter.
• For each move in the array, split into its components and pass to another array, with a hyphen as the delimiter.
  • Process the move based on the length of the array. Unless stated otherwise, all elements must be coordinates. Piece IDs are uppercase for White and lowercase for Black, and setting the shogiMode flag reverses this.
    • If length 2, single move or drop. First element may be a piece ID or a coordinate.
    • If length 3, single move with promotion or double move. Last element may be a piece ID or a coordinate.
    • If length 4 or more, multiple move with or without promotion. Last element may be a piece ID or a coordinate.
  • If an error occurs, exit loop without moving anything for this move and print an error message (moves successfully parsed before the error are still executed). Otherwise, make the move accordingly

As for FEN code, I am not sure how else to print the current position to and load positions from strings. It seemed like the best system to use for this when I made the functions, since none of my games involved random shuffling of the initial position.

Well, for displaying the game I prefer SAN, as it is the commonly used notation by regular Chess players. I would like the game parser to be as universal as possible, though. At the moment it would not understand formats with multiple hyphens; I assumed that intemediate squares only had to be mentioned with locust captures, and would be preceded by an 'x'. Then only the final leg of a multi-leg move could go to an empty square. But this is wrong; e.g. the Valkyrie of Odin's Rune Chess needs to go to the square where it wants to move the displaced piece to first. So I suppose I should first replace all 'x' in the move by hyphens, and then split by hyphens.

The problem is how to distinguish an intermediate square from the square of origin. When there always was an 'x' in front of intermediate squares, that was easy, as there never is an 'x' between the piece ID and a (possibly partial) square of origin. It would be problematic if there could be a hyphen between piece ID and origin. I guess I could check whether the first square, when it is fully mentioned, contains the mentioned piece. If not, it must have been an intermediate.

I have not decided about how to indicate the position. The method of random seed works, but cannot be used if the game was not generated by the diagram itself. FENs become pretty ugly with multi-letter IDs. And they are a bit overkill, as we don't want to indicate arbitrary positions, but just how the pieces are permutated. E.g. for Chess960 it would be enough to print the back rank. And that is small enough to make it a comma-separated list.

So perhaps the following would be a good solution: the Diagram's shuffle parameter contains piece types. During a raster scan of the board (say a1->h1->h8), any square that contains a piece that occurs in that list in the 'nominal' (= pre-shuffle) start position can potentially get another piece, and you the Diagram then print/reads the piece that actually ended up there. If the shuffle was symmetric you only do that for white pieces.

In making my own interactive diagrams, I decided to add functions for getting FEN codes from board positions and loading positions from FEN codes. They work pretty flawlessly, provided you use an ID w/ at least one letter for each piece. It even works w/ multi-character IDs, which are enclosed in curly brackets in the FEN code.

I also made functions for getting and loading game moves using a more specialized notation, w/ each element of the move separated by hyphens. Though it isn't standard algebraic notation, I have tested this system and it works very well.

If you would like, I can send you a text document w/ the functions.

I fixed the problem for shuffle games with a quick hack, because I was to lazy to write a FEN generator and FEN parser for prefixing the move list with a FEN for the starting position. What I did instead was save the seed of the pseudo-random number generator that controls the shuffling, and print that in braces before the move list. On pasting this the seed can then be restored, so that we will get the same shuffle.

Testing this revealed that the shuffling itself had a bug, which is now also fixed: When a King with castling capability was shuffled, but the Rooks (or other corner pieces that served as castling partners) were not, the code that should keep the King between the Rooks was erroneously triggered. As a result a KQ shuffling step could lead to disappearence of the King (replacing it with a second Queen), because in the cases where it wanted to swap them it suppressed placement of the King, supposing this would be done later together with the Rooks. (Which it then wasn't.)

Very nice feature!

This does not work yet. I guess I must make the game record start with a description of the shuffle, and then parse that when you paste a game.

What about games where the initial position is varied like chess 960?

I implemented a new feature to the Interactive Diagram: you can now also load games into it. The game record that is displayed in the 'AI bar' (which can be opened by clicking on the 'Play It!' link) below the navigation buttons is now editable. If a game record is pasted there, it becomes the current game, through which you can step using the buttons. This feature is still in the alpha testing phase; the design goal was mainly to make it understand its own game notation. So that people who played a game against the Diagram in an article can post their game as a comment, and others can then copy-paste it in the Diagram to use the latter as a game viewer. (This was an idea suggested by Fergus.)

E.g. in the Capablanca Chess diagram of this article you can now paste the game:

1. e4 e5 2. Nh3 Nc6 3. f3 f6 4. Bc5 d6 5. Ba3 Be7 6. Cg3 Ae6 7. O-O Qf7 8. Ad3 O-O-O 9. b4 g5 10. b5 a5 11. bxa6 bxa6 12. Axa6 Kd7

The Diagram uses Standard Algebraic Notation for the games. Interpreting that is not trivial, so there could still be errors. There should be alert popups when it encounters moves it cannot understand (e.g. because the mentioned piece is not present, or because multiple moves satisfy the notation). Especially moves with implied side effects (such as e.p. capture) are tricky; if no pseudo-legal move matches the notation as given, but there is a single move that matches what is given, but has additional non-mentioned locust capture or promotion, it assumes that move was meant. It should also accept non-pseudo-legal moves that are unambiguously specified (e.g. by fully mentioning the origin square, or by mentioning the moved piece type when only one piece of that type is on the board).

Note that the loading of the game is only triggered by pasting it; if you type moves there, they will be ignored.

Also note that drag & drop moving of the pieces in the Diagram is now fully supported: the dragged piece is animated (a feature that was lost when I switched to using the piece images as background, to make room for foreground marker symbols), and the piece disappears from the origin square while you are dragging it.

You are correct, it works fine if the piece table is open!

That is probably because you have not opened the piece table where you can select the piece from. In that case it just picks a default.

I guess I could have it open the table automatically, rather than picking a default.

[Edit] I have done that now.

It promotes to archbishop and griffin respectively, automatically!

But what exactly of that doesn't work?

I'm sorry for that. I meant the behaviour described in the game rules: "Pawns promote to any auxiliary pieces on the players 8th rank, any auxiliary or average peice at the 9th rank, and any piece at rank 10.For the purpose of limiting material when physical play is involved pawns are also restricted to promote to the pieces in reserve. In the reserve enter all the pieces captured of the colour of the promoting pawn and from the begining of the game 1 queen, 1 rook, 1 knight & 1 mameluk."

and

"Pawns may promote to any auxiliary piece on the players 8th rank, any auxiliary piece or average piece at the 9th rank, and any piece at rank 10.For the purpose of limiting material when physical play is involved pawns are also restricted to promote to the pieces in reserve. In the reserve there are initially 1 queen, 1 rook,1 champion and 1 knight and later on enter any of the player's lost pieces."

So mostly the same thing.

You do not specify what behavior you see that you did not expect / desire. But I did notice that it doesn't allow you to defer promotion by selecting a Pawn: the Pawn is not highlighted. I think that is because you specified the ID for Pawn as a lower-case 'p', but mention an upper-case 'P' in the promoChoice.

The !P in the promoChoice probabbly doesn't do what you want here, as it will disable the Pawn on the rank of brouhaha squares (which it considers the last rank). There is no notation to disallow a choice on the last two ranks. But it probably doesn't do any harm if the P is available even at the point where it would have no move left. No one would ever choose it.

Please take a look at my 2 apothecary chess games. I think either I did not understood the way promotion should be implemented either there is a bug in the diagram! They are here:

https://www.chessvariants.com/rules/apothecary-chess-2 

https://www.chessvariants.com/rules/apothecary-chess-1

I see your points, and I'd like to add that it is probably wrong in apothecary chess to push too many pawns. But some pawns may be pushed.

The problems you point out might be related. Pointless shuffling of pieces in the opening often occurs because within its look-ahead horizon the position that the AI's evaluation considers best is not at the horizon, but can already be reached in fewer moves. The AI then deosn't mind to waste tempos in the effort to reach that position. It sees that it can be reached anyway, and it saw nothing useful to do afterwards. If advancing Pawns is considered good, there will allways be some Pawns to advance in the opening, as you have so many of those. In that case there will be an incentive to reach positions with good piece development as early as possible, as this will then leave you more Pawn moves to improve the score further.

There is one problem, though: mindlessly storming ahead with all Pawns will expose your King, and often other valuable pieces as well, as it would allow your opponent to creep behind your Pawns. Pawns really make an essential contribution to controlling the squares near your camp, preventing invasion by light pieces. So it is important to keep some back, both as obstacles for blocking enemy sliders as for the squares they attack. In Fairy-Max I managed to get reasonable Pawn play by awarding Pawn pushing in general, but then give a penalty if 2 files left or right from the square of origin of that Pawn there wasn't another (friendly) Pawn. Because that means no Pawn is left to control the square that the pushed Pawn used to control. So after 1.e2e4 the move c2c4 would be discouraged for creating a weakness at d3, while d2d4 would still be OK, because b2 and f2 are still in place.

The problem is that this is very much based on the Pawn move being like in FIDE/Shatranj. It makes no sense for Berolina Pawns, Shogi Pawns, Janggi Pawns etc. And there is no guarantee that the Interactive Diagram will always have Pawns that move as in FIDE.

All Pawn types are useful for shielding the King against slider attack, and this can be expressed by giving a penalty for pushing Pawns next to the King to compensate a general Pawn-advance bonus. The problem there is that the King often doesn't start at the location where you want it to be. So applying a penalty for pushing Pawns in the King shield in FIDE would just prevent opening with your center Pawns, and would make the engine push the b- or g-Pawns instead, spoiling its future King shield in the castled positions before the King could ever get there. Again, this is much dependent on the initial position and the type of castling, which can differ from case to case. In general castling can be assumed to be good (or there would have been no need to make a special rule for allowing it), so the AI gives a lot of bonus for castling. But (unlike Fairy-Max) it doesn't search deep enough to have castling within its horizon when all pieces are still on the back rank, and a bonus that it cannot see how to get will not affect its play no matter how large you make it. If it prefers piece moves over Pawn moves there is a better chance that it clears the path for castling, (and subsequently castles) before it destroys the Pawn shield at the castled location.

But again, this is dependent on a lot of factors, so it is not that simple to produce the right behavior. Perhaps something like giving extra bonus for moving pieces between King and corner away in variants with castling. But in FIDE-like setups those are basically all non-Pawns. And it would be pointless to do this on both wings. So perhaps there should be a penalty proportional to the number of pieces between a (virgin) King and corner on the side where this number is lowest, to not needlessly encourage quick development of pieces (i.e. before pushing many Pawns) on the wing where you are not going to castle to. Problem with many variants is that the pieces can jump over the Pawn wall. For FIDE only Knights can do that, and you have to push Pawns to develop the Bishops, even when you would prefer developing pieces over pushing Pawns. It is not easy to get a good balance between Pawn moves and piece moves in all cases.

Also, if you can do something about the joker's value it would be awesome.

Hello HG! I have played against the diagram's AI and also watched games played against itself and I could not help myself from noticing 2 obvious flaws in it's play.

1. the diagram's AI does not push pawns in the opening
2. the diagram's AI moves way to often the same piece twice in the opening

Is it possible to make an option for games close to chess or Grand Chess (as my apothecary games are) where these things are taken into account?

Thanks!

Ah yes, there was a bug there. I tested whether the Joker was an fI or a bI after I had already corrected the f and b meaning for the color. So that a black fI was seen as a bI. This should be fixed now.

Hello HG, I have played a game of apothecary chess-classic where the joker is defined in XBetza notation as fI. What has happened is that the black j imitating a white P went backwards instead of forwards as a normal black p would move. Can I fix that? Can you fix that, or give an option for it?

HG, I am curious about how the joker's power is calculated by the interactive's diagram AI. This seems to me a difficult task.

Now that you mention it, it puzzles me that it gets a value at all. The Diagram determines the piece values by setting up a couple of random positions, and then count the number of moves and captures a piece would have when put on every empty square of these positions. But this is done before any piece was moved, so the Joker should not have any moves at all. Yet it does seem to get a non-zero value.

But I guess the concept of piece value does not apply to the Joker at all, so no matter what value it would get, it would always be wrong. A more sensible approach would be to give the Joker the average value of all pieces of the opponent, or perhaps a weighted average that weights mobile pieces more heavily, as these woould on average be moved more often than others. So something like the sum of the squares of the piece values divided by the sum of the piece values.

But that would just be the instantaneous value of the Joker. And the value of pieces is much dominated by the instantaneous value they would get in the end-game. E.g. in the early middle game Knights and Bishops have usually many more moves than Rooks, yet trading them for a Rook at that stage provides an almost winning advantage. A Joker against just King plus Pawns would be a pretty useless piece.

It seems to me that 3-fold repetition is not detected by the current interactive diagram. Is that true?

That is true. For the purpose of getting a feel for what the game is like this didn't seem needed. The AI is pretty weak, and the human should try to beat it. If the Diagram starts repeating, it is up to the human to deviate, as a draw should be considered a success for the Diagram. The human can decide at any time whether he wants to continue the game, or abandon it.

It seems to me that 3-fold repetition is not detected by the current interactive diagram. Is that true?

HG, I am curious about how the joker's power is calculated by the interactive's diagram AI. This seems to me a difficult task.

Without table it will in general be difficult to make a sensible promotion choice automatically. Not every variant has such an obvious default choice as orthoChess. So the idea was that people who want to seriously play would always open the table. But the diagram serves more purposes than playing (which is only a recently added capability), and for showing move diagrams or an initial position the promotion function is totally unimportant. So there is no reason to show the piece table by default.

What it now does when the table is closed is indeed a bit primitive: if promoChoice starts with a letter it takes the piece with that ID; if not it takes the forelast piece in the table (assuming the user will have specified the pieces in order of increasing value, King last, an assumption that fails for the diagrams generated by the Play-Test Applet).

I was too lazy to add a lot of code here (e.g. to check which pieces are in stock) only for the purpose of ensuring that the choice was legal (but likely still unsatisfactory) with a closed table. It is not really a disaster if the user gets a wrong piece because he forgets to open the table before promoting; he can just take back the move (and the reply) with the < button, and try again. The diagram accepts illegal moves in general, so why should illegal promotion choice be an exception? And if the table is open, but no choices are available, the user can simply click another piece on the board to abort the attempted promotion.

That being said, there are prospects for improvement here. For the purpose of the AI I wrote a completely new move generator, which creates a list of pseudo-legal moves. (And that includes all pseuo-legal promotion choices.) One of the items on my to-do list is to abandon the old move generator used for highlighting, and rewrite the mouse-click handler to interpret board clicks in terms of this list, narrowing the sub-set of possible moves as more squares get clicked, until only a single one is left. That would also cure the current limitation of only a single locust victim. And promotions for which no valid choice is available would not have occurred in the list, and not have been highlighted. I don't really feel like putting much effort in a temporary solution. (This reminds me that the AI probably does not recognize such impossible promotions as delivering check, now. But that again seems a rule that would never have to be invoked in practice.)

What should be rather easy, though, is completely remove the code that handles the case of a closed table, and open the table instead when the user promotes.

[Edit] I now uploaded a new script, which does the latter. It now also recognizes the case where nothing in the table gets highlighted, and aborts the move immediately rather than inviting the player to pick a piece.

I found an issue with promotions trying to implement Grand Chess.  Here are the promotion options:

promoZone=3
promoChoice=*N*B*R*Q*M*C!P
holdingsType=1

This works correctly as long as the table is displayed so that the user must choose the type to which to promote.  If a pawn tries to move to the last rank with no promotion option, and the table is open, it will highlight the square green, but you cannot complete the move because you can't pick any option from the table.  But, with the table closed, if you move to the last rank with no promotion option available, you automatically promote to cardinal!

I am saying that the Diagram (including the AI) will work, but that the Play-Test Applet currently cannot be used to completely generate the necessary Diagram description through its 'Show HTML' button. Because there is no way to make it add the necessary setting maxPromote=2. But you can add that line by editing the HTML code it does produce afterwards. Or you could also generate the Diagram description through the Design Wizard; this does allow you to specify a value for maxPromote. And it also allows you to control the order in which the pieces are specified.

I'm not sure I understand. You seem to be saying that it will work and it will not. Do you mean the interactive diagram will work but the AI will not?

You should be able to do this by defining Pawn and Ferz as the first two pieces, setting maxPromote=2, promoZone=1, and promoChoice=W (assuming W is the ID of the War Elephant). It might still want you to indicate the 'choice' by clicking on the War Elephant in the table (which will then be highlighted in blue). But it only requires a choice when the table is opened anyway. If the table is closed it always promotes to the default piece, which is the first ID of the promoChoice string. If there is never any choice, there is no reason to open the table.

The Play-Test Applet doesn't offer an opportunity to specify a maxPromote parameter different from 1. In western Chess variants it is very rare that there is more than one promoting piece, and in the cases I knew the promotion rules for the non-Pawns are then often special. (E.g. more Shogi-like, where there is a fixed promoted form.) The Play-Test Applet has no provision for defining Shogi-type promotions (which would be controlled by the diagram parameters maxPromote and and promoOffset, rather than promoChoice.)

Such mixed promotion rules are not really supported by the Diagram proper; the Diagram can be augmented with a user-defined JavaScript function WeirdPromotion to handle such cases. This is what I used for Chess and a Half: as far as the Diagram is concerned only Pawns promote, and it enforces the promoChoice setting on those. Promotion of the other pieces is handled by having WeirdPromotion recognize when they should promote, and return the promoted version in that case. I also use that for implementing 'contageon' in Maka Dai Dai Shogi.

It is always a hard call what to include in an interface to keep it user-friendly; I don't want to deter prospective users with an enormous list of options they would almost never need.

I have been thinking for how the need for using a custom WeirdPromotion script could be reduced. I could for instance introduce a parameter contageon that would decare a list of pieces that should be treated as contageous, and by default make royal pieces immune to that. (Or also introduce a parameter immune.) And I could make mixed promotions standard by having the Diagram obey the promoChoice parameter for the first piece (presumably Pawn) even when promoOffset is non-zero, if the promoChoice is non-empty or different from a single +.

Can the ID support Shatranj Kamil X? Specifically the promotion rules - Pawn and Ferz both have mandatory promotion to War Elephant on the last rank. I read the promotion section but its not obvious to me how to do this.

The interactive diagrams are an awesome innovation by the way!

The problem is that writing a strong engine is an open-ended project, that you can easily spend all your time on for the rest of your life. No matter what you have, it can always be made stronger with more effort. But unfortunately I have only one life, and cloning has not yet be perfected.

Besides, if you want to have a really strong engine, JavaScript is a bad idea. The same algorithm implemented in C would always be significantly faster, and thus stronger.

So any effort spent in this area would be more fruitful when spent on a conventional C program like ChessV or Fairy-Max, than on a JavaScript web Applet. You can argue that the diagram is more versatile than existing multi-variant engines w.r.t. the range of CVs it can handle, but that is exactly because more effort went into expanding its possibilities, rather than increasing its playing strength. I still believe that it will be more useful to add features that would allow it to do CVs it cannot yet do (e.g. with piece drops) than to make it stronger for those it can already do.

That being said, there are many standard techniques in engine building that the diagram's AI doesn't implement yet. Such as a transposition table, move-sorting heuristics such as killer and history, check detection, null-move pruning.Perhaps at some point I will add the check detection, because it seems really a bit unbalanced that (at 2 ply) it doesn't see mate-in-1 threats against it. It would add a lot of code to do that in a way that doesn't enormously slow it down. (And if it did, it would probably be better to keep the speed and just set it for 3 ply.)

In an earlier comment you said you could build an AI that plays much stronger than the one you currently have implemented into the diagram. I know the AI in the diagram is intended to be weak, but maybe you could implement the stronger AI as a separate option and have an option to switch between weak and strong AI in the AI bar?

Well, Chu Shogi seems to be the only case where this exception exists, and it makes no sense to tailor a diagram that is intended for general use too much to one specific variant. The diagram already has a 'hook' for customizng promotion rules to a variant: the page can provide a function WeirdPromotion() for sanctioning a default promotion, or altering it. I guess it would have been better if the Chu Shogi exception for last-rank Pawn promotion would have been implemented through that. Now the Diagram does it by default, it also happens in Dai Shogi, where the rule makes no sense (and thus probably would not have applied) because it is always better to promote a Pawn to Gold when entering the zone.

Perhaps you could add a function (i.e. IsPawn(p)) to allow certain pieces to promote on the last rank? That way you can still keep the option off but allow certain pieces to promote on the last rank if need be.

Oops, I inadvertantly unbalanced parentheses when fixing the problem that in the checkmating applets it insisted the first piece should promote when the piece table was open (despite promoZone=0). Fixed now.

The newest diagram script has a script error. Here is the error message I got when putting a diagram using the new script into the repl.it IDE for HTML:

>
Script error.
>

That is correct. It does count all ranks, also the brouhaha squares. It doesn't make an exception when there are only dark squares on a rank, and brouhaha squares are still part of the board. I thought it was allowed to capture to brouhaha squares, and there is no reason why such a capture could not also be a promotion.

So you would have to define promoZone=4, and adapt the rank limits in the promoChoice string accordingly.

I played against the AI in the interactive diagram .

when a pawn of mine has reached the promotion zone the promote menu has not appeared.

My guess is that the rank with brouhaha squares is counted as the final rank so the 3rd from last is unpromotable, the 2nd from last behaves as the 3rd from last should, and so on.

Null moving can currently be done by closing the AI, moving a piece back and forth, opening the AI again and press Move. For something that perhaps is needed only once every few hundred games, that doesn't seem too much trouble. Trying to do it through the normal move-entry interface is likely to have unwanted side effects for everyone. It would already be a problem that a drag & drop null move is not distinguishable from a single click to select the piece.

It may be rare that you would skip a turn in a Shogi variant, but there are those instances where that is useful.

If you were to implement such a feature, I would suggest keeping the deselection of pieces the same, but having the squares where locust captures are possible trigger the 2nd leg code even when those squares are empty. However, it's important to differentiate between multi-moves that can br triggered by moving to an empty square and those that can only be triggered by capturing (i.e. the Lion's lion power vs. the Heavenly Tetrarch's igui move).

As far as I know, there is no easy way to skip a turn with a multi-move piece has this ability. Can this be implemented?

Do you have any suggestion for how that could be implemented? I guess that what makes it difficult is that the move-entry system makes non-destructive intermediate squares transparent, so that a back-and-forth move to an empty square only leaves a marker on the selected piece. And clicking that again deselects it. I guess I could change the priorities there, so that clicking a piece that has marked itself as target will result in a null move, rather than a deselect. It should always be possible to deselect it by clicking another piece. (And if you have no other piece, there is no reason to deselect it in the first place.) Currently it only does that if a locust victim has been specified.

But is this really important? I always though that null moves are merely a hypothetical possibility, and that in practice it would almost always be very bad to play them. The pieces that can do null moves in Shogi are so powerful that you are not very likely to get into zigzwang if you have them.

The new AI is pretty impressive. But I must ask you something. As far as I know, there is no easy way to skip a turn with a multi-move piece has this ability. Can this be implemented?

I now also added shuffling to the standard diagram script. You just have to specify a parameter shuffle=... with a string of piece IDs, mentioning all the piece types you want shuffled. If you prefix one of the IDs with ! it will make sure the pieces of that type are equally distributed over the square shades. If there is a piece that has castling as one of its moves, and the pieces in the corners of the specified position are of the same type, it will make sure the castling piece ends up between the other two. (Better only use that when all shuffled pieces are on the same rank!) If you specified a symmetry in the diagram (e.g. symmetry=mirror) it will respect that symmetry; otherwise it shuffles black and white independently.

So all you have to do to turn a Diagram for FIDE into Chess960 is specify shuffle=N!BRQK .

Shuffling is triggered by pressing the 'Restart' button in the AI control bar. It then restarts from a new shuffle.

I rigged the Diagram in the Metamachy article to shuffle the Eagle, Lion, Queen and King.

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.