Comments/Ratings for a Single Item

Charles Gilman, did you read that this game is for children, who are
lerning to play normal chess, so things you suggested are not good for
this!
The only bad thing, wich i can see in this game is that castling is not
useful: king is already in corner. I can suggest varinat on 5x8 board, with
queen in first file (QKBNR), first, it uses all piece, and second, here
castling is a bit more useful.

Well, the Queen is also a piece in FIDE chess, so I'm not sure how this helps the argument.

For a game designed for kids, adding a queen gives them a lot of power without introducing a constraint. And the objective, it seems, is to make the game easy enough for kids while introducing them to the notion of constraints of movements.

The queen is literally a combination of a rook and a bishop, so it would be loopsided to have a queen and a rook (or a queen and a bishop).

Better to have just the bishop and the rook, which gets little kids start learning about constraints.

Just my humble opinion (I only landed on this page looking for a place where my kid could play demi chess online, so far I can't find one.)

Here's a diagram with a playable AI (my first, so let's see how this goes):

(So far this looks right. Having the defaults correctly detected for the common pieces means all that needed to be checked here is promotion and castling; really nice H.G.! But specifying promotion choices seemed finicky; without explicitly giving the knight's label it wasn't recognized, and depending on the order of the promotion choices I lost other choices as well.)

It is always very useful to get feedback from first-time users. So I am curious what exactly made defining the promotion choice non-trivial. To start with, which method did you use to generate the diagram? Did you use the Play-Test Applet, the Design Wizard in the article about Interactive Diagrams, or did you compose the diagram by hand-editing yourself? And if you used one of the 'wizards', did you do any post editing of the HTML these produced?

BTW, your diagram is not yet fully correct: you did not specify a royal=N parameter, and that makes the last piece you defined the royal by default. And you have ordered the pieces such that the Queen is last. To cure that either reorder the pieces so that the King is last, or add the line royal=5.

The Play-Test Applet should use N as ID for a Knight, in the table from which you can select the pieces. The Design Wizard probably takes the first letter of the name as an ID by default, which would give you an undesired K. Perhaps I should program an exception for that.

P.S. The Play-Test Applet seems to contain a bug; when I move the King that is present by default to a corner, it asks me to promote it! I will check out what causes this; it seems a very unnatural thing to do.

I used the Play-Test Applet, followed by some editing of the html. Specifically, since the queen doesn't appear in the initial setup, I needed to add it to the promotion choices, which subsequently required adding it to the piece list (hence its appearance last, which I didn't remember indicating royalty).

The Play-Test Applet also produced a more-verbose version of the piece descriptions than necessary, so I pruned those down based on viewing another of your posted diagrams. But then the issue with the knight came up, and it seemed that it needed the explicit id.

It seemed (though I went through many iterations, so perhaps there was some other issue) that the order I listed the promotion choices in mattered for which ones became available.

I've updated my previous comment to fix the royalty, and I cannot recreate the issue with promotion list order.

I used the Play-Test Applet, followed by some editing of the html. Specifically, since the queen doesn't appear in the initial setup, I needed to add it to the promotion choices, which subsequently required adding it to the piece list (hence its appearance last, which I didn't remember indicating royalty).

A work-around for such extra piece types could be to place them in the empty area of the board in the initial position. Then they will be put in the piece list, and in the post-editing you only have to delete the list of squares where they should be put.

The Play-Test Applet also produced a more-verbose version of the piece descriptions than necessary, so I pruned those down based on viewing another of your posted diagrams. But then the issue with the knight came up, and it seemed that it needed the explicit id.

I guess the problem with the Knight was that you pruned a bit too much. In particular the ID field for the Knight, which would have be an N if you had left it alone.

The order of the pieces in the promoChoice string should not matter; when a promotable piece reaches the zone the diagram just goes through the piece list, and for every ID tests whether it occurs (as a sub-string) in the promoChoice string. This algorithm failed when the IDs are not single letters, so I later supported a second format where you can specify a comma-separated list of promotion choices. If a comma occurs in the promoChoice it then only considers a piece ID a match if it occurs as a sub-string surrounded by commas.