Comments/Ratings for a Single Item

For now I have solved this as follows: when a move is indicated as an initial one, it will still be rejected if the mover is not virgin. But if it is, it will be tested whether the mover is in an array inocheck, which by default is set to (K k). If it is, this will add the origin of the move to the set of e.p. squares. And hence consider it illegal if that square is under attack after the move. If you want to forbid any other piece to use inital moves when attacked, or when your royal does not have the label K, or you have multiple royal types, you could set the inocheck array to contain the types you desire.

As dicussed this can in theory fail in the presence of hoppers. Although it is extremely unlikely that you would ever want to play an initial move designed to get you to safety to stay in the path of a hopper. Anyway, it seems to solve the problem with the game you mentioned, as this now says 'checkmate!' above the board. It is also not possible to have both initial moves that can, and that cannot move out of check on the same piece.

About your implementation of that preset: it is not necessary to build the in-check dependence into the move list of the King that is used when the argumet to the K or k function is 0. This call only has to generate moves with an implied side effect, i.e. a change of the board state not explicitly expressed in the move eneterd by the user. This is used when playing out the moves of the game for the purpose of setting up the current position, to make sure the side effects are properly applied, but where there is no need for testing the (pseudo-)legality of the moves. As this would presumably have been done before the move was allowed to be appended to the game. Normally the only moves that do have side effects are e.p. capture and castling. So there is no need to generate other initial King moves than castling in that case; the extra moves you defined do not have side effects.

it is not necessary to build the in-check dependence into the move list of the King that is used when the argumet to the K or k function is 0.

I don't understand this part. Is it about the number at the end of the K definition? I had the checked check there because the normal King move (with castling and leaping) had different numbers.

Indeed. There is no need to generate anything else there than the castlings. And for castlings the code would know that you cannot do those while in check anyway. So you can simply return the index of the castling moves in legdefs in the second case.

What would be a good method (if there is one) to use this to make Alice Chess?

I am not sure that this is feasible. Alice Chess is basically a 3-dimensional variant (with 2 levels), where all pieces have two-leg moves where the seccond leg changes level, and which are lame or (locust-)capturing by their orthodox move in the first leg. But the code in the include file used by the wizard assumes 2-dimensional boards.

Of course you can map the 3d board onto a wider 2d board (16x8, or perhaps 18x8 to allow a dead zone in between the boards that even Knights cannot cross, deleting the squares in that guard zone from the board in the Pre-Game code). And then define all moves as 2-leg moves that have a (dx, dy) = (+-18, 0) leap as second leg. There is no way to describe that in Betza notation, so the Interactive Diagram could not be used to generate the legdefs array with move definitions. But you could of course write that by hand. Either from scratch, or by adapting the code generated for orthodox chess, adding a second leg to each move. E.g. the Bishop in orthodox Chess would have

1 99  1  1     3 // bishop(104)
1 99  1 -1     3
1 99 -1 -1     3
1 99 -1  1     3
0

and this would have to be changed to

2 99  1  1     3 // bishop(???)
   1 18  0     1 
2 99  1 -1     3
   1 18  0     1
2 99 -1 -1     3
   1 18  0     1
2 99 -1  1     3
   1 18  0     1
2 99  1  1     3
  1 -18  0     1
2 99  1 -1     3
  1 -18  0     1
2 99 -1 -1     3
  1 -18  0     1
2 99 -1  1     3
  1 -18  0     1
0

And you would have to determine the new starting index for Bishop in this array, and put it into the B and b function definitions instead of 104.

I am not sure whether this would have the desired effect for castlings and e.p. captures, though. (Or indeed how the latter are supposed to work in Alice Chess in the first place.)

Some time ago I tried using the game code wizard to make a preset for a large (18x18) game using a few crooked sliding pieces. Now I notice that one of them, the Hornet from Seenschach, works in the applet but not in the generated code. The way I defined it was Wafs(alar)7Wafsal(aral)7WzB. Part of the move works, but the zB seems to be ignored, even though the generated code appears to include those moves as well.

https://www.chessvariants.com/play/pbm/play.php?game=Skica&log=sissa-arx-2022-289-168

We're having a problem with this game. On move 17, the pawn on g6 is captured when it shouldn't be. This seems to happen no matter what move white makes.

Daniel Zacharias wrote on 2022-11-16 UTC

https://www.chessvariants.com/play/pbm/play.php?game=Skica&log=sissa-arx-2022-289-168

We're having a problem with this game. On move 17, the pawn on g6 is captured when it shouldn't be. This seems to happen no matter what move white makes.

Should be fixed now. Turned out e.p. squares were never cleared until another double push was made. Apparently g8-g6 had been the latest double-push, so when a Pawn then captured to g7... Amazing that no one ran into this problem before.

Generated-code games are now giving an error saying "You may not set $extralegal with setsystem."

Generated-code games are now giving an error saying "You may not set $extralegal with setsystem."

