Comments/Ratings for a Single Item

Well, the bracket notation is simpler. This is why I would like to switch to it.

But when chaining moves into a single path it cannot be avoided that you would have to specify the bending angle at each point where two legs connect with the aid of directional modifiers (if f is assumed to be default).

And there is the more fundamental problem that oblique paths occur as pairs of mirror images, and that this mirroring swaps the meaning of l and r. To avoid having to specify complex oblique paths twice, there must be a way to encode sideway deflections not as an absolute direction, but in a relative way. And this is what z and q do.

@Daniel, HG. Thank you for your kind explanations. I start to see better. I had not caught the fact that the "a" could link with a "none" modifier.

I understand the logic. I don't like it much though. It is strange that nothing more natural could have been imagined, without ambiguity, to chain simple moves. You guys have been thinking on it for a long time, so I guess it is not so easy.

It would probably have been clearer if I had used a hyphen or slash instead of an a. But it all started as aaK for the area move of Tenjiku Shogi, and caK for the Chu-Shogi Lion. But the hyphens seem to group the atoms in the wrong way, when you don't also use brackets around the individual moves.

In (not-yet-implemented) bracket notation the Betza Rhino would be [W(?fzK)], shorthand for [W?fzK?fzK?fzK?fzK?fzK?fzK?fzK...], a W leg followed by any number of alternating fl and fr K steps.

Indeed I belong to those not digesting the "a" at all.

Think of a as a separator between two legs of the move, like an "and". In aW, the a implies that there are 2 legs and the W tells you what those legs are.

You should consider the a as a chaining symbol, separating the modifiers for the legs of a multi-leg move. So in afsafzafzW you see 3 a, which means the move has 4 legs. The modifiers for these legs are none, fs, fz and fz, respectively. So the first leg is a W move in all directions (no modifier). From there it continues forward-left or forward-right (because s = l or r), i.e. a diagonal step in the second leg. Then for the third leg it again deflects 45 degrees, but in the opposit direction as in the second leg, as this is what z means. Etc. So afsafzafzW is a shorthand for aflafraflWafraflafrW, two crooked trajectories that are each other's mirror image.

Haru's notation (afz)W is shorthand for WafzWafzafzWafzafzafzW..., a set of ever longer crooked trajectories. Every additional afz adds a new leg, which deflects in the opposite fl or fr (relative) direction as the previous leg did. (Which is the hallmark of a crooked move; if they would all deflect in the same direction, which you could do with fq, you would get a circular piece.)

The second leg in every sequence should really have been specified as fs, however, to indicate it can deflect in both directions, rather than only in one that is specified relative to the previous one. The first z or q occurring in such a sequence (i.e. before it is clear what 'opposit' or 'the same' direction means for the deflection, because there was no previous deflection) is always interpreted as s. You could see this as a special rule for expanding the parentheses into paths with different lengths.

@HG: somewhat it gives me some explanation, somewhat I'm more confused than before. So, HG, taking this "The meaning of z in a multi-leg move has also changed; it now means l or r, but the opposit of what the previous leg did. (So that it can be used to specify crooked paths)"; how would you write that Betza's Rhino and Mirror-Rhino?

@Haru N Y: your notations do work but I can't understand why. Indeed I belong to those not digesting the "a" at all. And why do you call the Mirror-Rhino a Snake? That confuses me even more too.

I did know about Betza's t[FR] proposal for Griffon, but I had never seen this z(FW) notation. XBetza is only upward compatible with the Betza notation for simple ('single leg') moves, and has its own system for combining these to multi-leg moves, which is more general than any of the suggestions that Betza coined in various scattered places.

The z modifier applied to a slider atom is original Betza notation for a crooked version of the piece, and is still supported in XBetza. On a leaper, such as zW, it never had any meaning.

The role of parentheses has completely changed; in XBeza these indicate zero or more repetitions of the enclosed group. So z(FW) would mean zzFWzFWFWzFWFWFW..., which doesn't really mean anything.

Brackets originally were not used in XBetza, but legs of a move were 'chained' by using an a as separator between the modifiers of each leg. This does the job of unambiguously defining very complex moves, but often leads to a very obfuscated description unsuitable for human digestion. A much clearer notation is possible by using brackets (but in a way that somewhat is different from Betza's t[...] construct). The brackets still enclose a sequence of simple Betza moves, which are supposed to be played in that order. But there is no t prefix (which was redundant, because the brackets are never used for any other purpose than chaining the contained moves), and separates the enclosed moves by hyphens (if continuation is mandatory) or question marks (if the move could also end there). This notation is already supported in the Interactive Diagram for simple cases like the Griffon ([F?R]). Supporting it in its full glory is a desire for the future.

The meaning of z in a multi-leg move has also changed; it now means l or r, but the opposit of what the previous leg did. (So that it can be used to specify crooked paths, while q means l or r in the same direction, and can be used to define curved paths.)

Rhino: (afz)W
Snake: (afz)F
z stands for zigzag & it's repetition depend on the board size. This page is about XBetza notation, not Betza notation.

@HG: I thought I had understood, but finally I'm confused and lost. I try to describe Rhino (TwiKnight) (and Mirror-Rhino (KnightTwi)) in Betza's notation. I found z(FW) in an old page (made by Betza) but it doesn't work on the diagram. Maybe the role of the () has changed.

Also I don't understand why when I test zW and zR, I get the same result. Is z meaning an infinite repetition?

Is all this consistent?

You would forbid the capture of all non-pawns by pawns in the captureMatrix, and then exempt the pawn's normal captures from this restriction by suffixing it with an apostrophe.

Wouldn't this mess up Pawn promotion?

You would forbid the capture of all non-pawns by pawns in the captureMatrix, and then exempt the pawn's normal captures from this restriction by suffixing it with an apostrophe.

What would not be possible is having some moves that can only capture pawns and others that can capture only knights. (So you cannot implement an Ultima Chamelion with this method.)

Type selectivity is provided by means of the captureMatrix, possibly in combination with the apostrophy in the XBetza to restrict it to a subset of the moves. I haven't encountered any case yet that could not be handled this way.

But what if the qualification only affects one of a group of possible moves? In this case, the opening move of a Pawn, which could capture anything with its conventional capture but has a special initial move only for capturing nearby enemy Pawns.

Type selectivity is provided by means of the captureMatrix, possibly in combination with the apostrophy in the XBetza to restrict it to a subset of the moves. I haven't encountered any case yet that could not be handled this way.

Since "Ideas for the future" no longer mentions ways to allow/disallow capture of certain pieces the way k does for the King, I take it that this has been abandoned? (I'd been kind of hoping for at least some way of affecting at least Pawns this way, and while I can see where the logistics would be difficult to figure out I'd be interested in helping brainstorm it.)

Fair enough. :)

if you could take a glance at that when you have a moment and pick out any problem symbols (the Berolina would be a leading candidate), and hopefully suggest alternatives, I'd appreciate it.

No, I don't have the character sets memorized, and I don't think it is a good idea to go beyond ASCII for piece notation.

Since this site uses Literata, Noto Sans, and Courier Prime, you may want to limit yourself to a subset that is supported by all three of these fonts. Of these, Courier Prime has the most limited support for character sets. Besides ASCII, it supports only Latin Lowercase, Latin Uppercase, Numbers, Common Latin, and Punctuation. Literata and Noto Sans both support all of these, as well as others.

That still leaves me a bit uncertain. I just edited Short Sliders with some Unicode symbols; if you could take a glance at that when you have a moment and pick out any problem symbols (the Berolina would be a leading candidate), and hopefully suggest alternatives, I'd appreciate it.

If that means that, essentially, all of Unicode would be open for use on all systems, then that opens up many more possibilities (for the "special custom codes").

In theory, but it's a rare font that fully supports all of Unicode. Since this site uses Literata, Noto Sans, and Courier Prime, you may want to limit yourself to a subset that is supported by all three of these fonts. Of these, Courier Prime has the most limited support for character sets. Besides ASCII, it supports only Latin Lowercase, Latin Uppercase, Numbers, Common Latin, and Punctuation. Literata and Noto Sans both support all of these, as well as others.

