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.

Great work HG!

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!

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!

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.

Great to hear this!

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.

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?

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.

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

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.

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.

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.

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

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.

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.

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.

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?

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

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!

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

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?

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.