Comments/Ratings for a Single Item

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.