My concern was support on people's systems at home; I expect that there's still a small (but, admittedly, rapidly shrinking) percentage of systems that support ANSI but not Unicode.

Those would have to be very old computers. According to the Wikipedia article on UTF-8, "UTF-8 is the dominant encoding for the World Wide Web (and internet technologies), accounting for 98.2% of all web pages, 99.0% of the top 10,000 pages, and up to 100% for many languages, as of 2024." According to the same article, Windows Notepad only supports UTF-8.

Note that this site uses UTF-8. So there is no point in sticking to Windows-1252 in the mistaken notion that it may be better supported. That said, ASCII has the advantage of being on most keyboards and of being most familiar to people. It’s also a subset of UTF-8 that can be written as single 8-bit characters.

If that means that, essentially, all of Unicode would be open for use on all systems, then that opens up many more possibilities (for the "special custom codes").

My concern was support on people's systems at home; I expect that there's still a small (but, admittedly, rapidly shrinking) percentage of systems that support ANSI but not Unicode.

the Windows-1252 character set that I'm suggesting to use as the basis (because even a system without Unicode installed should have at least that much

Note that this site uses UTF-8. So there is no point in sticking to Windows-1252 in the mistaken notion that it may be better supported. That said, ASCII has the advantage of being on most keyboards and of being most familiar to people. It’s also a subset of UTF-8 that can be written as single 8-bit characters.

And while hexagonal boards may be in scope for the ID, I imagine 3D and hyperbolic boards are far from it ;‌)

Representation of 3D and 4D 'boards' is mostly problematic for the human player. One often resorts to displaying 2D slices of the board next to each other, which basically maps it to a larger 2D board. Chess programs in fact use the very same technique to map 2D boards to their 1D memory, storing them row by row. In all these cases separators between the slices would be needed to prevent 'wrapping' from one slice to the other. Usually this is done by separating the slices by enough inaccessible cells of the 2D representation that the leaper with the longest range cannot jump over it.

E.g. for a 5x5x5 variant with range-2 leapers ('Knights') you would map it to a 33x5 (or 5x33) board, with five 5x5 playing areas separated by four 2x5 'guard bands'. On this board an orthogonal step perpendicular to the slices would be a (7,0) leap, and is representable in XBetza as WXX. So the Raumschach Rook would be RWXX4, a Raumschach Bishop BHX4DXX4FXX4.

It's trying to get caib[qN] to work that would be the challenge.

Well, now that generalized burning is been written with the aid of legs behind a semicolon, another punctuation (say comma), could be used for generalized rifle capture. Burning and rifle capture are related: there is a set of captures, burning automatically does all of those that are possible, rifle capture has to select one of those. Pure rifle capture is a null move followed by the capture option. Suppose O without range would mean null move, then [O,cqN] would be a rifle-capturing Rose. There still is the issue of whether the rifle part can be optional. I would say no, as the entire moves in a Betza description are already optional. So by making it mandatory to do at least one of the rifle captures, you can still allow the move without capture by specifying it separately. Like for Odin's Forest Ox: N[N,cK].

you'd (apparently) lean toward using ß for Sexton, while I'd use it for Switchback

We're technically not contradicting each other; I was using capital ⟨ẞ⟩, as is usual for atoms, whereas Switchback, whilst really something that XBetza would tend to spell out explicitly, is definitely small ⟨ß⟩ material

That depends; the Windows-1252 character set that I'm suggesting to use as the basis (because even a system without Unicode installed should have at least that much) only has ß. That, I believe is the lower-case letter -- which would rather spoil my use.

By the way, the full XBetza for the Switchback would be afq(afzafq)K(afqafz)K, which I think would be quite rarely used and only needed to be "atomized" for a rifle capture, bent slider, or something similarly strange. So not having it wouldn't necessarily be a big loss, and one of the other letters in the set (like maybe Ï? Or Ş, if all of Unicode is opened up) could still work if I really want it.

I may be wrong, but trying to get XBetza to manipulate a Rose path in that way once it's been defined might be more convoluted than it appears

You may also be right, at least when using a simple qN definition. If that turns out to be the case, then I'd have to find a way to program it using whatever custom-move system that H.G. (and/or Fergus) come up with.

why you want to expand xBetza

As with Bob, really my answer is (at the moment) that I don't; it works well enough for what it does (as H.G. has elaborated on). More that we were discussing a previous commenter's proposal to extend it using non‐ASCII.

I'd still be tempted to hold out a degree of openness for exactly the purpose I mentioned: 3D (let alone 4D) or unusual (hyperbolic, say — I've been musing over an actual Regular Octagonal Chess to match Frolov's approximation) boards where the existing letters would all apply but more would be necessary to cover the extra moves. Though one might equally argue that at that point it's far enough from the familiar that Betza is somewhat out of its depth anyway.

And while hexagonal boards may be in scope for the ID, I imagine 3D and hyperbolic boards are far from it ;‌)

you'd (apparently) lean toward using ß for Sexton, while I'd use it for Switchback

We're technically not contradicting each other; I was using capital ⟨ẞ⟩, as is usual for atoms, whereas Switchback, whilst really something that XBetza would tend to spell out explicitly, is definitely small ⟨ß⟩ material

under my suggestion, I could define Þ to represent the Rose's movement path (possibly with a line something like def Þ = qN -- not just a character replacement, but a definition of a movement path).

Strictly speaking a path‐and‐mode model is not quite what XBetza does; rather it decribes moves in stages.

Which is, to be fair, in line with how Betza thought; the ‘Ferz‐then‐Cannon’ of his Bent Riders article comes easily to XBetza whereas a path‐and‐mode description thereof is cumbersome at best. Conversely path‐and‐mode describes the contrasted ‘Bent Cannon’ much more naturally.

I may be wrong, but trying to get XBetza to manipulate a Rose path in that way once it's been defined might be more convoluted than it appears

The first part wouldn't even need the brackets; mqN works perfectly well. It's trying to get caib[qN] to work that would be the challenge.

So, under my suggestion, I could define Þ to represent the Rose's movement path (possibly with a line something like def Þ = qN -- not just a character replacement, but a definition of a movement path). Then the Rifle Rose could be mÞcaibÞ.

If a bracketed move could be treated as a path, this could be m[qN]caib[qN]

But the bracket notation for describing multi-leg moves is much more intuitive, and hardly any less intuitive than the original Betza notation was for single-leg moves.

I agree with this completely. If I can figure out a move using BBetza, even if the XBetza is technically simpler, I'll do that.

One question you should ask yourself is why you want to expand xBetza.

My answer is: I don't. The use of an extended character set, as I'm suggesting it, would appear on a case by case basis, be programmed by the designer of the variant, and only affect that game's Interactive Diagram.

To clarify an earlier illustration. Normally, qN is more than sufficient to define a Rose, and XBetza is good enough to handle most variations that I can think of. But then there's the "Rifle Rose," which can not only move like a Rose, but make a rifle capture along the same path. There's not really any good way to do that in XBetza.

So, under my suggestion, I could define Þ to represent the Rose's movement path (possibly with a line something like def Þ = qN -- not just a character replacement, but a definition of a movement path). Then the Rifle Rose could be mÞcaibÞ. The definition wouldn't affect anything outside that one specific Interactive Diagram; other users could use a different character for the Rose, use Þ for a different function, or both. The Þ wouldn't even have to appear outside the ID, though I think that a brief explanation in the text would be the polite thing to do.

Addendum: It's already possible (though not generally a good idea) to use any Unicode character for single-character piece ID codes. I haven't experimented yet with using those in captureMatrix and similar functions, but if they work there then that's one problem (provisionally) solved -- though I'd still advise folks to avoid it when possible.

Actually I agree that XBetza has become too obfuscated, and that it has grown that way because of its use as move definition in the Interactive Diagram, where there was demand for pieces with ever more complex moves. But the bracket notation for describing multi-leg moves is much more intuitive, and hardly any less intuitive than the original Betza notation was for single-leg moves.

