Comments/Ratings for a Single Item

You are right, something is not as it should be here. (So thank you for reporting it!)  hlalfN gives a 4-step orthogonal move, while hrarfN gives a 4-step diagonal one. While logically they should just be each other's mirror image.

I will have to figure out why exactly this happens. My first suspicion is that I added code to swap the meaning of l and r after a left-handed chirality-breaking step. At an early stage of designing the notation I thought this would be helpful, because it means that you could simply write afrN to mean hrafrNhlaflN. But later I realized that the modifiers q and z could be used in continuation legs as placeholders for l or r, meaning deflection in the same or in the opposit direction as the previous leg. This would be a natural generalization of the original Betza meaning of circular and zig-zag.

I suspect that in implementing the latter, I somehow interfered with the original idea of making the meaning of l and r itself in continuation legs dependent on context. I will check this out.

Anyway, the recommended notation for what you wanted to do would be aqfN, a first Knight step, followed by a 45-degree bend in the same direction. Where the original direction was defined by the way the oblique move was bending when you consider it an orthogonal move followed by a diagonal one.

I have now implemented the multi-path expansion of the n modifier on oblique atoms in the XBetza parser of the Interactive Diagram. This can only be used when all geometrically shortest paths are allowed. So nN is a Moo, and pieces that only do a subset of that still need to specify want path they take (Mao = afsW, Moa = afsF). But pieces that do multi-path typically do all paths, so this is not a problem. And of course this is where you also get the largest savings. So the multi-path Falcon move now can be written as nCnZ.

Under the "Modes and Other" section:

m ('move') can move to empty square
c can capture enemy piece
p can hop over an occupied square (the 'mount') in its path

I believe the "can" in each of these should be "must".  (May apply in other places too)

I believe the "can" in each of these should be "must".

