Comments by HGMuller

Perhaps this can just be a forced no-op, as a non-promotion would just leave the piece as is.

I already made it such that forced non-promotion in the morph can be achieved by specifying promoting to the piece type itself. Before this was excluded, to allow two pieces using the same ID (and presumably the same image) to morph into each other (to emulate a location-dependent move). By excluding the self it would then automatically pick the other. But there wasn't any use in also forbidding it if there only was a single piece with that ID. So this is now allowed.

Forced Shogi promotion is really redundant: you can just mention the oppromoted type. The possibility to use comma separation in a row of the matrix allows this even when the ID of the promoted type is something like +L.

@Fergus - I have a problem with the following GAME code:

  set royal array; // empty array
  do while < #i count #myroyal:
    set type elem #i #myroyal;     // next royal type
    set cnt elem #type piececount; // count them
    if #cnt:
      set nr + #nr #cnt;
      push royal #type;
    endif;
    inc i;
  loop;

The purpose was to make (from the array 'myroyal' of royal types) an array 'royal' of royals that are actually present on the board. The problem is that 'cnt' doesn't get the value zero when the key '#type' is not in the array. So the "if #cnt:" is always satisfied, and the non-present royalas get listed in the array 'royal' as well.

How could this be solved?

[Edit] I did find a solution: use "if + 0 #cnt:" instead of "if #cnt:". Apparently dereferencing a variable with value 'undefined' produces a text string, but using it as an arithmetic operand treats it as 0.

@Daniel - It appears this solves the problem in the preset, which was caused by the first piece type mentioned in the 'royal' array being a Pr, which was not present in the initial setup.

OK, I see. The move Ki10-h10 is ambiguous, as it can both be a fast castling and a normal King move. And the preset doesn't let you resolve that ambiguity. I suppose the fact that it thinks it can be a castling is an additional bug, as the King has already moved. I will have a look at it soon.

Can you be more precise about where you see this error? I did not see it when I checked the preset for this game.

I already fixed this. It was the issue with the hashtag on an undefined variable resulting in a string.

Note that the Sjaak II engine is configurable for drop variants. It could be that Nebiyu is too (as I know it to support mini-Shogi). CrazyWa is not configurable, but it is open source, (a C program), and can probably easily be adapted to play Seireigi: it is an engine designed for playing drop variants, and already supports Wa Shogi.

Since Fairy-Stockfish supports regular Shogi, I suppose it can be configured for other drop variants too. (Caveat: although Fairy-Stockfish is in general super-strong, it derives its strength in Shogi mainly from a trained neural network evaluating the positions. I heard that this increased its strength by about 1000 Elo over using the hand-crafted evaluation.)

Can't we present the nominations as a table, with columns that can be ticked for eeach of the facilities that exist for it? That would make it much easier to find one that (nearly) meets the requirements, and see what still has to be provided.

I suppose the information we list now is not completely up to date either; there exists an Interactive Diagram for Golem Chess (in the comments), and there might exist computer opponents that are far stronger than Zillions in cases where no Zillions implementation exists.

Especially nominations where the lack of a strong computer opponent is the only thing disqualifying them, this might be very easy to fix.

I now fixed the FastCastle routine in the betza.txt include file, so that it only generates the move if the King is still virgin. As it was it only tested that for the Rook. Normally the presence of an i in the XBetza castling definition would automatically suppress the move, but because of the way I encoded fast castling in betza.txt the original modifiers are no longer available in the preset. But I suppose it is safe enough to assume there will never be any need for a fast castling for a non-virgin piece.

This would have solved the problem in your game, because only one of the generated moves would have matched your K h10-i10 input. It does not solve the general disambiguation problem yet, when a virgin King would attempt a single step. This problem could also arise with O1 normal castling. I suppose 'capturing' your own Rook could be used to enter the castling, in that case.

Ai Ai is very weak. I think it even loses to the Interactive Diagram.

Affecting the initial state is somewhat tricky, because the Interactive Diagram is initialized with a certain delay. This to make sure the initialization routine can see all Diagrams on the page, and is not immediately executing after the page has been loaded enough to only see the first Diagram. So you cannot use the code you use later for altering a Diagram that you use in the buttons immediately.