But it should be kept in mind that the complex, hard-to-understand descriptions in practice hardly ever occur. The overwhelming majority of variants never gets any further than symmetric slider-leaper compounds, which are dead simple. Personally I think it is much easier to read or write BN rather than "bishop-knight compound' all the time. It is certainly moer easy for a computer to understand than colloquial English, and is not beyond the understanding of most people. (While programming languages are.) The reason Betza's funny notation has become so popular is mainly that although it potentially can be complex, the cases needed in practice are quite simple.

BTW, the Play-Test Applet already contains a Betza-to-English converter, even though it is not always perfect yet.

Clearly one argument against expanding beyond ASCII would be disagreement over which letters to include! My preference would be where possible to stick to non‐precombined characters; thus we'd both be ok with ⟨Þ⟩ or ⟨Æ⟩, but I'd avoid ⟨Š⟩ and ⟨Ä⟩ whereas you'd (presumably) take exception to ⟨Ƿ⟩ or ⟨Ꞵ⟩ (assuming those even show up for you).

When Ralph Betza first came up with his funny notation, I believe the purpose was for communicating piece movement capabilities in a brief notation that could be easily read by another person. In contrast, H. G. Muller's xBetza notation has become more of a programming language, and it already comes across as an obfuscated one at that. Personally, I don't use funny notation or xBetza, because it is already too complicated. I prefer to use English for communicating with other people or a full-fledged programming language, such as GAME Code, for programming how a piece moves. One question you should ask yourself is why you want to expand xBetza. If it's to easily communicate more types of piece movement to people, I think it's going to reach a smaller and smaller audience as you add more characters to it. If it is to more easily program types of movement not already supported, I think it would work better to allow the use of longer names through some kind of bracketing, sort of like Game Courier's FEN allows longer names within braces.

I have thought about supporting hexagonal boards in the Interactive Diagram.

The way you describe it could be a handy stopgap, but I'd be more in favor of something specifically made for hex boards, treating W as a move to an adjacent hex, F as a move to a corner-adjacent hex*, and the rest as extensions thereof. The directional modifiers would be the only truly hard bit to figure out, I think, especially with t and w being the only unused lower-case letters for adding, but I suspect that a bit of brainstorming could work something out.

About castlings: one can of course think up any sort of crazy move, and present it as a castling option.

Well, my description of gO was just a random thought, taking the notation to its logical description, and not as something that would necessarily be useful. If the "cascading castle" you describe in the next paragraph after the above seems like a more reasonable (as well as more useful) interpretation, then I say you should go for it -- it's something that I could imagine using in a variant (though I'd be more likely to want a as its notation).

*An awful description, I'm sure, but I think you know what I mean there.

Clearly one argument against expanding beyond ASCII would be disagreement over which letters to include!

This (and what follows) is much of why I argue for using only the ANSI extensions, and even those only for custom (that is, user-defined) atoms. I've already made some private notes for the use of Ä, Ç, Ê, Ë, Ñ, Ø, Ô, Š, Þ, Ü, Ž, and ß (as well as V), some of which I've shared already, but your uses of those characters on an ID could (and probably would) be different from mine.

And as H.G. points out, notation for hexagonal, triangular, and 3D (or more) layouts could (and probably should) start from scratch for meanings. Even so, I can imagine running out of atom letters quite quickly (especially in the last case), and might even overwhelm the extra characters of ANSI, in which case I could see expanding to Greek letters or even Latin Unicode.

...whereas you'd (presumably) take exception to ⟨Ƿ⟩ or ⟨Ꞵ⟩ (assuming those even show up for you).

Those did show up, and you already showed one example of where different people would use the same letter for different things: you'd (apparently) lean toward using ß for Sexton, while I'd use it for Switchback. And we could; I'm not in favor of standardizing the ANSI characters, but rather making them available for use when user-defined atoms are implemented (and I'm not expecting that before the end of next year at best).

The idea of a fixed move that can be described by a notation implies a board with regular tiling. Such a tiling can have other connectivity than the usual 8-neighbor square-cell topology, e.g. hexagons or triangles. But these could have their own, completely independent system of atoms and directions, reusing the available letters for their own purposes.

I have thought about supporting hexagonal boards in the Interactive Diagram. This could be done by representing the board as a table with a column width half the piece-mage size, and give every table cell a colspan="2", in a masonic pattern. That would distort the board to a parallellogram. A numerical parameter hex=N could then specify how large a triangle to cut off at the acute corners. The board could then be displayed without border lines and transparent square shade, so that a user-supplied whole-board image with hexagons could be put up as background for the entire table. This would purely be a layout issue; the rest of the I.D. would know nothing about it. In particular, the moves of the pieces would have to be described in the normal Betza notation as if the pieces were moving on the unslanted board. E.g. a hexagonal Rook would be flbrvvssQ.

About castlings: one can of course think up any sort of crazy move, and present it as a castling option. But in orthodox Chess castling exists to fulfil a real need, rather than the desire to also have a move that relocates two pieces at once. The point is to provide a way to get your King to safety without trapping your Rook, and without having to break the Pawn shield. Sandwiching a piece between your Rook and King doesn't seem to serve a real purpose. If the piece could easily leave you could have done that before castling, and if not than it is still semi-trapped.

A more sensible novel form of castling would be where multiple piece end up at the other side of the King. E.g. when the piece next to the Rook would be a Moa ([F-W]), conventional castling is not up to the task. You would need a castling that moves the Rook to f1, and the Moa to e1, upon castling to g1 on 8x8. Of course you could argue that this is a defect of the start position, and could better be solved by choosing a setup that had a jumping piece on b1/g1.

Clearly one argument against expanding beyond ASCII would be disagreement over which letters to include! My preference would be where possible to stick to non‐precombined characters; thus we'd both be ok with ⟨Þ⟩ or ⟨Æ⟩, but I'd avoid ⟨Š⟩ and ⟨Ä⟩ whereas you'd (presumably) take exception to ⟨Ƿ⟩ or ⟨Ꞵ⟩ (assuming those even show up for you).