That's now fixed. I changed the line setsystem extralegal #xtl; in betza.txt to setsystem legalmoves merge $legalmoves #xtl;. Since $extralegal did not appear in any individual presets using this include file, nothing more needed to be done.

I suppose a good way for defining how pieces morph into other types upon reaching a certain board square would be the following:

set morphers (X Y Z);
set morphs assoc
  X (0 0 0 0 0 0 0 (All Q))
  Y (0 0 0 0 0 0 0 (R N B Q Q B N R))
  Z (0 0 0 0 0 (All B) (All R) (All Q))
;

In this example X, Y and Z are piece labels of promoting pieces, and the morphers array specifies which pieces can morph. The associative array morphs would then define an array for each of those, to specify on which ranks they morph, and if they do, where on the rank to what. The ranks are tabulated low to high, and a 0 would indicate nothing happens on that rank. If there is morphing, for each square on the rank it is specified to what piece type. Or, if the first element is All (assumed to be not a valid piece label), the second element applies to all squares of the rank.

So the example (for an 8x8 board) shows a piece X that promotes to Q on 8th rank, a piece Y that promotes to the piece that started on the promotion square on 8th rank, and a piece Z that promotes on the last 3 ranks, to B on 6th, to R on 7th and to Q on 8th.

yes, it looks clear. I guess it is not implemented yet because I tried it right now for Bigorra and no promotion occurs.

Question: in the case of my Troll which promotes only when moving 1 square, how it will work?

I will try to put it in the betza.txt include file tomorrow. Perhaps we should reverse the order in which the ranks are tabulated, starting at the promotion zone. Then you don't have to start with so many zeros. Pieces tend to morph on the far end of the board, and everything beyond the end of the array could be considered a zero, so that you wouldn't have to write so many zeros.

For the Troll I suppose the preset will still need some dedicated GAME code in the Post-Move sections, to suppress the promotion if rank #ori (the rank the piece moved from) equals 12 (or 3). In the ID you can exclude some moves in the Betza descriptor from application of the morph, by suffixing them with a quote. (So the Troll move is G'H'fmWfcF, which would suppress morphing on the G and H move.)

I uploaded a new version of the betza.txt GAME-code include file now, which tests for the presence of morph arrays in the HandelMove routines, and performs the promotion instructions these convey for altering the piece type. This works slightly different than mentioned before, because it has to account for the possibility of an asymmetric game, where the black morphs are not automatically implied by the white ones. So the morphs have to be specified for each color separately.

