Comments/Ratings for a Single Item

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?

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.

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. 

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

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.

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

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

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.

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.

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:

Indeed, that cannot be right. The code that was appended to the Post-Move sections should have placed a white Pawn on d4 in this case, as 'victim' was not empty (@) here, but a black Pawn.

If you would post a link to the preset, I can try to debug it.

I am grateful for the code to turn off the display of captured pieces - I added it and it works.

...I think you want to add the captured piece to the origin square of the piece that moved and flip its side. 

This is exactly the goal of Conquer. Unfortunately, I have no idea what the required code should look like - I'm not a programmer ( you remember: 'That's a part of life. We don't all have the same capabilities or inclinations').

Do you have any idea what the codes might look like? Would be nice if.

It would look like a simpler form of what Shogi does, as it would move the piece to an already identified space.

if capture:
  set mynewpiece flipcase realname alias $old;
  add #mynewpiece $origin;
endif;

This should work if you're not using aliases:

if capture:
  add $old $origin;
  flip $origin;
endif;

It looks like the code for Shogi omits doing this in the stalemated subroutine, as moving a captured piece off-board does not affect whether the move leaves the King in check. If your game had check in it, you might have to deal with this in the stalemated subroutine. But since you don't have check, maybe putting the piece back on the board will not affect the evaluation of which moves are legal. In that case, it may not be essential to deal with it during the simulation of potential legal moves.

But since you don't have check, maybe putting the piece back on the board will not affect the evaluation of which moves are legal. In that case, it may not be essential to deal with it during the simulation of potential legal moves.

Indeed, this is exactly why it is sufficient to just do this at the very end of Post-Move. The preset was automated through the betza.txt include, not by fairychess.txt, so it needs different code to do that from what you give.

I run into a problem that I don't understand, though. The code I suggested, which Gerd put in the preset, relies on the variable 'victim' to contain the captured piece. But printing it shows it is always equal to @ at the end of Post-Move. Even when I print it directly after the only place in betza.txt where it is set:

  set victim cond != #desti #ori space #desti @; // no self!
print . #ori . , . #desti . , #victim;
print space #desti;

it prints @, both for #victim and space #desti:

d2,d4,@
@
e7,e5,@
@
d4,e5,@
@

But how can space #desti be @ on d4-e5 if the preceding move was e7-e5? I would have expected a Pawn there. The checkbox "Do Not Include Moves in Code" is ticked in this preset, so the Pawn should still be there.

it prints @, both for #victim and space #desti:

If space #desti is @, then victim will be set to @ no matter whether #desti and #ori are the same, because the cond statement will evaluate to @ either way.

But how can space #desti be @ on d4-e5 if the preceding move was e7-e5? I would have expected a Pawn there. The checkbox "Do Not Include Moves in Code" is ticked in this preset, so the Pawn should still be there.

Since your automatically generated code runs mainly in the Post-Game section, it works very differently than the code I usually write. I think Conquer would be simple to program in the usual way with the fairychess include file, but maybe it's not as simple for your automatically generated code.

It should be fixed now; it had to do with the betza.txt script treating normal capture of a piece that could be e.p. captured also as e.p. capture, which removed the victim before the destination square was examined for its occupant. I now made sure the destination square is never included in the e.p. squares, when e.p. rights are created.

This makes the problem go away, but it would still not 'recruit' an e.p.-captured Pawn (where the destination square is empty). So we need to expand the code appended to the Post-Move sections a bit, by having it start with the line:

set victim cond #imp p #victim;

This makes the victim a pawn (p) for any move with implied side effects. (Which here are only e.p. captures.)

Is there a way to make stalemate a win for the stalemated player?

Is there a way to make stalemate a win for the stalemated player?

Currently not. Is this needed? It would not be difficult to add. Unfortunately not in a backward-compatible way that is also logical, as currently the stalemate result is controlled by a GAME-code variable staledraw, shich by default is set to 1, and specifies a draw for any non-zero setting. When set to 0, it makes stalemating a win. I could make it suche that setting it to a negative value makes stalemating a loss.

Is this needed?

Not really. I was just looking and thought it should have been there. I don't know of any games that actually use it though.

The Duke of Rutland's Chess is one CV where stalemating the opponent results in losing the game:

https://www.chessvariants.com/historic.dir/rutland.html

P.S.: It may be an interesting idea for this CVP website for members (and/or editor[s]) to tag games where stalemate is either a win for the player giving it, and/or a loss for the player giving it. Baring an enemy king seems to be always a win if opponent cannot retaliate next move (if not a drawn case like for some chess endgames), and a tag for such might be considered too [edit: Losing Chess is close to being an exception].

Misère, Anti-chess, Codrus Game, Take Me Chess, Duck Chess, That one couchtomato's variant shared in Discord at 14/11/2021 (this one is prob a mistake tho), Quinquereme Chess, Teutonic Knight's Chess, Mainzer Schach, Ghostarelay, etc.

I was aware of Duck Chess, but because this needed an alternative search routine in the AI of the Interactive Diagram, I just hardcoded the rule there. And the generated GAME code would not work anyway, as it is a multi-move game. (And it is a 'never happens' case there anyway.)

