Comments/Ratings for a Single Item

I forgot about the preset H.G. made:

https://www.chessvariants.com/play/pbm/play.php?game%3DJumping+Chess%26settings%3Djumping&submit=Edit

Is this ready for me to post?  It looks like everything is correct except for highlighting moves that wouldn't be allowed when a mandatory edge capture is available.  (It still doesn't let you actually make the illegal move, so that's good enough.)

@Fergus - What would be the best way to manipulate the $legalmoves array, if I want to remove some moves that in hindsight must not be highlighted after all? Would the following code work?

set tmp $legalmoves;
setsytem legalmoves array; // clear the legal list
for m #tmp:
 if fn SomeTest #m:
   setlegal m;
 endif;
next;

You made a typo. setsytem should be setsystem. With that fixed, it looks like it would work. Since the documentation did not mention that it would work, I updated the documentation. But it will work only for legal moves described as arrays of coordinates for $legalmoves. It will not work for legal moves entered as strings.

Zone confinement now also works for the highlighting, with the aid of the 'user-supplied' BadZone function. And I have implemented non-final-leg e.p. capture in the betza.txt include file now, so that works too.

Only remaining imperfection is that when an edge capture is mandatory it still highlights other moves.

OK, that should simplify highlighting of legal moves. But the rule that (some) captures are mandatory actually is another global rule that creates a difference between legal and pseudo-legal. In Losers Chess this rule has lower priority than the checking rule, here it seems to have higher priority, even when the checking rule would be employed. Pseudo-legal highlighting will be easy here. It will still require me to put a 'hook' into the general code with which a user can interface his own code for the zone confinement; I will make this a function call that passes the full move (fromSqr, toSqr, locustSqr, dropSqr and droppedPiece), which returns whether the move is pseudo-legal, but for efficiency will only be called when a global flag 'zonal' is set.) Besides confinement, such a user-supplied function can also be used for enforcing restrictions what peiec types can capture each other.

It has been useful to attempt this, because it made me discover that the Diagram code had suffered a regression: the Betza compiler used to flag which pieces are inversion-symmetric, so that the GAME-code generator in the wizard page could draw on this to decide whether separate table entries should be made for white and black pieces. This code had disappeared!

I am now thinking how the general GAME-code in the include file could be enhanced in order to interface with variant-specific code. Rule enforcing is in general easy, as when there are extra global rules that outlaw some pseudo-legal moves, you can just test for compliance to these independently of the normal code (e.g. before you call the latter), and 'die' if they are violated. But legal-move highlighting requires such a compliance test to be called from somewhere deep inside the standard code, after the MakeMove of of every pseudo-legal move. Normally the code only does a check test there, and pushes the moves to the legal list when it doesn't expose the King.

The problem with mandatory capture is that you have to know in advance whether such a capture is possible to judge whether a non-capture (or in this case also a non-mandatory capture). An obvious way to do that would be to first make a list of all moves that are legal ignoring the rule, and then test whether there is a mandatory one amongst these. If there is, all non-mandatory moves should be purged from the list. This could be done entirely after the standard code. If I would know how to revoke a previous setlegal command.

@Fergus - What would be the best way to manipulate the $legalmoves array, if I want to remove some moves that in hindsight must not be highlighted after all? Would the following code work?

set tmp $legalmoves;
setsytem legalmoves array; // clear the legal list
for m #tmp:
  if fn SomeTest #m:
    setlegal m;
  endif;
next;

I have another question about GAME-code syntax. In

if fn F X or B:

would this be read as if( B || F(X) ) or as if( F(B || X) )?

Very nice!

The goal is definitely to capture the king because subvariant 6 is to play for checkmate rather than king capture, but that seems needlessly complex.

This is a quick approximation:

https://www.chessvariants.com/play/pbm/play.php?game%3DJumping+Chess%26settings%3Djumping&submit=Edit

It enforces the rules (except that e.p. capture does not work, but this would have to be solved in the included library file). It doesn't properly highlight legal moves, though.