That depends on whether you think of it as an enabling modifier or a restricting one. I admit the situation is not entirely clear cut. Specifying multiple modifiers means that you can do each of those. E.g. having cp means hopping as well as capturing get enabled (in a non-final leg), and what is not mentioned (non-capture or moving off board) is not allowed. This is somewhat contradicted by the fact that (in final legs) mc is the default mode. So writing a single m disables c, rather than changin the m rights (and vice versa). But forbidding c is not really the meaning of m, as you can write mc, and that would allow both. (It would just be unnecessary verbose, unless there is a third mode involved, like mce. So the way I look at it is that the modifiers enable what they mention, and do not affect any rights they do not mention (for which I think 'can' is the proper choice). It is just that we have the convention that a pure 'mc' can be omitted.

@HG,

So, GX and HY is the same thing, or one takes precedence?

No, AX and HY is the same thing. One way to look at it is that X gives an extra H and Y gives an extra A. And H+A = A+H.

It doesn't matter which one you use.

Thanks!

I have implemented k now such that in combination with c it disables capture of royals. (A combination that before was not different from plain c.)

Actually this means that k now can do what the t modifier (for 'tame') does in XBoard. Without using an extra letter!

In the process of testing it I found out there was a horrible e.p. bug in the AI of the Interactive Diagram: it was always considering the destination of any normal moves an e.p. square. But since usually pieces that can e.p.-capture also would have normal capture to the same square, it would not have any effect other than that the capture would be generated twice. With the new move entry routine this would require an extra click on the destination, though, to resolve the 'ambiguity'.

I have implemented k now such that in combination with c it disables capture of royals. (A combination that before was not different from plain c.)

Actually this means that k now can do what the t modifier (for 'tame') does in XBoard. Without using an extra letter!

That's fantastic. Brings Tenjiku Shogi one step closer to being implementable in an interactive diagram. The range jumping piece's moves (in this case the Bishop General) can now be written as B(paf)0ckB, where ck takes care of the restriction against capturing royals by jumping. The current BadZone function could easily handle the rest of  the rankings for the jumping Generals. Now just to figure out what to do for the burn...and how to specify options to accomodate how the burning move behaves. Once I have a way to do this, I can take care of the rest.

Unfortunately this is not so easy, because BadZone only gets the locust squares passed. Not the pieces jumped over. The non-destructive intermediate squares are not part of the internal move representation. But I suppose BadZone could be made such that it scans the board for high-rank blockers along the path from origin to destination itself.

BTW, I have played Tenjiku at high level according to 'modern' rules, where the King can be jump-captured. To my surprise this was very playable, and not too unbalanced. If you know the correct opening lines. Which my Tenjiku engine was able to determine.

In addition I came to realize that the King has highest rank does not necessarily have to refer to capture. Originally I thought that outlawing jumping over a King only would be pointless, as you would never be interested in doing that when you could also capture it. But it could also refer to your own King. So the evidence that historic rules did not allow King capture is starting to get flimsy.

BTW, I have played Tenjiku at high level according to 'modern' rules, where the King can be jump-captured. To my surprise this was very playable, and not too unbalanced. If you know the correct opening lines. Which my Tenjiku engine was able to determine.

In addition I came to realize that the King has highest rank does not necessarily have to refer to capture. Originally I thought that outlawing jumping over a King only would be pointless, as you would never be interested in doing that when you could also capture it. But it could also refer to your own King. So the evidence that historic rules did not allow King capture is starting to get flimsy.

Jumping Generals are not allowed to jump over a King or Prince (or other higher-ranking pieces) of either side, regardless of which ruleset you use, so the fact that the rankings could refer to friendly pieces is a rather dubious piece of evidence for allowing jump-captures of royals. Besides, even if the evidence for forbidding jump-captures of royals is indeed flimsy, it still improves the gameplay, as allowing jump-capturing of the King creates a critical weaknesses in the opening after 1. 7k (2. VG 2g#) which is only solvable via 1... SE3f. Furthermore, this weakness persists throughout much of the game, as the King remains boxed in throughout the opening and (early) middlegame, the Soaring Eagle on 3f (and other pieces defending 2g and 1h) can easily be threatened with capture, and one wrong move can result in a smothered mate. The point is, you should not need to use an AI to find a good opening.

Unfortunately this is not so easy, because BadZone only gets the locust squares passed. Not the pieces jumped over. The non-destructive intermediate squares are not part of the internal move representation. But I suppose BadZone could be made such that it scans the board for high-rank blockers along the path from origin to destination itself.

You can just use board[y][x] & 511 for the piece type, and a call to a recursive function that scans the in-between squares to handle the rest.

... the fact that the rankings could refer to friendly pieces is a rather dubious piece of evidence for allowing jump-captures of royals.

The point is that it makes no sense at all to make a rule that forbids jumping over an enemy King, while allowing its capture. For this reason I always considered the fact that the King was mentioned in the general's ranking as evidence that it must be there for forbidding its capture. (Even though this caused a very nasty inconsistency in the rules, as capture of generals of equal or higher rank are allowed.) This reasoning was flawed, however: the rule could also have been added for preventing generals to jump over their own King. That it would at the same time forbid jumping over the enemy King would not be relevant, as no one in his right mind would want to do that anyway.

The evidence in favor of allowing capture is that the King appears in the ranking without further comment, suggesting it is treated as its rank would suggest, but not special otherwise. The evidence to the contrary now seems to have evaporated. The weakness you mention can in fact be trivially defended; no AI is necessary to to find that, and the 'quick attack' was standard theory from the very beginning. Its main line doesn't provide a very large advantage, though, as it doesn't win in just a few moves, and when sente runs out of steam, gote can mirror its play for a counter attack. This also has been known from the early days.

The smothered mate indeed is the main theme of all openings. It is the only way in which the jumping generals can combat a Fire Demon, and makes Demon sacrifices for 2 or 3 generals (including the GG) playable: in the end the side with the generals can force the opponent to give the Demon back. Otherwise the value of a Demon is close to infinity. It is really a very interesting game that way, and certainly doesn't fuel any reasoning of the kind "they cannot have intended this".

Ok, fair enough.

Aren't X and Y confusing in some cases? For example what is NX? Is it (4,2) (as DY) or (5,1)?

Or is it a convention to remove all ambiguities?

The convention is that X extends the longest dimension of the preceding atom. So NX makes (5,1) from (2,1), not (2,4).

It seems strange that [W?fR] is the same as [W?fB]. Is that intended?

It is a consequence of the Betza parser not printing any error messages. In [W?fB] the f and B are conflicting input: f says you should keep moving in the same direction as the W step, while B says you must move diagonally. So it is an invalid specification, with undefined result.

What happens in practice is that the [...] notation is implemented by a pre-processing step that replaces it with the original XBetza notation using the a modifier. It thus uses the first step as the atom, tests whether a range-toggle is required for deciding it should be prefixed with a or ya, and takes the modifiers on the second leg. So [W-fB] becomes yafW, which is what [W-fR] would become too. The B or R are simply ignored (apart from detecting that they are sliding moves, so that the y will be prefixed). The preprocessor is not smart enough to understand directionality of the second-leg atom, nor that non-matching directionality would require addition or removal of an s to get the correct bend. It treats all second-leg atoms like they are K or Q, and you have to supply the s yourself.

Perhaps this can be improved one day.

How can I make a kamikaze piece and the fire demon with it ?

Kamikaze pieces are a form of promotion (namely promotion to an empty square). The Interactive Diagram does support mechanisms for indicating unusual promotions (like the captureMatrix), but unfortunately promotion to empty is not amongst those. The problem is that promotion code 0 (the code of an empty square) is used to indicate there is no promotion, and the piece remains itself.

It should be possible to use another code for indicating promotion to empty, though, and recognize that as a special case in the routine that performs the moves.

How about the coordinator?

There is no special notation for automatic side-effect captures, like explosions in Atomic Chess, burning of Fire Demons in Tenjiku Shogi, or Coordinators and Pincher Pawns in Ultima. It is questionable whether there should be. Betza notation is primarily a method for indicating how pieces can move from one square to another. If a locust capture is optional, it can often be described as an extra move possibility with a displacement capture in a non-final leg of a trajectory that makes a detour. But Coordinator captures are not of that type. There it is possible to move to a destination even if there is nothing to capture, but it is not allowed to make the move without capture if capture was possible.

As noted in the text, the lowercase w is still unused. Could that be made to indicate a withdrawing capture? If it has to be coupled with the c, then it could still be usable for other things by itself or with other modifiers.

Or is there already another way to indicate a withdrawing capture?

In XBetza notation all captures are written as normal (i.e. replacement) captures, where you specify a multi-leg move that makes a detour over the victim square when they are not. So for withdrawer capture as in Ultima you would specify a trajectory that first takes a step in the opposit direction of how you want to move, and then reverts direction to move with a non-capture to the destination. This has a much larger expressive power than introducing a new letter for each type of capture.

There are two caveats in the withdrawer case, though:

• To exclude plain rifle capture, the piece would have to move at least two steps after making the capture. So you must make it a 3-leg move, where the first leg steps to capture, (i.e. K if you want it to go in all 8 directions), the second leg steps back, and a third leg then continues with a slide in that derection (and so needs to toggle the range by usin ya in stead of a for connecting the legs).
• The detour must not be blocked by a board edge or an own piece, while it must be mandarory. (So you cannot add a separate mQ for the non-captures, or the capture would be optional if there is something to capture). So the first leg must also be able to leave the board (o) or hop over a friend (but not an enemy). Unfortunately there does not exist a letter for 'friendly hop', so this must be improvised through 'friendly capture' (d) + 'unload (u) on the next leg. Because of the unload this cannot be contracted with the 'mco part' and has to be specified as a second move.

That finally gives mcoabyafmKdaubyafmK for the Ultima Withdrawer. The new 'bracket notation' for multi-leg moves, which is supposed to be more intuitive because in explicitly indicates direction type and range for every leg, instead of having to reconstruct it through range toggling and atom rotation, would be [mcoK-bK-fmQ][dK-buK-fmQ].

I agree that this is rather cumbersome, compared to, say, wmQ. But that is the tradeoff you will always have in using a completely general system over a system taylored to one application. There is in principle an infinity of capture modes, and by giving each mode its dedicated letter you will run out of letters pretty quickly, and then there is no room for further expansion. And even if there was (e.g. by using the Chinese character set), it would be impossible to remember all the meanings. Having a separate letter for 'friendly hop' would have helped here, but then you would still not have something for 'enemy-only hop'.

It is true that the combination "capture if there is something to capture, but do not block if there isn't" is relatively common amongst the cumbersome combinations of modes. It could be an idea to use cc for that (i.e. move, enemy capture, friendly hop or over the edge). That would simplify the Withdrawer case to [ccK-bK-fmQ]. It might even be better to give cc the meaning of a "rifle capture if possible", to remove the need for the extra backward step before you start sliding. Then the Withdrawer would become [ccK-bmQ]. And an Advancer would be [mQ-fccK]: move to an empty square as Queen, and from there rifle-capture the next square along the path if there is an enemy there (but never mind if there isn't one).

I like the idea of using cc; it at least leaves that w open for something else. Listing my Hangman (captures by moving one space away) as ccK-bmK (or would that be bmK2?) is elegant.

On a different topic, is there a way to represent Immobilizing? I have a Jellyfish that Immobilizes anything within 1 square (though unlike the usual Immobilizer, it moves like a King).