I tested this now, and it looked like it would work on square boards. (Unfortunately GAME code itself is broken for non-square boards, so it doesn't work there yet.)

For the white specification the ranks are now mentioned from high to low, and there will be no morphing on ranks that are omitted. This to save the user the trouble of writing many trailing zeros for all the ranks where nothing happens, if morphing only takes place near the promotion zone. (Which is usually the case.) So the example I gave before should now be specified in the pre-game code as:

set wmorphers (X Y Z);
set wmorphs assoc
  X ((All Q))
  Y ((R N B Q Q B N R))
  Z ((All Q) (All R) (All B))
;

set bmorphers (x y z);
set bmorphs assoc
  x ((All q))
  y ((r n b q q b n r))
  z ((All q) (All r) (All b))
;

Note the double parentheses: the inner pair encloses the square info on a rank, the outer pair encloses a number of ranks (even if only one rank needs to be specified). A bare 0 between the outer parentheses can still be used to indicate a rank where nothing happens. For a symmetric game the black specification only differs from the white one by having all piece labels in lower case, and the array names strating with b instead of w.

A future version of the Play-Test Applet will append this automatically to the generated Pre-Game code for converting any morph parameters that were specified in the converted Interactive Diagram.

My apologies for those who might have already tried to use this feature: I changed it again, in order to simplify the code, and make it more efficient for other purposes the morph parameter has in the Interactive Diagram, namely confining pieces to a board zone. There are now no longer separate morphers and morphs array for each color, but they must be combined into one:

set morphers (X Y Z x y z);
set morphs assoc
  X ((All Q))
  Y ((R N B Q Q B N R))
  Z ((All Q) (All R) (All B))
  x ((All q))
  y ((r n b q q b n r))
  z ((All q) (All r) (All b))
;

The rule that the ranks should be listed starting at the promotion zone (so high to low for white pieces, low to high for black) still applies.

The idea is that a future version would allow you to specify the words 'barred', 'check' or 'win' instead of the label of the piece to promote to; this would then (respectively) ban moves to the corresponding square, treat reaching the square as a check to the opponent (so that he loses when he cannot remove the piece from that square in his next turn, but wins when he captures your King), or terminate the game immediately as a win (without having to worry about possible retaliation against the piece that reached the square, or your King).

I've tried it on few pieces for Bigorra (Knight, Camel, Giraffe) and it seems to work. I will try with more later. I will have to see how to deal with the Troll after this. Thanks

For the Troll you can leave it out of the morphers array, and append to the Post-Move 1 section something like:

if #mover == TROLL and == 15 rank #desti and == 14 rank #ori:
  add DIREWOLF #desti;
endif;

and in the Post-Move 2 the corresponding code for black:

if #mover == troll and == 0 rank #desti and == 1 rank #ori:
  add direwolf #desti;
endif;

It doesn't work.

I've tried

if #mover == TROLL and == 15 rank #desti and == 14 rank #ori: add DIREWOLF #desti; endif;

and

if #mover == T and == 15 rank #desti and == 14 rank #ori: add DW #desti; endif;

None of them works. The GC can be played but the Troll doesn't get promotted.

Sorry, my bad. You are correct that you have to use the labels you use for these pieces in the preset (I did not know those, so I used the full names). But in GAME code the operator has of course to preceed both operands, and I wrote the == between them. What I intended to write was

if == #mover T and == 15 rank #desti and == 14 rank #ori: add DW #desti; endif;

THANK YOU HG. That's great. It works. I think I now have the full GC for Bigorra, thank you for your help.

When I test this GC, every time I move one piece, I have to wait about 6 seconds before I can move a piece from the opposed side. Do you know why it is so long? Is that because the board is large and there are many pieces?

When I test this GC, every time I move one piece, I have to wait about 6 seconds before I can move a piece from the opposed side. Do you know why it is so long? Is that because the board is large and there are many pieces?

Indeed, because of the generality the GAME code generated by the Play-Test Applet is not very fast, and for huge games this can become very noticeable. When used for playing a game on-line between two different people 6 sec processing time for a move is not really a problem. When playing against yourself for testing I can see it would be a nuisance. Game Courier does impose a time limit on the processing of a move by the GAME code, though, and when we would exceed that limit the preset would no longer work.

Most time consuming is usually the move highlighting; the GAME code always calculates all moves of all pieces in the latest position, in order to hide a list of those in the page the user gets to see after having submitted a move. So that when he clicks a piece on that page the moves of that piece can be highlighted instantly, without further communication to the CVP server. But it is wasteful, as of all pieces usually just one will be clicked, and the moves of all othe pieces would have been generated in vain. Especially with fully legal highlighting (which I think is the default) preparing the move list is a lot of work, as every possible move has to be tested for exposing the King, which it must do by generating all opponent moves after the move has been made. So if each side has ~100 moves, it will need to generate ~10,000 moves in total to figure out which of the 100 moves are legal. (Of course most moves would not expose the King, but you can only know that after you have tried all opponent moves, because any you haven't tried yet could still hit the King. When a move is illegal you could discover that much sooner, perhaps even on the first reply you tried.)

If you are satisfied with pseudo-legal highlighting it would be much faster. You would have to append to the Pre-Game section:

set pseudo 1;

for that. But this would also highlight moves that leave your King in check. Game Courier would still reject those moves, though, if you actually try to play one.

Another time-critical task is detection of checkmate, in positions where you nearly deliver one. This test only has to run until it finds a legal move, but if there are very few of those you will have to judge many other moves before you stumble on the legal one. And for all these moves many opponent moves might have had to be generated before you stumbled on the King capture that made them illegal. In one of Aurelian's games this actually made the preset exceed the time limit, in an unfavorable case. I improved the situation a bit by giving priority to generating the opponent moves of the piece that captured the King on the previous move we tried, but it can still take a long time.

It would be nice if the highlighting could be delegated to an Interactive Diagram in the Game Courier page. The GAME code would then not have to generate a complete list of legal moves, and by generating those locally with the Diagram there would be no need for communication with the CVP server to highlight the moves when the user clicks a piece. So you still would have instant response for that, as the processing time is also small, since only the moves of that clicked piece would have to be tested for legality. But I don't see that happen.

Sounds very promising. But I'm a little unsure about your [edit]; '...and set the parameter checkrule to 0 at the end of the Pre-Game section. And then add a few lines of custom code at the end of the Post-Move sections for automatically placing the color-flipped capture victim on the square of origin.'

I'm afraid I won't be able to manage it.

I'm afraid I won't be able to manage it.

I didn't expect you would, but if you think it is worth to go this way I can tell you what you should add to a preset for 'nocastle' chess automated with the Play-Test Applet in order to make it play Conquer. In particular at the bottom of the Pre-Game section you can add

set checkrule 0;

to indicate that the king can be exposed and must be captured to win. Then at the bottom of the Post-Move 1 section you can try

if != @ #victim:
  set victim toupper #victim;
  add #victim #ori;
endif;

and to the Post-Move 2 section the same with tolower instead of toupper. I think that should do it.

...to go this way I can tell you what you should add to a preset for 'nocastle' chess automated with the Play-Test Applet in order to make it play Conquer.

I would like to go this way, but I can't get any further with the preset for 'nocastle' chess. Where am I wrong?