The way I would do it, is first alter the mechanism by which you change things now, by letting all buttons call the same function (say 'AlterDiagram(n)'), specifying by the parameter n what should actually be altered. So AlterDiagram would contain a switch(n) statement, where each case does what you now have written directly in the button. Initially you can then call AlterDiagram with a random number as parameter (Math.floor(nmax*Math.random()). Or call it twice, once for the base variant, and once to choose the off-board piece.

The main difficulty is when to call it. You could call it with a delay larger than the betza.js script uses to call its Init() function, but that seems a bit risky in case the page lows more slowly than that (or future versions of betza.js use another delay). Now you can prevent that betza.js invokes the Init() routine at all, by, before specifying the URL to betza.js

<script>var scriptSeen = 7;</script>

(Betza.js uses this to make sure the Init() routine is only executed once, even if there are multiple links to the script on the page, such as could happen in a Comments page.) You then should arrange the Init() function to be called from your own code. You could do this through

<script>
function MyInit() {
  Init();
  var n = ...; // number of the random position you want to show
  AlterDiagram(n);
}
setTimeout('MyInit()', 100); // arrange MyInit() to be invoked 100 msec from now.
</script>

This guarantees that you execute the AlterDiagram() for picking the initially shown position only after the initialization has been done.

We will have to add additional opportunities for human on-line play (pychess.org, gamerz.net, freechess.org, chess.com), and for 'strong' computer opponents (Fairy-Stockfish, ChessV, Sjaak II, Nebiyu, HaChu, CrazyWa, KingSlayer...).

Since some of these engines are configurable, it would often be possible to supply game files for them, to use them for variants that are not in their standard repertoir.

Standard repertoir of Sjaak II:

• Normal chess (Jazz, Sjaak and Leonidas all play this).
• Spartan chess, where black and white play with different armies and black has two kings (Sjaak and Leonidas can both play this).
• Seirawan chess, where both sides start with an extra off-the-board piece that can be introduced later (Sjaak and Leonidas both play this).
• The Maharaja and the Sepoys, where white has only one piece (the Maharaja) (needs to be played as variant "fairy" in XBoard). In Sjaak II you need to load the variants.txt configuration file to make this variant available.
• Amazon chess, where the queen moves as an amazon (needs to be played as variant "fairy" in XBoard).
• Knightmate, where the king moves as a knight and the knights move as a king.
• Berolina Chess, where pawns move one square diagonal and capture straight ahead.
• Shatranj, a historic precursor of modern chess.
• Capablanca Chess, a variant played on a 10x8 board with two extra pieces.
• Gothic Chess, the same as Capablanca Chess but with a different starting position.
• Fischer Random Chess and Capablanca Random Chess, which are like normal chess and normal Capablanca chess, but with a randomised starting position (Sjaak does not generate a starting position, however).
• Makruk, the Thai version of Chess. ASEAN chess and Ai-Wok are supported Makruk variants.
• Pocket Knight, like normal chess, but players have an extra knight they can drop on the board.
• Grand Chess, on a 10x10 board.
• Indian Grand Chess, or possibly Turkish Grand Chess. On a 10x10 with four extra pieces.
• Burmese chess (Sittuyin), needs to be played in XBoard with legality testing off.
• Courier chess, a medieval variant played on a 12x8 board.
• Chinese chess (Xiangqi), Black and white face eachother across the river that runs along the board, with their kings confined to their palaces.
• Japanese chess (Shogi), where captured pieces can be dropped on the board to reinforce your own army. Also supported are a number of Shogi variants (sho-shogi, mini-shogi and tori-shogi).
• Traditional Mongolian Chess (Shatar), which has restrictions on how mate can be delivered.
• Omicron Chess, which is basically Omega Chess on a slightly smaller board.
• Omega Chess, a variant on a 12x12 (effectively 10x10 with four extra squares) board.
• Grande Acedrex, a large (12x12) mediaeval variant of chess with divergent pieces: the Rhinoceros/Unicorn (first as Knight, then as Bishop) and the Gryphon/Aanca (first as Ferz, then as Rook). Can be played by Postduif.
• Various minor variantions and challanges, including Peasant's revolt, Legan's chess.

I think this is a very good way to present a group of variants that is so closely related. But I still have a few suggestions for further improvement:

The gatable pieces start in the piece table, but this table starts closed, and it might not occur to the reader to open it. You can force a piece table that is open from the beginning by including <table id="KevinTable"></table>, e.g. where you now have the KevinList. (Which such an open table you would need to also include enableAI=2 in the diagram definition to keep the AI available.)

The board uses a square size 35x35, because that is the I.D.'s default, and you did not specify a size in the initial Diagram. But then you use 50x50 piece images. This is no problem, as betzaNew.js scales the images to fit the board size. (Unlike betza.js, which would do the opposit.) But this makes the piece table, which does not have such scaling, look unnaturally large compared to the board. Which would become all the more obvious when you would always display them side by side. You could cure that by using the alfaeriePNG35 set. (Or put squareSize=50 in the initial Diagram, but then board and piece table might be too wide to display side by side.)

Actually I like the way you solved the placement issue in the GC preset (gatable pieces starting in the center of the board) better than dragging the pieces from the table. But the I.D. doesn't allow it! Even though it would allow illegal moves in general, it does not allow moves to 'hole' squares. Perhaps I should allow those too? Or at least allow those for virgin pieces on the central rank(s)?

Instead of writing "choose your desired diagram" I would say "choose the desired setup". You should add some instructions for how to place the Griffon / Falcon / Manticore too before starting normal play (and opening the AI panel), especially if these come from the table. I guess I could have the I.D. suppress the AI from replying to moves that were not at least pseudo-legal (i.e. to non-highlighted destinations). Then it would not matter when you opened the AI panel.

I think it is site policy to have pages that only look acceptable for viewers with JavaScript switched on. So I think you should at least provide a static image of one of the start positions (and perhaps of all three), within <noscript> tags.

[Edit] I now made the proposed changes to the Diagram script. So it should be possible to start the gatable pieces on the central rank.

Note that draw is not possible in mini-Shogi. So it is a bit strange to say a position there is drawish...

Otherwise, I think the possibility of offering various variants in one diagram is very effective.

It is especially effective for 'combinatorial cases'. With 8 armies you would need 64 Diagrams to provide all combinations. The number of buttons required is 4 times smaller, and buttons are again much smaller than Diagrams. I suppose one could even do with 8 buttons here, using the convention that clicking the buttons alternately defines white and black.