Comments/Ratings for a Single Item

Re: Locust moves:

I think I'll stick roughly with what I have, with a slight change. I'll put the leap icon in the destination square, shade the target square black (rather than red, as I have it now), run a straight arrow through it, and include a text explanation. I'll try this out on a "Piece of the Day" on my profile before I do it here, though.

And due to that and other circumstances, I'll be starting in on these edits Monday or Tuesday.

OK, I got through the edits on most of your notes, H.G.

I'm not sure what the problem could be that you're having with the Bowman moving close to the edge; the nN part of the XBetza should handle that.

What I did get:

• The "morph" parameter on the Pawn, Soldier, and Sergeant
• Fixed the Sergeant's sideways move in the ID
• Redid the diagrams for Bowman, Helepolis, and Nightrider
• Clarified the text descriptions for the Berserker and King
• Deleted the Pawn-line strategy (it turns out, that's good advice for most chess games -- or at least that's how the ID plays -- so it's not that important.)

Still need to:

• Fix the text for Bowman, per notes
• Possibly another try with the Helepolis diagram
• Figure out if there's any way to code in the Royal promotion
• Figure out if the Berserker might be more easily coded as [K?K]NAD
• Explore similarly simple ways to code the Wizard's move ([F?fW3], perhaps? Plus the position-switching code, of course), then clarify the text based on what I find and per notes.

The problem with using nN as a separate move is that this move will also be available when the distant N2 square does contain an enemy piece, and thus makes the capture optional. The verbal description suggests that the capture should be a mandatory side effect.

To force the capture if one is possible only moves that make the detour should be available. But you must also make sure the move is not blocked if the detour is off board, or hits a friendly piece. This can be achieved by explicitly allowing these, by granting o rights next to the c rights for the leg that hits the detour square, (which takes care of the off-board case), and allow it to hop over a friendly piece. Unfortunately the Betza p modifier does not distinguis friend or foe, but friendly hopping can be achieved through the kludge of specifying d mode (for friendly capture), with an unload u on the following leg to undo this. But the necessity for this u prevents combining it with the move that must capture an enemy, as you would not want that to be put back. So you end up with something like afcoabNafdabuN.

This is of course awful, which is why I suggested to introduce cc as a shortcut for such 'mandatory if possible' locust captures, so the above could be written as afccN. But I did not implement that yet.

As it is, moving the Bowman crashes the ID. This probably has to do with the way I implemented n on oblique atoms; I will look into that later.

[K?K]NAD would include a lot of duplicat move specifications. Which is not really an error as far as XBetza goes, but undesirable for the ID as it slows down the AI (which would search all duplicats as well). For clarity I would recommend KNAD[cK-K][mcK-bK]. This would separate normal, hit-and-run and rifle capture/turn pass, which people tend to percieve as independent modes of capture.

[F?fW3] or even [F?fsW3] do not work (yet). The bracket notation, which strictly speaking is not XBetza but Betza 2.0, is still in development, and the ID only implements it in the most rudimentary form. (Where it ignores the direction implied by the atom of a continuation leg, purely relying on the directional prefixes, and only allows range 1 or infinite.)

The problem with using nN as a separate move is that this move will also be available when the distant N2 square does contain an enemy piece, and thus makes the capture optional. The verbal description suggests that the capture should be a mandatory side effect.

   I need to fix the text description. It's supposed to be optional.

As it is, moving the Bowman crashes the ID. This probably has to do with the way I implemented n on oblique atoms; I will look into that later.

   I did notice this, yes. I'd assumed that it was something I'd done wrong, but I'll give you time to work on that, then recheck the move tomorrow.

[F?fW3] or even [F?fsW3] do not work (yet). The bracket notation, which strictly speaking is not XBetza but Betza 2.0, is still in development, and the ID only implements it in the most rudimentary form. (Where it ignores the direction implied by the atom of a continuation leg, purely relying on the directional prefixes, and only allows range 1 or infinite.)

   I'll figure out something else to deal with the Wizard's move, then. (It's supposed to be blockable only along the given path.)

The problem with the Bowman is that n on an oblique leap is only recognized as multi-path lame for single-leg moves, in which case it triggers some special code during the parsing of the move to convert the leap into a sequence of steps in all possible geometrically shortest ways. In multi-leg moves it still only results into setting of a flag on the leg in question to indicate it is lame. When the move generator sees that flag it only tests one path for being empty, and since that path is a repetition of identical K steps it would never reach the target square of an oblique, and get stuck in an infinite loop. Originally n was only defined for non-oblique atoms.

This is not so easy to fix. The easiest solution is to expand the multipath move yoursef, expressing everything as K steps. That would make it a 6-leg move: 2 legs for the multi-path to the final destination, 2 legs to the locust square (transparently glued together with mp mode), and 2 legs back to the destination.  Like

afsafmpafzcabmpafzK

That, I'm sure, would work for the capturing move; I think I'll still want the nN for the non-capturing/conventionally capturing move.

For the Wizard, I'm thinking FyafsFyafsafF for the basic move, if I'm reading the coding correctly. (I'll probably keep the place-switching part in leap mode: udFudNudC.)

Question: could captureMatrix be used to effect the royal promotions (Prince to King and Princess to Queen, upon the capture of the second in each pair)?

Reminder to self: Include the technical difference between "rifle capture" and "advance capture."

I think all that's left right now is to check the Berserker and Wizard text descriptions against your notes, H.G. (I'm pretty sure getting the royal promotion into the ID is a lost cause, at least for now -- not even a captureMatrix seems like it would do that trick.)

For the Wizard, I'm thinking FyafsFyafsafF for the basic move, if I'm reading the coding correctly. (I'll probably keep the place-switching part in leap mode: udFudNudC.)

It should not contain the y, which would 'range-toggle' the next leg to make it an unlimited-range slide. So FafsFafsafF would do. BTW, I am not sure what the added value is of making these moves lame rather than direct leaps. And that they would not be lame for the swapping is an inconsitency.

The description of checkmate still confuses me, and even seems inconsistent at places: you say that when your King is in checkmate you cannot rescue it by checkmating your opponent back, and then later you say that you can do that, and would even win by it. If you specify unusual rules w.r.t. royalty, you cannot take anything for granted, and should clearly specify what makes a pseudo-legal move illegal. As I understand it, in this case that would be to leave the King under attack, except when there is no pseudo-legal move that would could resolve that and you still have a Prince, in which case all pseudo-legal moves become legal. (Even moves that create new attacks on your King? Can you move your King to another attacked square in that case?)

This exception to the normal checking rule can cause your King to get captured, and you have a rule to address this: the Prince promotes to King. After that you no longer have a Prince, so the acception does not apply, and you basically revert to the normal chess rules for check(mate).

Note that Tamerlane II uses a very similar rule, which the ID implements through the succession parameter. The difference is that there the Prince does not promote when your King gets captured, but that you have to spend a move on that (only allowed when otherwise you would have been checkmated).

I'll fix the Wizard's ID move per your note.

I could make the regular move leaps; my idea is that the Wizard moves normally, but does the swapping through a magic spell.

I'll try to simplify the discussion on Checking and Checkmate, among other things by putting it all in one place.

I don't suppose the succession parameter can get the Prince to promote upon the King's capture? (And likewise the Princess and Queen.)

I don't suppose the succession parameter can get the Prince to promote upon the King's capture? (And likewise the Princess and Queen.)

What succession=N does is to generate moves that swap the King with a piece of the indicated successor type and search those, after the search of all other moves has left the score at minus 'infinity' (meaning no legal moves and no draw by stalemate). That it has to scan the board for that is of no importance, as this code is almost never reached.

What you want (if I understood it) is far more complex, as capture of the King should normally abort further search with a +infinity score (flagging the preceding move as illegal), unless the previous position was done in a checkmated position (which it would not know yet at that point).

Funny enough the Princess promotion would be easy to do with some custom scripting. The ID calls a custom function (if one is supplied) for every move it generates, which could then tinker with the generated move. This function could test for capture of a Queen, and in that case add promotion of the Princess to the move encoding. The parameter trackPieces should make location of the Princess available resonably cheaply, so that this doesn't cause too much of a slowdown.

The difference is that exposing the Queen to capture is allowed at any time. But exposing the King to capture is allowed only when checkmated. This latter requirement is the hard part.

Yeah, I kind of figured it'd be that complicated. I'll hold off on trying to do the succession for now, though I do have an idea.

Perhaps, from the perspective of the ID, the King each side starts with is a non-royal King. Then capturing either the NRK or the Prince puts the royal King in the place of the other.

That might even be a clearer way of explaining that in the text.

I'd want to hold off on any custom scripting until this variant is live, though.

Perhaps, from the perspective of the ID, the King each side starts with is a non-royal King. Then capturing either the NRK or the Prince puts the royal King in the place of the other.

That is basically 'extinction royalty', where both King and Prince are royal. This is even the default mode of the ID, provided you define both these type as royal. In this case there only is a ban on exposing the last remaining one to capture.

It would allow you to ignore attacks on the King even if you are not checkmated, though. (Even for the purpose of capturing protected pieces.) In Spartan Chess black has two Kings as extinction royalty, and the second King turns out to be worth about 4.5 Pawn. So it would be favorable to trade it for a Rook, let alone a Queen, and 'checks' by these pieces can be dealt with satisfactory by protecting your King.

Of course the script for promoting Prince (and Princess) in case of capture would still be needed, because their move needs to be altered.

The extinction royalty sounds like what I'm after (or, as we used to say in the 80s, "close enough for government work"), especially if the Prince promotion can still happen.

I'll try to simplify the discussion on Checking and Checkmate, among other things by putting it all in one place.

Just so you know, H.G., I haven't forgotten about this, and I hope to get to it some afternoon soon. I have a few other adjustments to make as well (among them yet another change in the Helepolis' move).

Have you thought about adding this to game courier?

I have, yes. I still need to fix a few pieces' moves, though, as well as get familiar enough with GC to put it in.

Considering that (as I just noted in my latest update on my Dealer's Chess submission) I've hit my limit on new submissions for now, this might be a good time to start doing those things.

The Interactive Diagram you included defines the Nightrider as the (only) royal???

The Interactive Diagram you included defines the Nightrider as the (only) royal???

ARGH!!! I'll have to fix that after I get home tomorrow.

The way I understand your checkmate rules is that normally you would have to play like the King is the only royal piece. But positions where you would then be checkmated you have to recalculate after making the Prince (if there is one) a 'temporary royal' instead, i.e. upto and including the opponent's next move. After which royalty returns to your King if it is still there, or the Prince morphs into a King, making its royalty permanent, if it was not. If you also have no legal moves when the Prince is royal, you have lost immediately.

I guess this means that when your King runs into checkmate, and your Prince then delivers a check to the opponent King through his Knight move, the opponent can resolve that check by capturing your King (demoting the Prince to a King, which loses it the checking move).

I plan to just go with a conventional "extinction royalty" rule, possibly with an added rule that the King has to move out of check if possible. Even with that change, though, the automatic promotion of the Prince to King upon the original King's capture makes your second paragraph still correct.

With extinction royalty you could ignore any check as long as you still have multiple royals. With an additional rule that a King must get out of check when he can, this makes it indistinguishable from the case where the King is the only royal, as the Prince can be kept in check because it is an extinction royal and you still have a King. So I am not sure what exactly the change is you have in mind.

If you consider changing the rule, how about this: the King is the only royal piece, but in the case of checkmate it must swap places with the Prince, (like in Tamelane II succession), in addition to doing another move. The King would still stay the only royal, but it is now where the Prince used to be. If the opponent decides to capture to the old location of the King, this leads exactly to the situation your original rule would have led to if he had captured the King. Only if he doesn't capture immediately Prince and King would have been swapped.

This would be easier to support in the Diagram, where it would just be a small modification on the way it now treats Tamerlane II succession. The code there is only executed in stalemate positions, and these are so rare that it doesn't have any effect on performance of the AI. (So it is affordable to scan the board for finding the location of King and Prince(s).) Currently it then performs the King-Prince swap(s), and searches on from there with the opponent on move, to judge whether the swap (that took a turn) brings any solace. In the proposed case it would have to search on with the same player on move, (as the swap was an automatic consequence of the checkmate), to find the best move to combine with the swap.

What if, instead of trading places with the Prince, the checkmated King simply teleported to the Prince's location, destroying the latter? (I really don't know if the ID can handle this as-is.)

You mean automatically, in addition to another move, or as a move option to the checkmated player? Currently the Diagram supports neither, but especially the latter is so similar to the Tamerlane II succession it already supports that it would be very easy to supply it as an option too. You would lose the possibility of any King rescue, though. And if you don't have that, I don't really see why you would prefer this over the already existing succession mechanism.

I was thinking automatically, though if the ID doesn't support it I might as well go back to the original rule of the Prince becoming King automatically when the King is captured.