One valid use for beyond‐ASCII letters imo would be expanding Betza beyond the square board; we have few enough capitals left that e.g. ⟨Ⅎ⟩ for ‘ⅎiceroy’ or ⟨ẞ⟩ for ‘ßexton’ (both of course Gilmanese) might be in order. And since the ID doesn't do non‐square boards (except through hacks as for Chess66) it wouldn't even need to worry about them. Likewise the non‐square directional qualifiers (I'm maybe grasping at straws a little with ⟨ɂ⟩ and ⟨ƿ⟩ for ‘up’ and ‘doǷn’, but non‐ASCII letters cover an odd sound space…)

There is no such thing as a 'regular keyboard'

Especially when you have people like me who (heavily) customise their layouts; all the characters I've just typed (except the quotation) are accessible for me without copy–pasting

Useless tip:

vsQ = B
vsK = F
vvssQ = R
vvssK = W

(Well, it's probably completely useless right now, but it or something similar might become useful in the future.)

I have an idea for something gO could do, but I'm not sure it'd be used at all (including by me) so I'll leave it alone for now.

Mostly just for the heck of it (but also in case anyone's curious, or might find it useful): My idea was that gO could represent a sort of "grasshop castle" with a single piece between the King and Rook (or whatever the two pieces are), with each of the two taking position on the other side of the intervening piece. (Of course the full notation would be isgO, but the g is the significant part).

It's probably too much trouble to actually code, especially since (as I already stated) I'm not sure that even I would actually use it; I just thought I'd share the idea.

Good answer, and good info.

I have an idea for something gO could do, but I'm not sure it'd be used at all (including by me) so I'll leave it alone for now.

would pO (with other appropriate modifiers, of course) allow castling with an intervening piece?

Sort of. I chose that as the notation of 'Fast Castling', which allows the King to jump over arbitrarily many pieces or attacked squares. The Rook would then move to the King's square of origin, though. So it is not normal castling that can hop.

The O atom is treated somewhat differently from other atoms. (E.g. the range indicator specifies the exact number of King steps, not the maximum as ranges normally do.) It had to, for making the combinations useful.

Just a quick y/n question:

would pO (with other appropriate modifiers, of course) allow castling with an intervening piece?

That my intention was insufficiently clear is, well, sufficiently clear. For that reason, I'm glad you stated your opinion so I could clarify.

You know, I prefer to say my opinion because your intention was not clear.

I completely agree with you HG. I hope those ideas will not crawl into the Betza's notation that you are developping. For me too what matters is the simplicity.

This is pretty much the reason I've been saying that these 31 new characters should be available only for custom moves, programmed by the game designer (or borrowed from another one). It's not inconceivable that one or two might catch on, though I'd consider it very unlikely; while I'd use Þ for a Rose, others might want to associate one or the other with something else, as I've already noted.

I actually would also consider it a headache if any of these additional characters were implemented into XBetza/BBetza during my lifetime. I previously said that I'd use Ø as a null move, Þ for a Rose, Ñ for Quintessence, and Ê for Edgehog; I could also use Ô for the Zpider's (and certain other pieces') move of tracing the edge of the board, and Ü for my Root-N25 Leaper. But I'd only actually use them, or any other extended character, in an ID if writing out the conventional XBetza was even more inconvenient, if I was doing something with it that couldn't be done in conventional XBetza, I was writing against a filesize limit, or some similar reason. A Rose would generally still be qN, but a Rifle Rose would have to be ÞcaibÞ (though it could also be qNcaibÞ).

And now that I think of it, since they'd be based on the custom move machine, I'm not sure they should be implemented for bracket notation.

I completely agree with you HG. I hope those ideas will not crawl into the Betza's notation that you are developping. For me too what matters is the simplicity.

I had no idea that the i could be that far separated from the long move it's supposed to imitate.

The official definition says "as many steps as in the previous slider leg". It would never make sense to mimic the length of a leaper leg, as this is known to be 1. So intervening leaper legs are simply ignored.

It would make sense to slightly alter that definition in the case of multiple iso legs, to "the previous slider leg that is not iso itself, and has not yet been mimicked by an intervening iso leg". This is not how the I.D. currently implements it though. Which probably does make the current implementation useless for multiple iso legs, as it does something I cannot imagine you would ever want.

The q and z modifiers cannot be used in their original Betza meaning of circular / crooked in a multi-leg move. Their meaning in the latter context has been redefined as a directional modifier meaning the same as l or r, but in the same or opposit direction of deflection as the previous one.

The circular and crooked moves were hard to fit into the scheme according to which other moves are handled by the Interactive Diagram. I added a special case of move generation just for those, where a tabulated sequence of legs of a multi-leg move doesn't have to be traversed in its entirety for the move to be valid, but is allowed to stop at any point along the trajectory. This can be combined with (grass)hopping; normally the trajectory would not continue after an occupied square, but would exercise its c or d right there. But in combination with p or g it must continue on the first such encounter, in the latter case exactly one leg. Continuing after capture, or on any other path than the indicated circular/crooked trajectory is not implemented for this type of move generation.

The introduction of parentheses in principle would allow specification of circular and crooked paths in the context of normal multi-leg move generation. But the way parentheses are implemented is very inefficient, which especially hurts the AI. In theory (af)W is the sane as R, but in practice it is expanded to WafWafafWafafafWafafafafW..., which is WnDnHnWXnDX..., a squence of ever larger lame leaps. And for each next leap it will test all squares leapt over, even though the previous lame leaps already tested those. So if the W and D leap in a certain direction are valid non-captures, but the H leap is blocked, it would still try to generate thw WX, DX... leaps, and test the W, D and H squares they pass through for each of those, before coming to the conclusion that these are not possible. The special case of storing only the longest trajectory, and allowing termination at any step along the way, solves this problem. But it is not compatible with straying from the path.

BTW, the I.D. currently does not implement moves with more than one pair of parentheses on an atom. The implementation through pre-processing would really make the length of the XBetza string that results explode if there would be multiple pairs.

That only happens with R and W, not with any other atom. And I'm not sure even that much is deliberate.

I tried your idea, and mine, and a few others, and nothing worked. I have a feeling that if any existing XBetza does work, it'd be more hassle than just entering caibÞ considering it'd be just once, with Þ still available for an unaltered and/or differently-altered Rose. Þ7 can be one that doesn't go around the full circle, Þ3 only goes to the far rim, hrÞ only goes clockwise, [Þ?R] is a Rose-Rook bent slider... the first two are pretty easy with existing code, the second might be, the last I'm not so sure.

But of course others could do it their own way, and even use Þ for something else entirely. (No remembering required!)

h on it's own means the same as b for orthogonal atoms.

A "Rifle Rose" may be as simple as qcaibN -- I honestly don't know, or have time to check it out right now -- but I'd prefer caibÞ

Here's an idea [c[qN]-ib[qN]]

or even [c[qN]-ib[]] with the empty brackets applying the ib modifiers to the previous bracketed path.

Actuially, of the four I listed there, only the Edgehog is a big challenge in XBetza. The null move is mpabK, the Rose is qN, and the Quintessence is zN. For just about anyone (myself included) the XBetza is actually much easier to type than the special character, unless I'm doing something weird with it like turning it into a rifle capture. (A "Rifle Rose" may be as simple as qcaibN -- I honestly don't know, or have time to check it out right now -- but I'd prefer caibÞ.) And anyway, those are just off-the-cuff examples.

I'm curious, though: Why not use the thorn (Þ) for the Rose?

Well, as I said, I don't think I'd make use of them in the main XBetaa/BBetza universe. Allowing their use for custom moves, once that is available, is the furthest I'd go with it. The ideas I cited for specific symbols are just examples, which I'd (at least hypothetically) code myself and make available to others. Others could also assign different effects to a given symbol; unless something really catches on, there'd be no standardization. The symbols wouldn't be used as part of any standard description, but only in specific games.

yafsR should be no problem (yafscabyaifzR).

I had no idea that the i could be that far separated from the long move it's supposed to imitate.

Look out; here comes the Boomerang!

y(a)5K is not valid XBetza (as it includes yK), but I suppose you mean some kind of area move. If there is more than a left-right choice it is indeed not possible to retrace the path using q and z. This could also be solved by a new directional modifier that would do what i does for the range of a continuation leg: mimic a previous deflection.

I realized that it was invalid when I reread it a bit ago. It should've been ya(a)4K -- a King move, followed by one to five Queen moves (that's a simplified version of what the piece I had in mind would do; each leg would be a p, and the end a c -- I just didn't want to mess with calculating that aspect of it).

Well, you unload something that disappeared elsewhere. And if p' means friendly hopping, it seems natural to make u' mean friendly unload, i.e. that you don't unload the captured piece, but the moving one.

That's quite logical and reasonable. Still not "obvious," since p' isn't actually implemented yet, but it definitely makes more sense now than my suggestion of an exclamation point.

I don't get that. A moving piece would always have to follow the entire trajectory; that is the basis of XBetza  notation. So how could it end up anywhere else than at the end?

Take the Drive-By sliders that I posted very recently as a starting example: they move normally, but do sideways a rifle capture  somewhere along the path. Now imagine that, instead of a one-space capture, it went up to five spaces, turned 45°, and went up to three more spaces, and then optionally makes another 45° turn for up to 2 spaces, calling for u' and a~. to trace the rifle capture. The piece moves, makes the "magic bullet" rifle capture, and then continues moving.

Like I said, a rare enough occurrance to make it low-priority, but probable enough to make it an eventual reality.

Also, on the topic of just the u', the Lariat in Zwangkrieg isn't working as intended (I can explain again next week in a Comment on the game's page if need be), and this could work well in helping fix the problem.

This i find a very good idea, 31 new symbols,

Well, I don't know. The success of Betza notation lies in its simplicity. The meaning of most modifiers is obvious (f, b, l, r as directions m, c as move/capture), and for those who are slightly familiar with unorthodox pieces, most atoms as well (standard symbols for orthodox chess pieces, plus W, F, A and D). Perhaps they have to learn a handful of other symbols (v and s, but outside Shogi pieces tend to be fully symmetric, and directional modifiers are only very rarely needed in the first place, p and g.)

Having to know the meaning of '31 new symbols' pretty much destroys that. There is very little benefit in introducing symbols that hardly anyone would know the meaning of.

yafsR should be no problem (yafscabyaifzR). y(a)5K is not valid XBetza (as it includes yK), but I suppose you mean some kind of area move. If there is more than a left-right choice it is indeed not possible to retrace the path using q and z. This could also be solved by a new directional modifier that would do what i does for the range of a continuation leg: mimic a previous deflection.

It doesn't seem obvious to me, but that's probably just me.

Well, you unload something that disappeared elsewhere. And if p' means friendly hopping, it seems natural to make u' mean friendly unload, i.e. that you don't unload the captured piece, but the moving one.

(the "load" spot won't always be the end)

I don't get that. A moving piece would always have to follow the entire trajectory; that is the basis of XBetza  notation. So how could it end up anywhere else than at the end?

This i find a very good idea, 31 new symbols, but we could also use the lowercases for 31 new symbols for modifiers, like the different i's for different cases of initial, so that ii is not needed, for I maybe we could use different Imitators.

Examples of what I personally might assign to those letters include Ø as a null move, Þ for a Rose, Ñ for Quintessence, and Ê for Edgehog.

I like these ideas, outside of Rose, since they couldn't be (easily) written otherwise, we could do like ê as the Edge-Modifier (and possibly ë as the Limited Edge-Modifier). We'd also may need a symbol for relative halfling, i originally thought a lone h, but maybe one of these Windows-1252 symbols works better

I don't see the problem of not being able to reverse the leg. Betza notation is for boards with a translation-invariant 8-neighbor topology, and that it would not work for other boards is normal and unavoidable.

As I said, if the issue was the weird board, than it would be a non-issue. The problem is if the approach path is something like yasfR or y(a)5K (both of which I actually would use; in fact, yasfR is what made me realize that the problem wasn't limited to weird geometries.

If a modifier for self-unloading was necessary, I think that u' would be the obvious choice.

It doesn't seem obvious to me, but that's probably just me.

Then a marker for where the piece "captures" itself, both for this purpose (the "load" spot won't always be the end) and what Daniel brought up would be needed; I suggested the tilde (~) because it's not likely to be needed for anything else, but a` could make a nice counterpart to u'.

I don't see the problem of not being able to reverse the leg. Betza notation is for boards with a translation-invariant 8-neighbor topology, and that it would not work for other boards is normal and unavoidable.

If a modifier for self-unloading was necessary, I think that u' would be the obvious choice.

I wonder if that could be done by having something to indicate self-capture. That could also be used for pieces that self-destruct without unloading.

That would have to also mean without capturing, since self-destrictive capturing can be indicated with a kamikaze move (0 on the captureMatrix). And I think that such a thing should be a modifier directly on the atom, or to the last leg -- though the ~ that I suggested could do the trick.

So, it made me wonder if there could be a way to mark a point in a move, either replaccing or supplementing u, as a point that the piece later comes back to.

I wonder if that could be done by having something to indicate self-capture. That could also be used for pieces that self-destruct without unloading.

While recently working on a particularly weird chess variant with a very odd board, it occurrerd to me that I'd set up certain elements in such a way that, under certain circumstances, a rifle capture might not be able to return the way it came, even if it was a simple diagonal slide (caibB). This was a product of the quirky board I'm using, so I didn't think of it much, but then it occurred to me that some more mildly exotic cases could face the same problem -- a grasshopper rifle capture, to give a simple example.

So, it made me wonder if there could be a way to mark a point in a move, either replaccing or supplementing u, as a point that the piece later comes back to.

I don't think this would be worth using the w or t for; save those for cases with multiple uses. So, punctuation... I recently suggested ! as an atom modifier for a move being possibly one if under/not under attack, but to my eye it's the character that looks most like a bookmark, so it could be used either following u (which would be my preference) or preceding a to "bookmark" the locatioin for later. Then, for going back, follow a with ~.

You may have a different preference for marker(s), and of course there's no rush on this (the above-mentioned CV couldn't use an ID anyway -- though I'm thinking of something with a bent rifle capture on a more traditional board), but I just thought I'd see if I could get some creative gars turning.

There is no such thing as a 'regular keyboard'. Each country has its own national version, and that you happen to have these symbols, doesn't mean that others have them. (Have you ever been in Taiwan?) I do have í on my PC, but not on my laptop.

I think the only place I'd allow characters outside the ASCII standard, such as letters with diacritics, would be as atoms in connection with the custom moves that we've discussed before. Even then, I'd limit it to the capitals in the ANSI/Windows-1252 set (À to ß, skipping × but possibly also including Š, Œ, Ž, and Ÿ). I say this in spite of the fact that I can think of specific uses for several other characters on the lower half of the Windows-1252 table, as modifiers.

Examples of what I personally might assign to those letters include Ø as a null move, Þ for a Rose, Ñ for Quintessence, and Ê for Edgehog. (Maybe even Ä as Aanca, as a Griffin/Manticore compound that could be broken down into orthogonal or diagonal.) But, again, I'd build them as "custom moves" (though I'd also make the code easily available to others).

See, I knew I was getting the u wrong somehow! And I didn't think about the a in bracket notation being different; botching that, honestly, is me all over.

Trying out your bracket notation (I think I'll start calling it BBetza, for Bracket Betza) in the Sandbox, though, it still doesnt work, beyond the R. If it helps, it translates (exactly as I'd expect) to RyafafucabpafR.

It's not incredibly important, though; I was just planning ahead half of a Burn (afafucabpafK) for when the use of the colon is implemented. (The other half, I think, would be apfafucbafK -- to push a friendly piece adjacent to the landing square away to an empty square beyond.)

Thanks for the help on that. :)

There is no such thing as a 'regular keyboard'. Each country has its own national version, and that you happen to have these symbols, doesn't mean that others have them. (Have you ever been in Taiwan?) I do have í on my PC, but not on my laptop.

Grouping of atoms was also proposed by Bob (in various forms, either by enclosing them (and then I would not use parantheses but braces { }), or by connecting them with some infix operator like |.

It may not be neccesary, but we could expand the set of allowed symbols, currently we have;

• Letters, upper- and lowercase, Numbers and Punctuation, may use shift

We could expand to use symbols like í, þ and £, which are all available on a regular keyboard, the special i's could get used for various "cases" of initial, removing the requirement of ii as a special i could take it's place. Edit: Though you'd need Alt Gr for the latter 2 symbols given.

At the current point, i don't really see it happening, since we still have quite some punctuation not yet used

Edit: Could we also have grouping of symbols to make things like c(QNN) for a capture-only Amazonrider

[R?uW-cW-bpafW]

You are mixing XBetza with bracket notation. You cannot do that; a in bracket notation would mean 'all directions', not continuation. You should have written [R?uW-cW-bpW-fW].

But your original [R?ufW-cfW-bD]  is wrong in the first place. It specifies an unload on the start square of two consecutive W steps, and then a D step back. Which would end up on the same square as the unload. What you really want after the Rook move is step to the unload square (fmW), from there swap with the enemy piece (fucW) and step two back (bD). That is [R?W-ucW-bD]. (But note that this makes the attarction of the enemy piece optional; it could stop after R even if there is an enemy piece two steps further.) The D step would have to be split up in XBetza, and not being a 2nd leg the bracket preprocessor won't do that automatically. But it probably would handle [R?W-ucW-bpW-W] correctly.

This would indeed be hard. One way I could see it done was introduce a special symbol as repeat limiter similar to what i does for slider continuation legs, and thus means "as many repetitions as there were in the previous parenthesized group". Suppose that symbol is $, you could write [(mpW-)pW-(mpW-)$cW]. It is a sort of orthogonal Equihopper.

I like this idea, and the choice of symbol. I can see it being useful for a number of different possibilities (like maybe a bent or hopping rifle capture).

OK, so the bD should've been bpaW (or bpafW), and I should've realized that. Grr.

But now I've tried [R?mW-ucW-bpafW] and [R?uW-cW-bpafW] and various other combinations thereof (both with and without the f), and I still don't get the desired effect.

This would indeed be hard. One way I could see it done was introduce a special symbol as repeat limiter similar to what i does for slider continuation legs, and thus means "as many repetitions as there were in the previous parenthesized group". Suppose that symbol is $, you could write [(mpW-)pW-(mpW-)$cW]. It is a sort of orthogonal Equihopper.

This might never be possible, but I wonder if there could be a way to specify a piece that captures like a cannon, but both parts of the move—before and after the mount—must be the same distance, and there can be any number of other pieces jumped over on the either leg.

Well, bracket notation is currently only implemented for two-leg moves: it tries to reduce those to a commensurate atom, and ignores all later atoms, except their leaper/slider nature for determining if a y should be inserted. So when it works it is basically coincidence.

If you assign a new move to another piece, you can see which XBetza the preprocessor produced from your bracket notation. Which in this case is: RyafufafcfabR . So you see it did understand that the move could end at R, and it did understand there were 4 legs (3 as), it did understand it had to switch from slider to leaper after the first leg. It got a bit confused about the directions, because you added an f where no f was really needed, because that is already default. And you did that after a mode modifier (while I always do directional modifiers first), so that it did not notice it. Hence it adds a redundant f before the u and c. But I don't think that would hurt. It did understand that two continuation legs were f, and the 3rd b.

What it did not understand is that the 4th leg was D. Because it never looked at it, other than classifying it as a leaper, so that it should not toggle back the W to R. So it was close, but no cigar...

I'm trying to build a piece that moves like a normal Rook, and then, if there's an empty square in the next space forward and an enemy piece in the next space beyond that, pulls the enemy piece into the empty square. I'm still a bit inexperienced with u, but it seems to me that the bracket notation should be built thus:

• The basic move, R
• The rest is optional, so ?
• The next space is to be a destination, so ufW
• Then capture the enemy piece in the next space, so -cfW (said enemy will then go to the first space)
• The jump back to where the Rook move ended, so -bD

But when I try [R?ufW-cfW-bD] out in the Sandbox, the enemy piece and moving piece just end up in each others' places. I'm not sure what I'm doing wrong here.

I like that idea for the %. It's actually quite intuitive for the symbol's conventional meaning. The only question is, what effect would that have on a Rook on a rectangular board? If the board is 12x16, would the half-Rook move six spaces sideways and eight spaces vertically? (That actually would make the most sense to me.)

As for using ' and " to "retire" d, I think the letter would have to be retained for backward compatibility. Otherwise, I think we'd have freed the L and J atoms by now. (I personally would welcome seeing all three characters freed up for potential new uses -- like, an atom for Bison (CZ), mainly for use with Cheetahs, Sabertooths, and related pieces, which I wouldn't try to do with the smaller number of free atoms we have right now.)

On a (mostly) unrelated note, I'm finding trouble when I try to put more than one pair of parentheses into a move, whether nested or sequential. For an example of the latter, I've tried expanding the Springer's pya(b)K move so that it can bounce off more than one target, but pya(b)(pa)K (or even pya(b)(pa)2K) doesn't yield anything but an error message ("No atom at end").

PS: With some experimentation, I've found that shQ and shK yield "all directions except forward and backward," while vhQ and vhK yield "all directions except left and right." I just thought I'd point that out; I think it'd be worth documenting. :)

gafQ3

Bracket notation is a proposal for future improvement, and basically not implemented. A few cases representing commonly used pieces such as Griffon are recognized, and handled by a pre-processor that substitutes the corresponding a-notation. The S is apparently not amongst the recognized cases. (This might be easy to fix.)

Range limits on hoppers has always been a problem in XBetza, because you would really need two ranges: one for before, and one after the mount. The rules for range toggling (triggered by g or y) are such that the specified atom + range count for the first leg, that finite range turns into infinite, and infinite into 1. So gQ4 means up to 4 steps to the mount and infinitely many behind.

Bracket notation would solve this, by allowing you to specify a range in each leg. But it is not implemented yet.

Reusing an existing symbol has little advantage if you have to introduce a new symbol to resolve the ambiguity it causes. IIRC 'halfling' is a (flexible) range specification, so it would be more natural to indicate it as a (non-numeric) suffix than as a modifier prefix. I would suggest the % sign, as the actual range should be a fraction of the free path. We could even give different meaning to W% and R%.

As a symbol on its own checking for a piece is already done by p. If a combination of symbols is to be used for specifying whether it should be friend or foe, I'd rather use p' and p" than a t. The quotes could be used to diversify other modifiers as well. E.g. c' could be friendly capture, and c" friendly or enemy capture. Than d could be retired.

Indeed, screen = mount = platform. Two platforms you can already do by [pB-pB-cB] or pafpafcB.

@Aurelian: What do you call "platform"? Do you mean the "screen", as defined in https://www.chessvariants.com/piececlopedia.dir/pao.html?

I think a nice feature would be to allow multiple platforms for cannon like pieces. Personally as I don't like the idea of bishops in a Xiangqi or Janggi environments I'd like a pRppcR instead (where pp stands for 2 platforms). Some food for thought.

Somethings i want to note and some ideas

• gK should be able to be written as [jS?Q] but the latter moves completely different
• gQ4 i expected to be a grasshopper, not a lion, limited to 4 tiles in total, the case of up to 4 tiles after hurdle can be constructed using square brackets [gQ?Q3] (i think, doesn't work in the diagram on the page)

• h on it's own has no definition, something like relative half, from the halfling, could work
  • This does make left-only half impossible as lh and hl already have a meaning, you could use a punctuation like a comma , to seperate them so that the compound doesn't work, with this , you can make a move that's initial and non-leaping, but does not create e.p. rights i,n
• t could be used for checking if there's a piece there, adding c or d to specify enemy or ally piieces

Moves that are only allowed when you are attacked are much harder to implement. They are a form of enemy induction. (Which the I.D. also doesnt't implement for that reason.)

I actually was thinking that it could be something that the new off-site AI you mentioned being in the early stages of working on might be able to manage. And HaruNY did point out a few other cases where the rule is used.

It's something to consider, at least, as you're building said AI engine. :)

So I will change the definition to that it should not go back to the previously visited square on the path.

That, I think, would be the ideal. :)

A good algorithm would be to tabulate first which squares you can reach in one step, and then from all of those take another step to tabulate those you can reach in two steps, eliminating duplicats at every stage.

That can be great, though sometimes where a piece can move from a square depends on where it came from. With a Rose, for example, any square that can be reached in 2 or 3 steps has two ways of approaching (unless blocked), and each of those two ways has a different allowed exit -- four if the Rose is allowed to go full circle. Some complex bent sliders, the Combine being the most common, also have overlapping moves. The algorithm would be perfect for pieces like the Ubi-Ubi or Shogi area movers, and probably would also improve regular radial sliders and oblique riders (especially those with cannon, grasshop, or juggernaut moves), but there should be some way to allow for "this way in, that way out" (like ignoring the elimination of duplicates after a turn modifier is encountered).

I am not sure that rules like this would qualify as being part of the move. Betza notation is supposed to describe the pseudo-legal moves of a piece, and that some of those might be forbidden in a real position because of the constellation of pieces outside the path, is what makes the difference between legal and pseudo-legal moves. Moves of pieces in a variant that has a checking rule are not written differently than in a variant that hasn't.

A rule for not being allowed to move out of attack can be implemented in the AI relatively easily: you test for in the reply move whether you can capture to the evacuated square. This is how the ban on castling out of (or through) check is implemented to. The AI is not aware it is in check, but on castling it marks the King's origin and passed-through squares as 'royal' e.p. squares, and considers any capture-capable move to it in the next half-move as an (immediately winning) King capture.

Moves that are only allowed when you are attacked are much harder to implement. They are a form of enemy induction. (Which the I.D. also doesnt't implement for that reason.)

-King can't castle when in check in Chess

-King may not move out of check, except to capture its singular attacker in Makpong would be !mKcK.

-Vaulting Camel-King from fairy chess problems would be K!!C

-Transmuting King from fairy chess problems (King but when it is threatened, moves only like the threatening unit(s) (!K+Orphan))

-Tengu pieces from MAD Chess

-etc.

Not if the move is a leap. Imagine, for example, a Flame-ingo with [CX;KD].Or, probably more to point, a piece with K[T;K] -- or should that be K[T;abK]?

In the former the burn would go to all 12 squares, as none of the KD steps is perfectly aligned with CX. In the second case one of the moves would go exactly in the backward direction. Although it doesn't seem a disaster having to write ab, I guess it shows that there really is no reaason to forbid moves with another stride. So I will change the definition to that it should not go back to the previously visited square on the path.

That reminds me that in XBetza at some point I defined it as not being allowed to return to any previously visited square, to prevent that aaK could make a turn pass by triangulating. Of course this was pretty much unimplementable. Now as the Ubi-Ubi (which basically has an unlimited-range area move with Knight steps) shows, area moves really need a dedicated generator if you want to treat those efficiently. (As is very important for the AI.) There is just too much overlap between them. (a)2K has 456 possible realizations, but these reach only 49 squares. So each move is generated some 9 times on average. A good algorithm would be to tabulate first which squares you can reach in one step, and then from all of those take another step to tabulate those you can reach in two steps, eliminating duplicats at every stage.

Good question. It makes less sense to exclude it here. OTOH, normally this square has to be empty, or it would have blocked the move.

Not if the move is a leap. Imagine, for example, a Flame-ingo with [CX;KD].Or, probably more to point, a piece with K[T;K] -- or should that be K[T;abK]?

Well, I tried to generalize it. But I think I blew it, because I was thinking in terms of steps rather than moves when I wrote it.For the conventional 'orthogonal planar move', which we would write here as [vR.sR], the point is that the steps set up a grid (in this case containing every board square), and that you only have to consider what is on that grid. But (on an empty board) every square of the grid could be reached by zero-or-one move of the first kind plus zero-or-one move of the second kind. The area spanned by the move (which must be empty) consists of all squares that could be reached by fewer or shorter moves of both kinds.

Yeah, I was thinking Rook/Bishop when I was reading it, not Wazir/Ferz. This explanation is much better, and reflects what I recall.

I used the dot because I saw it as a multiplication. A comma could also be suitable, if you see it as coordinates.

I'm actually seeing the planar move as a simultaneous two-way move; that's why I was suggesting the ampersand. (Another symbol that makes sense to my brain is the slash -- though it's also one that I think would probably confuse the computer!)

Also, I'd wonder whether directly backwards is part of the default, or would have to be added.

Good question. It makes less sense to exclude it here. OTOH, normally this square has to be empty, or it would have blocked the move. So it only becomes an issue for a burning Grasshopper move. As it seems quite unlikely anyone would use that, there seems little harm in excluding it. Just for uniformity with other continuation legs. It is easy enough to add it through ab, while it would be very hard to exclude it.

the description there doesn't match up with the explanation that I recall being given to me.

Well, I tried to generalize it. But I think I blew it, because I was thinking in terms of steps rather than moves when I wrote it.For the conventional 'orthogonal planar move', which we would write here as [vR.sR], the point is that the steps set up a grid (in this case containing every board square), and that you only have to consider what is on that grid. But (on an empty board) every square of the grid could be reached by zero-or-one move of the first kind plus zero-or-one move of the second kind. The area spanned by the move (which must be empty) consists of all squares that could be reached by fewer or shorter moves of both kinds.

I used the dot because I saw it as a multiplication. A comma could also be suitable, if you see it as coordinates.

The Ubi-Ubi is of course a sick piece. The problem is that the current implementation of the I.D. tabulates each angular realization of a given move, and for multi-leg moves that can freely change direction that quickly explodes. Even the Tenjiku area move, (a)2K, produces some 500 trajectories.

Ughh, that would be a problem indeed. Better use a semicolon for the burning then.

Something just occurred to me about punctuation in the notation. How would : (for burn moves) interact with the use of colons in Interactive Diagram coding?

(I think that this is what Bob had in mind too, but he wrote the u in the wrong place.)

Guilty on both counts! :)

I think that this is an excellent documentation for full bracket notation, but for two or three quibbles.

One is a typo: in the paragraph on Burning, you say "color" instead of (the first time of) "colon." Also, I'd wonder whether directly backwards is part of the default, or would have to be added.

Second, while that's a dead-on explanation of a as used in this context. I think it's worth mentioning that a(b) or ab can be used for any direction including exactly backwards. (My experience is that for former works, but not the latter.)

About planar moves: This needs a clearer explanation of what a planar move is. Besides being convoluted (for brevity, no doubt; "Hello, Mr. Kettle"), the description there doesn't match up with the explanation that I recall being given to me. Also, this might be a better use of & (as referred to in another Comment) as being both more visible and (arguably) more intuitive than ..

PS: The Ubi-Ubi as (a)N is pretty simple, though it does seem to overwhelm the system (at least, on my computer, which is particularly powerful).

Dabbabante is (mpaf)D.

Thanks for that! I was trying to figure it out a while back, and here's the very obvious solution.

I wonder what (mpaf)A would be. Elephante? Then (mpaf)S could be Alibabante....

I think that's a good use of @, ', and ", and your note about quotes looking like suffixes is a part of why I prefer | for the "or" function -- & would be (or at least look like) more of an "and" function, like trying to make an alternative to bracket notation.

And consider my Grandmaster Mage, currently notated as ooKooCooZooudcKooudcCooudcZaooxKaooxCaooxZ. (I probably can delete the first triad, perhaps with an m in t he second, and the last one may need another oo, but that's irrelevant here.) It would be much shorter with (treating the other string as though it's correct) ooK|C|ZooudcK|C|ZaooxK|C|Z, which is less than half as long.

A thought on ' and " on p (and presumably g): Doing this would still leave those marks open for similar but different meanings ono other modifiers. I have no ideas on what such meanings could be; I just thought I'd point that out.

Aside: Long-term, I'd like to eventually see ! used as an atom suffix for "not when under attack," and !! for "only when under attack." But that's admittedly a fairly low priority, since at this time the Chicken Pawn is the only piece I'm aware of that would use it (maybe the Anti-King and/or Orphan).

Well, what you propose is not backward compatible with what we have, so that rules it out no matter what. I think repetition through parentheses is more flexible than on individual modifiers, and can achieve the same thing. KaKaaK can already be written as (a)2K, and if all steps should capture as c(ac)2K, or (ca)2K if the last step does not have to capture. Exactly 5 Wazir moves can simply be written out in full aaaaaW. The Ubi Ubi can already be written as (a)N.

But I want to get rid of the a notation (which was the core of XBetza), which quickly gets very obscure. And the need to express everything with a single atom is often very cumbersome, requiring many mp intermediate steps for what really is a single (but incommensurate) leap. The bracket notation, which is somewhat similar to a very old proposal that I called Betza 2.0, would solve all that. But I never think there was any formal specification of it, which should be a first step. So:

Betza 2.1

All extensions of XBetza apply, except that the a modifier is not used for chaining, y does not exist, and g exists only as legacy from original Betza notation (i.e. in a single-leg move describing a grasshop).

Complex moves must be surrounded by brackets [ ]. Within the brackets there can be a number of simple Betza move descriptors, each describing a leg of the move. These can be separated by hyphens - or question marks ? . The meaning of a question mark is defined as

[A?B] = [A][A-B]

The hyphen indicates chaining: the legs must all be made one after the other, the next one starting where the previous one ended, each satisfying the conditions that their Betza notation specifies. The default mode for non-final legs is m. This doesn't exclude the leg descriptions from being compounds:

[A-BC-D] = [A-B-D][A-C-D]

Directional modifiers in continuation legs are interpreted relative to the preceding leg, where f is default, and means "as much in the same direction as possible". Since legs need not use compatible atoms, it is not completely trivial what that means. So to be more specific:

• Diagonal after diagonal and orthogonal after orthogonal: f = exactly the same direction (W system).
• Diagonal after orthogonal and orthogonal after diagonal: f = two moves, deflecting 45 degrees (F system).
• Orthogonal after oblique: f = in the direction of the longest orthogonal component (W system).
• Diagonal after oblique: f = in the same quadrant (W system).
• oblique after diagonal: f = two moves in the same quadrant (N system).
• oblique after orthogonal: f = two moves closest to that orthogonal axis (N system).
• Oblique after oblique: f = in the same octant (K system).

The use of an 8-fold radial (pseudo-)atom like K or Q after oblique might result in undefined behavior, unless all directions are allowed. After diagonal or orthogonal atoms these use the K system, with f is in exactly the same direction.

In this system a is a new directional modifier for use in continuation legs, meaning "all directions, except to squares that were already visited earlier in the path". And 'the path' is supposed to also contain the square of origin.

The bracket notation always specifies completely (i.e. 4-fold or 8-fold) symmetric sets of moves. If the use of compound legs allows non-congruent paths, each such path will be included in all its orientations (including reflections). That means directional modifiers on the first leg are not allowed. To define a subset of these moves, directional modifiers should be placed before the brackets.

Paths that completely stay on one diagonal or one orthogonal will be considered of that symmetry; other paths are considered oblique. Directional modifiers in front of the brackets will be interpreted in the symmetry class of the trajectory that is subject to it. For oblique moves the direction in which the path first steps of an orthogonal or diagonal determines in which of the two adjacent octants it belongs. E.g. for a Ship, the symmetric move set is that of a Griffon ([F?R]), and the first oblique squares on its allowed paths are that of the narrow Knight (vN). The Ship is thus v[F?R].

Consequence: describing trajectories of different symmetry in one bracket notation can be asking for trouble if you want to make a selection. If you write fr[R?sR] the brackets describe both orthogonal and oblique moves. For the Rook moves fr means forward or right, but for the hook move it means the forward one of the rightmost pair, which would be first right and then forward.

Prentheses can be used to indicate the text they enclose can occur zero or more times; a number behind the closing parentheses indicates the maximum number. E.g. [(pR-)cR] is a Rook move that must capture, but can hop over arbitrarily many occupied squares to do so.

Burning: trajectories of 'flames' can be appended as extra leg(s) within the brackets, separated from the real move by a semicolon ; rather than a hyphen. The piece would in any case end up in the destination specified by the last leg before the semicolon (to which the rules for a final leg apply). From there any valid move of the burning spec (interpreted as continuation legs of the move, as far as directional modifiers and i legs go) would then burn its destination. E.g. [Q;cK] would be an Advancer, burning the square just beyond the one where it stopped, [Q;acdK] would burn all pieces (friend and foe) adjacent to the destination, [Q;ibQ-cK] would be a Withdrawer, and [R;ap'D-bcW] would be an Ultima Pincher Pawn if p' indicated friendly hopping.

Planar moves: (proposal) these could be indicated by two moves within brackets separated by a period. The meaning of [A.B] would be that any move consisting of zero or more repetitions of a move described by A and a move described by B would be valid if any move with a smaller number of such repetitions of A and/or B would end on an empty square.

You can already shorten KaKaaK though by 1 character by writing (a)2K. Dabbabante is (mpaf)D.

I found an interesting method of applying a on the wikipedia page of Ko Shogi, where for example a4 means "up to 4 times", thus KaKaaK would be rewritten as a3K. You could also add an ! to indicate that it must use that exact amount of step, no more, no less. a!5W indicates exactly 5 Wazir moves
Note : In the context of Ko Shogi these multi-steps are allowed to capture a piece on every step, maybe we should do ac3 or another punctuation to indicate multi-capture or something else. This also means that a1 has no definition and a is a2. Edit: The new a, if it were to be defined as a2, would be defined as a combination of the old a and non-a move, which may be weird and or difficult to implement. The old a would be a!2

With this aa is opened up and i think a good idea for what it should be is "as many times as you want", based off the doubling of leaper atoms, which gives us the notation of the Dabbabante and the Ubi-Ubi, being aaD and aaN respectively

I was thinking of something like dabaubR where each successive leg should not be longer than the previous.

If I understand this correctly that means a Rook that relocates the friendly piece at the end of its extrapolated move to any of the squares it passed over. Requiring a certain order of the intermediate 'transition squares' is difficult for back-and-forth movement, but comes automatic when you always move in the same direction. E.g. the Valkyrie in Odin's Rune Chess is basically a simplified version of what you use here, which can ony relocate a piece on its destination. Rather than first picking off the piece, and then moving back to the point where you want to unload it, (which would require length restrictions to not overshoot the origin), I described it as first moving to the unload square, and then continuing to the target ([Q-udQ] or  afudQ). That automatically guarantees the unload is between origin and destination.

So in the case you describe you could at least first move to the unload square. Unfortunately there is no such freedom for the destination; this always has to come last. So you would get an m slide to the unload square, fud slide to the piece that should be relocated, and then an m slide back to the destination. The 3rd leg should be shorter than the 2nd, which you can enforce by making the last leg an i leg, and split the 2nd leg into two: [Q-uQ-dQ-ibQ] or afuafdaibQ. Another way to look at that is traveling origin - unload - destination in the same direction (to enforce the order), followed by a friendly rifle capture in that same direction.

(I think that this is what Bob had in mind too, but he wrote the u in the wrong place.)

I wanted to reserve @ as atom for indicating dropping. Single or double quote behind a modifier was proposed for friend-only or foe-only (e.g. on p). For grouping of atoms I would use braces {} rather than overloading the parentheses. But  I like the double-quote idea better (except that I would use &, as I thend to interpret quotes as suffixes of the previous symbol), as meaning 'same group of modifiers as previously'. I don't think that would be very useful in the bracket notation, though, as there will never be very many modifiers on an atom there. And perhaps it is more useful to focus on a full implementation of the bracket notation than trying to keep the a notation bearable through all kind of quirky tricks.

And one can also look at it this way: an unwieldly Betza notation is a very useful 'red flag' to indicate you are attempting to do something that you really should not do. The complexity of Betza notation reflects the complexity of conceiving the moves when playing, and perhaps that is a good thing.

(Sadly adding entirely new modifiers will be difficult, as only the letter w is still unused.)

Actually, t is also unused. (But that only helps a little.)

Aside: I like the increasing use of punctuation here. So far I can find ()[]-?*', with a proposal for :; I'm not sure what's still available, though. At least +{}"`, I'm pretty sure, and I'm guessing at least most of \|@#$%&!, should anything more be needed that punctuation would cover. (I can't think of anything right now, though when certain new things are implemented I probably will).

Addendum: After a couple of hours, I thought of something. There probably should be some way to indicate that the same set of modifiers applies to multiple atoms; that would be handy for when that's being done with especially long modifier strings and/or several atoms. The simplest might be to enclose the atoms in parentheses, though putting a pipe (| sometimes used to mean "or") or double-quote (", sometimes used as "ditto marks," meaning "same as before") could work too. So (giving a more or less random example) while a (0,1)-Zigzag Nightrider is Nabl(abz)N, doing the same with a Buffalo, which would now be NCZabl(abz)Nabl(abz)Cabl(abz)Z, it would be NCZabl(abz)(NCZ), NCZabl(abz)N|C|Z (which would be my choice), or NCZabl(abz)N"C"Z.

(I'm not expecting that next week, or anything. It's just something to ponder.)

I don't see how you can express a shorter leg like that. I was thinking of something like dabaubR where each successive leg should not be longer than the previous. The only way that seems possible now is to do every possible combination of different numbers of W steps. But you understand it all better than I do

I don't think dabaubR is quite what you're after; the u should come before the d, if you want your Rook-like piece to move a friendly one. What you have there would simply make the friendly one disappear, and then move any enemy piece it captures at the end to an earlier point in its move. The effect you're after there would be more like uafafdaibR -- the first move forward sets the landing spot for the other piece, the second sets the landing spot for the moving piece, the third picks up the other piece and transports it to the landing spot, and the backward move puts the moving piece at its landing spot.

It seems to me it can already be expressed by inserting an extra slider leg in the same direction for making up the difference.

I don't see how you can express a shorter leg like that. I was thinking of something like dabaubR where each successive leg should not be longer than the previous. The only way that seems possible now is to do every possible combination of different numbers of W steps. But you understand it all better than I do

Another idea that's probably also too unusual to matter is to allow repeated p modifiers in a single leg so i could be applied to a move that hops over multiple pieces.