It is not clear to me whether this variants employs the check rule; the explanation of mandatory capture suggests it has not, as it talks about capturing the King. An alternative would be to consider the position a checkmate, as you only can do the capture with the edge piece, and it does not resolve the check.

The betza.txt library should have some feature similar to the BadZone hook for the Interactive Diagram, where the user can define a function to enforce confinement of pieces to zones. When such a function is defined each generated move should call it to check whether the move obeys the confinement rules.

Well, the idea was of course to let the GAME-code wizard do most of the work, starting from an Interactive Diagram made through the Play-Test Applet. It took a few minutes to create this with the Applet:

which does take care of the piece moves. (But not of the zonal confinement / mandatory capture.) Which has one defect, though: the e.p. capture does not work when specified on a non-final leg. At least in the move generator used for highlighting, the AI could be more accurate. I recall encountering this issue many times during programming the stuff, and each time I thought "a locust e.p. capture? Nah, that will never be needed." Obviously I was wrong. So I might have to shape up the move generator here and there, also the one I wrote in GAME code. The move tables the Betza compiler generates for this are OK, but the code that interprets them unjustly assumes an e.p. leg always is the last leg of the move.

Enforcing the rule that non-captures cannot go to an edge in the GAME code is pretty trivial; the mandatory capture is more tricky, though. In particular in combination with legal-move highlighting. I guess it would be useful to extend the move generator in the GAME-code include file with a task that would test whether there exists a legal or a pseudo-legal capture, very similar to how it checks whether there exists a legal move. Perhaps the existing code can be used for that, by introduction of a global flag that tells it to ignore non-captures. The Post-Move code for the latest move of the game could then start calling the move generator for this task for all pieces on the edge, if the move in question was a non-capture or did not start from the edge. Existence of a capture from the edge would then make the move illegal. In other cases the mandatory-capture requirement is fulfilled, and the standard procedure (which doesn't take it into account) can be called.

BTW, the Diagram's AI does think the Knight is worth more than a Bishop. For each capture target the Knight also has two possible final squares.

As far as I got it, the only unusual aspects of this variant is the piece confinement and the mandatory capture. So it should not be that difficult. The only special-purpose code that is needed would be for rejecting moves that end on an edge square and do not specify a locust victim (which could be added as the end of the Post-Move sections), and for apparently pseudo-legal moves with non-edge pieces or non-captures with edge pieces, a test whether any of the edge pieces has a capture.

Ok, perhaps I should have said it would be very difficult for me...

I have added full support to ChessV though.  This required a couple of special rules, but I added support for basic capture-by-overtake to the internal move generator.  My quandry now is what the pieces should be worth...  The Rook, Bishop, and Queen are modified in the same way so I assume their relative value should be similar to Chess... The board is enlarged, but use of the outer ring is limited and landing on it hurts your options on the following move significantly, so I think the values should probably not change much from 8x8 values.  The Knight is interesting - he has a choice of captures, so maybe his value is augmented.  The Pawn, when capturing, moves forward two spaces instead of one, getting it to the other side faster, so maybe it should be worth more as well.  But these are just guesses.

EDIT: Upon further consideration ... the Knight has a choice of captures, but no choice where he lands.  The Bishop, Rook, and Queen, though, unlike in Chess, can capture and still choose which square to land on (if there is space.)  So maybe the Knight is not more powerful.

A rule-enforcing preset would be nice, but that would probably be pretty difficult.

As far as I got it, the only unusual aspects of this variant is the piece confinement and the mandatory capture. So it should not be that difficult. The only special-purpose code that is needed would be for rejecting moves that end on an edge square and do not specify a locust victim (which could be added as the end of the Post-Move sections), and for apparently pseudo-legal moves with non-edge pieces or non-captures with edge pieces, a test whether any of the edge pieces has a capture.

The page for this contest-winning game hadn't been updated in twenty years, so I thought it was about time. I've upgraded the graphics to be anti-aliased. All images are now dynamically generated by the diagram designer. A navigation menu has been added. ASCII diagrams have been removed. Made a few minor edits, such as removing the request to vote in the contest and adding a note that this game was the winning submission.

A rule-enforcing preset would be nice, but that would probably be pretty difficult.