Comments/Ratings for a Single Item

The logic behind it is a very simple, "The King is dead! Long live the King!" In reality, the death of a king makes the prince into the new king; this simply replicates that. (A similar, if slightly spurious, logic appliess to the Princess's advancement to Queen on the Queen's capture.)

Well, that describes exactly what the already implemented Tamelane II succession rule does. So why the need for a different rule?

Isn't it just the same as having two kings at once?

No, with two Kings (as extinction royalty) you can ignore any check. Succession and the like only can ignore checkmate.

That's not what Tamerlane II succession does. In Tamerlane II, as you already described, when the King is in a checkmate position the player may exchange the King's location with the Prince's. This is, basically, abdication in favor of the selected Prince; the King becomes a Prince, and may remain in play. What I described is the King being removed, automatically making the Prince into the King, kind of like what recently happened with Elizabeth II and Charles III.

Anyway, the Nightrider problem was a matter of me miscounting. It should be fixed now.

Indeed I can't remember why I wrote this detail in the succession rule of Tamerlane II: "The checking player is free to take or not the new Prince." Originally I wanted a succession as you describe it, the King disapears and the Prince becomes King. Probably, I was troubled by coding reasons. In chess a piece disapears when it is replaced by its conqueror. Maybe I had made a bad choice, maybe I should have said the taking the "new Prince" is compulsory. Well, in most cases it is what happens, the checkmated King is really taken otherwise the attacking player is letting a new Prince that could become a King again, which is not suitable.

In the rule as you see it Bob, I understand that the checkmated King is removed but no attacking piece is moving on its square. Imagine White King is checkmated and that, in checkmating, Black is eating a piece. As he also removes the white King, Black is actually taking 2 pieces in a single move. That was probably my problem. This is why, I said that the White King is becoming a White Prince.

Well, in most cases it is what happens, the checkmated King is really taken otherwise the attacking player is letting a new Prince that could become a King again, which is not suitable.

Not really. The new Prince is not any different from a Prince that has always been a Prince, and whether you want to capture a Prince (or in fact any piece) depends on whether it is protected, and how much you would lose on the recapture. This is quite similar to extinction royalty (except that the checkmated side in Tamerlane II has to spend a move on the succession, while with extinction royalty the remaining King automatically will become a King that has to take threats seriously).

For instance, in Spartan Chess black starts with two Kings. Now the tactical value of a King is not very large; it is close to a Knight. The fact that you have a spare royal is also worth some, though. In playtesting it turned out that when replacing a Rook by an extra King for one player, that player will lose more often than not, about half as bad as when he is a Pawn behind. So a Rook is about half a Pawn better than a spare King, and you would not want to trade a Rook for that King. Let alone a Queen.

In the rule as you see it Bob, I understand that the checkmated King is removed but no attacking piece is moving on its square. Imagine White King is checkmated and that, in checkmating, Black is eating a piece. As he also removes the white King, Black is actually taking 2 pieces in a single move. That was probably my problem. This is why, I said that the White King is becoming a White Prince.

In the rule as I'm trying to implement it, for the succession on White's side to be triggered, Black has to actually take a turn to capture the White King. Then the White Prince immediately becomes the White King.