In the ID the obvious way to specify it would be staleMate=loss. In the GAME code I could make it configurable through staledraw = -1, and make the Play-Test Applet generate that when it was specified in the ID. There would have to be a pull-down menu on that page for configuring the stalenate result then; a checkbox would no longer be enough.

BTW, the only practical consequence of this rule seems to be that some KPK end-games with edge Pawn can now be won. Usually not even the strong side cannot force the weaker opponent to stalemate him, and having stalemate a draw is already enough deterrent for the strong player not to do it. Losing Chess is of course an exception to this, as even a weak player can force a lot because of the mandatory capture.

This page really needs a button or link (somewhere in the last two paragraphs before "Alternative code for handling the mouse") to send to a blank GC preset page in a new window.

I have wondered if a blank GC preset page (or Settings File) exists or can be created (page not being quite the right word for it, though I don't know what is, other than just calling it a preset, period). Except for the first one ever made, after Fergus made Game Courier, when there were zero presets. I have always just altered a preset made by someone, including myself, to begin making a preset for a CV of mine.

That's probably the easiest route currently. But if a blank one isn't possible, maybe the link can go to a preset for orthodox chess.

I have wondered if a blank GC preset page (or Settings File) exists or can be created (page not being quite the right word for it, though I don't know what is, other than just calling it a preset, period).

There is no blank preset, but there is a default one with only default values. Just go to https://www.chessvariants.com/play/pbm/play.php without a query string.

That's precisely the link I was asking for. If H.G. would just (please!) put it into the article, I'd find this much, much easier.

But it has nothing to do with the Wizard for GAME Code Generation. Why not just look on the Game Courier page, where there is a link to it?

But it has nothing to do with the Wizard for GAME Code Generation.

Doesn't it? Is it actually less important of a step than using the Play-Test Applet, which does have a link?

Why not just look on the Game Courier page, where there is a link to it?

Why not have a link here, where creating GC presets is already under discussion, than just assume that anyone would know where to look?

Is it actually less important of a step than using the Play-Test Applet, which does have a link?

I never use this Wizard to generate presets, but I presume that using the Play-Test Applet is actually a step in using the Wizard, whereas starting with the default preset is no more of a step in this than having a blank canvas is a step in generating AI art.

Why not have a link here, where creating GC presets is already under discussion, than just assume that anyone would know where to look?

This page is about using a Wizard to generate a preset for you. It is not about making your own from scratch. For that, I would refer you to the Game Courier documentation and various tutorials.

The Wizard generates GAME code. It does not create a preset.

For generating the preset additional information would be required. Such as the name of the game. I suppose I could add a field where you could enter that, and a button for creating a preset of that name.

For generating the preset additional information would be required. Such as the name of the game. I suppose I could add a field where you could enter that, and a button for creating a preset of that name.

That could be done, or just take the text "Invoke the preset" and add "(click here to start)" or some such. The simipler the better.

This is just a testimony. I'm not a champion in coding and sometimes I don't understand 100% of what I'm doing, but the Wizard is really very good to generate a game code for GC. I have done it for Bigorra, for Camel Decimal Chess and yesterday for Patchanka. The only difficulty I had is when I have several different promotions to manage. I had to use the "morph" instructions and this is not given automatically by the Wizard. I solved my difficulty by copying from the Bigorra's GC where that issue had been solved for me by someone else.

What I found strange in the full process of submitting a new game with "all features inside" is to write 1) a regular page for presenting the game (in which I now put the ID in the Setup section) like this one; 2) a page "play" for presenting the GC preset where some information is duplicated, and the diagram is often shown with wrong pieces as it uses default pieces, like this one; 3) the preset itself where the Wizard is helpful indeed, like this one.

Maybe the process could be simplifed a bit, for instance I'm not sure that the page 2) is really useful.

I do not discard also that I'm doing something not optimal. I have often the feeling that Fergus, HG you are doing your best to help us (and you do it very nicely and kindly) but you do not always realize how much things looking simple for you can be difficult for common people with no specific education in coding.

2) a page "play" for presenting the GC preset where some information is duplicated, and the diagram is often shown with wrong pieces as it uses default pieces, like this one;

I never tried to publish a GC preset, but it seems to me that the diagram that is shown on that page is entirely the responsibility of the user. So if it doesn't show the same pieces as what the actual preset uses, it is because you ordered it to show different pieces.

You could even use an Interactive Diagram on that page, instead of a static one from the Diagram Designer. I recall that I made such a substitution on several GC pages, for variants that only appeared to exist on this site as GC presets, without a real article describing the rules. (Matts Winther's variants are typically presented like this; the GC page links to his own website for the rule descriptions.)

I agree that in most cases this page is entirely redundant, and just an annoyance to the user. There might be a reason for it if the same variant has multiple presets with different piece representation, to give the user a possibility to pick the representation he prefers.

Thanks HG. After all, there is no real need of a diagram at all in (what I call) page 2. So I have modified the cases which were showing a diagram with a wrong piece set. I have removed those faulty diagrams.