Comments/Ratings for a Single Item

Instead of 32 pieces, there are now only 31 pieces on the board. That doesn't fit with Conquer.

Given the rules of the game, you need code for processing the captured piece after it is captured. When a capture has been made, I think you want to add the captured piece to the origin square of the piece that moved and flip its side. You should do this for both actual moves and potential moves. You would also want to turn off the display of captured pieces with this code in the Pre-Game section:

setsystem capturedpieces false;

I understand that, but the following simple situation can't be right:

Instead of 32 pieces, there are now only 31 pieces on the board. That doesn't fit with Conquer.

Well, I don't know what is the purpose of displaying the captured pieces; as I said, displaying them has no effect on processing of the game by Game Courier, and in most variants it is mostly redundant information, as what was captured can be deduced from what is still left on the board. So one suspects that it is merely a visual aid to the players and observers to easily see the material balance.

The way GC calculates it (difference between current and initial board population) does not make it perfectly suited for that purpose, though, since pieces can disappear from the board in other ways than capture. In particular, after a promotion it would count the Pawn as 'captured', even if no Pawn was captured at all, and it would no longer show the resulting Queen as captured, even if a Queen had been captured. And it has no provision for indicating a negative difference if the original Queen was still around.

In a game like Conquer a negative material balance will occur quite often. If a visual aid for judging that balance should probably show the difference between the white and black population of the current position, presenting negatives as pieces of the opposit color. According to Fergus it should be possible to overrule the default presentation with GAME code, but I would not know how, and I don't think it would be worth it anyway.

If I understand correctly, no captured pieces may be displayed (and removed from the board) in Game Courier, as all captured pieces are added to the capturing party (in Conquer, of course).

Ah. Anyway, since what is shown does not affect the game, I don't understand what the problem is.

While captured pieces are shown automatically, this can be controlled in the code if the default manner of handling captured pieces does not fit with the rules of the game.

'Captured pieces' are something that Game Courier shows automatically, but has no effect on the playing of the game. What is shown is not controlled by any user-supplied code; it is just the difference between what is on the board now, and what was there at the start of the game.

Hopefully I have implemented it correctly.

It works, but not always, as the captured pieces show.

[Edit] I have now played a few games where there were no problems.

[Edit, Edit] Now another game with captured pieces. 

I am not sure what you men. You did use the Play-Test Applet to create a rule-checkinf GC preset before, not? So just set up a board for normal chess, alter the King move to plain K to get rid of the castling, and ask for the GAME code.

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

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.

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.

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.

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?

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;

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.

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;

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

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

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

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

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.