I'm trying to figure out how it works for you. Let's say Black checkmate the white King while taking a white Pawn. Black says "checkmate", and White plays if, as you say, Black has to take a turn. So White plays while his King is checkmated. Either he plays another piece while leaving his King in check or he plays his King by placing it on a square where it is also in prise, as it was checkmated. Then, and only then, Black seizes the White King (so a black piece is now on the King's square) and White's Prince is becoming a King. Correct?

In such a case, it is strange that White plays while his King is checkmated.

Sorry, it is not clear for me yet.

This is part of why I'm wanting to also implement the King and Prince as both royal, at least for purposes of the extinction royalty rule.

I don't quite know the rule for declaring check or checkmate with extinction royalty, but my take on it is that it isn't required (except on the last one) but is good to do as a courtesy.

In any event, if the White King is in check, then the White player is strongly encouraged to get it out, though if he has a better move (such as capturing the Black Prince, or otherwise doing serious damage to Black) then he may take that. Likewise, Black is not required to take the White King if he has an opportunity, though he may also find something better to do (like capture or trap the White Prince, capture the White Queen, or just leave the White King where it is because if the White Prince promotes to King it'll be in position to move and capture something in an orthogonally neighboring space that Black doesn't want captured). Only when the Prince is off the board, either by being captured or by promoting to King when the King is captured, do normal check/checkmate rules apply for that side.

That means that, if White still has his Prince and Black doesn't have his, White can deal with his King being in check by putting Black's King in check. Black is then obligated to get his King out of check.

And, as I mentioned, the promotion of Prince to King only (and immediately) happens when the opponent actually makes the move of capturing the King.

So, basically, your scenario is correct but for a couple of minor details, the main one being those generated by the extinction royalty rule.

Taking the King might also be bad simply because it was protected, and the piece checking it was too valuable to trade it for a King. After all, a spare King isn't all that valuable. On 8x8 it is already worse than a Rook, and on large boards it is likely worse than a Bishop.

An attack on one of a number of extinction royals is not a check, and doesn't have to be resolved. In Spartan Chess there is a special 'duple check' rule (so it is not regular extinction royalty): you must have at least one King that is not under attack. This is really like it is absolute royalty,  but at the end of every turn you can appoint one of your King pieces to be the absolute royal for the next turn.

H.G., when you have a minute or two, could you take a look at this game's ID? I fixed the Wizard, and I think I got the Royalty right, but I'm really unsure about the Helepolis.

H.G., when you have a minute or two, could you take a look at this game's ID? I fixed the Wizard, and I think I got the Royalty right, but I'm really unsure about the Helepolis.

Another undocumented trick, originally intended just for debugging of the Diagram script: If you open the piece table, and click on the header of the move column, it switches to showing the guestimated piece values instead. And it also shows the (hexadecimal) value of the 'royalness' parameter for that piece, if non-zero. Using this it is easily confirmed that you made Prince and King both royal.

As to the Helepolis: combining 'transparent' and 'destructive' modes (such as m and c) in a non-final leg is something the old move generator (used only for the move diagrams if you specified newClick=1) cannot handle. For that reason it splits such moves during parsing of the XBetza descriptions. But the splitting only works for the first leg that needs it, as the old script could not handle more than a single locust capture in the first place. And for the Helepolis you have upto 14 mc legs...

But that is completely unnecessary. By basing the description on a Rook move instead of a Wazir, skipping of the empty squares becomes an implied possibility of each individual leg. So (caf)14R describes the same as (mcaf)14W (with the difference that the old move generator understands it too). What you did is a bit similar to defining a Rook as (maf)14W, making a separate leg out of each step. And that would be quite inefficient, as the modifier repetition would be handled by preprocessin the text description, expanding it to WmafWmafmafWmafmafmafW... Eventually the move generator, when it gets to generating the N-step move, would start testing the first N-1 squares to see if these are empty, while it already had obtained that information during the attempt to generate the (N-1)-step move. When described as R it would simply try to add another step to the last move it had, and once it encounters an obstruction it would be done with that direction, and never try any longer moves for it.

Royalty: Excellent!

Helepolis: OK, I think I've got it. I'll fix that presently. The move as described should be RcamfRipfmRsb(caf)14R, right?

The ipfmR part would also allow a non-capture hop over an enemy piece without capturing it. I don't know if this was your intention. If it should be friendly hopping only, you could use the kludge idaufmR, where the d limits the first leg to reaching friendly pieces only, and the u in the next leg would undo the destruction this involved by unloading that friend on the same square.

I hope to get rid of this kludge, one day. Perhaps this is already achieved, but the price is that you then have to define a captureMatrix. A ^ in that matrix outlaws hopping in a type-specific way, so that you could keep specifying the universal hop ipfmR, and then outlaw doing it over all enemy piece types, but not with friendly piece types, by writing as many ^ as there are piece types (shorthand ^N) in the row for the Helepolis, after a dot . (which would apply to hopping over an empty square, which is nonsense and so doesn't have to be outlawed).

The ipfmR part should be idaufmR, then. I was actually more worried about the sb(caf)14R part, but apparently that's OK. :)

Many thanks for all your help on this!

Addendum: I have it now looking like I think it should. Now to work on the Game Courier code....

And, after evaluating the Teutonic Knight (from Teutonic Knight's Chess), I've decided to use its WNC move as a more appropriate expansion for the Knight in this game than the Aurochs. (Plus, it's still a Knight by name.)

I hope to get rid of this kludge, one day. Perhaps this is already achieved, but the price is that you then have to define a captureMatrix. A ^ in that matrix outlaws hopping in a type-specific way, so that you could keep specifying the universal hop ipfmR, and then outlaw doing it over all enemy piece types, but not with friendly piece types, by writing as many ^ as there are piece types (shorthand ^N) in the row for the Helepolis, after a dot . (which would apply to hopping over an empty square, which is nonsense and so doesn't have to be outlawed).

Just a thought: What if this could be done with i^pfmR? Would that confuse things too much?

Just a thought: What if this could be done with i^pfmR? Would that confuse things too much?

I don't see the logic of that; considering that ^ in the captureMatrix means "cannot hop" combining it with p seems more confusing than helpful. And if there is to be a special XBetza modifier for friendly hopping, there should also be one for hopping only over enemy pieces.  It is true that allowing non-alphanumeric caracters as modifiers solves the shortage-of-lower-case problem, but ^ seems a bad choice. I once did consider using p' and p" for friendly and enemy hopping, or using general 'limiters' in the form {...} behind modifiers to restrict their action to the enclosed piece types. But it seemed bad to have piece ids, which are very variant specific, appear in the XBetza notation, where capitals already mean something completely different. The capture matrix seems a much cleaner solution for all type-specific interactions. And color is just one aspect of type, so it can also be used to resolve the color-blindness of some of the XBetza modifiers.

Addendum: I have it now looking like I think it should. Now to work on the Game Courier code....

Unfortunately the betza.txt GAME-code include file does not support more than a single locust victim per move. (Which is the same limitation that the betza.js script imposed on the ID, end was only relieved in the betzaNew.js that is under development.) It is not even possible to use the option of defining Custom Pieces, as the problem is not only in generating the move, but that the employed move encoding and code that finally applies the generated move to the board has no provisions for more than a single locust victim.

A work-around for when you still would want to use the Play-Test Applet system for automation would be to define the Helepolis 'buldozer moves' as multi-hopping, rather than multi-capturing in the Diagram you are going to convert, and then append some GAME code to the Post-Move sections to remove all pieces that were hopped over.

OK, that's definitely good to know. Thanks for the note on that, H.G.

Have you thought about adding this to game courier?

I finally got a start on this this evening, and so far it's had more wrinkles than my Jedi Elvis costume when it's straight out of the suitcase. I'll have so many questions for H.G. (and probably Fergus) when I go back to it Monday....

OK, I have the basics of the GC preset in place. I was able to figure out the worst problems on my own (all it took was making sure the two-letter piece codes were in all caps). Things I still need to figure out how to do (that I can identify right away) and/or get help with:

• Fix the Helepolis move.
• Require promotions of Pawn -> Knight, Soldier -> Helepolis, and Sergeant -> Lancer upon reaching the back row.
• Arrange for Prince and Princess to promote to immediately replace a captured King or Queen (respectively).

Once those are done, I can:

• Decide whether to make new graphics for the Berserker, Bowman, Chancellor, Prince, Princess, Sargeant, Soldier, and/or Spy; and, if I decide in favor, actually do it and send the work to Fergus (unless, of course, someone beats me to it).
• Write out piece move text (using the [pc] shortcode). (Side note: Where does this go?)
• Put text of other rules into the Rules section.
• Take care of anything else I've forgotten.

If you expect help it might be an idea to post a link to the preset, so that people can see how you are doing...

Did you use the Play-Test Applet to convert your Interactive Diagram? If you would have used the new version of that, the morph parameters in the Diagram would have been converted to GAME code too, and the promotions should work. Except that your Diagram seems to contain contradictory instructions: on the one hand you define a promotion zone, where Pawns should promote to Queen that had been captured before, but at the same time you specify they should morph to Knight there. No idea what the GAME code would do in that case.

For K and Q replacement you could append code to the Post-Move sections to figure out whether the piece captured in that move (available as the variable #victim) was a K or Q (of the applicable color). And if it was search the board for the Prince or Princess (there is a GAME-code instruction for that), and promote it. SHould not be terribly complicated, except that the Helepolis could have captured K or Q too on other squares as its destination (so that this would not show up in #victim). So the code to handle Helepolis buldozer captures should also test for this, and relay the result of that test somehow to the code that performs the succession.