Check out McCooey's Hexagonal Chess, our featured variant for May, 2025.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

EarliestEarlier Reverse Order LaterLatest
Betza notation (extended). The powerful XBetza extension to Betza's funny notation.[All Comments] [Add Comment or Rating]
Bob Greenwade wrote on Tue, Feb 27, 2024 06:09 PM UTC:

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.


💡📝H. G. Muller wrote on Tue, Feb 27, 2024 09:08 PM UTC in reply to Bob Greenwade from 06:09 PM:

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...


Daniel Zacharias wrote on Tue, Feb 27, 2024 09:29 PM UTC:

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.


💡📝H. G. Muller wrote on Tue, Feb 27, 2024 09:41 PM UTC in reply to Daniel Zacharias from 09:29 PM:

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.


Bob Greenwade wrote on Tue, Feb 27, 2024 10:31 PM UTC in reply to H. G. Muller from 09:08 PM:

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.


Bob Greenwade wrote on Tue, Feb 27, 2024 10:36 PM UTC in reply to H. G. Muller from 09:41 PM:

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).


💡📝H. G. Muller wrote on Wed, Feb 28, 2024 07:40 AM UTC in reply to Bob Greenwade from Tue Feb 27 10:31 PM:

[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.


Niels van Ham wrote on Wed, Feb 28, 2024 09:08 AM UTC:

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


💡📝H. G. Muller wrote on Wed, Feb 28, 2024 10:09 AM UTC in reply to Niels van Ham from 09:08 AM:

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 |.


Bob Greenwade wrote on Wed, Feb 28, 2024 03:15 PM UTC in reply to H. G. Muller from 07:40 AM:

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. :)


Bob Greenwade wrote on Wed, Feb 28, 2024 03:48 PM UTC in reply to H. G. Muller from 10:09 AM:

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).


Bob Greenwade wrote on Thu, Feb 29, 2024 10:51 PM UTC:

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.


Daniel Zacharias wrote on Thu, Feb 29, 2024 11:16 PM UTC in reply to Bob Greenwade from 10:51 PM:

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.


Bob Greenwade wrote on Fri, Mar 1, 2024 03:35 AM UTC in reply to Daniel Zacharias from Thu Feb 29 11:16 PM:

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.


💡📝H. G. Muller wrote on Fri, Mar 1, 2024 06:48 AM UTC in reply to Bob Greenwade from 03:35 AM:

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.


Bob Greenwade wrote on Fri, Mar 1, 2024 07:41 AM UTC in reply to H. G. Muller from 06:48 AM:

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'.


Niels van Ham wrote on Fri, Mar 1, 2024 07:44 AM UTC in reply to Bob Greenwade from Wed Feb 28 03:48 PM:Good ★★★★

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


💡📝H. G. Muller wrote on Fri, Mar 1, 2024 08:00 AM UTC in reply to Bob Greenwade from 07:41 AM:

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?


💡📝H. G. Muller wrote on Fri, Mar 1, 2024 08:14 AM UTC in reply to Niels van Ham from 07:44 AM:

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.


Bob Greenwade wrote on Fri, Mar 1, 2024 03:30 PM UTC in reply to H. G. Muller from 08:00 AM:

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.


Bob Greenwade wrote on Fri, Mar 1, 2024 05:12 PM UTC in reply to H. G. Muller from 08:14 AM:

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.


Bob Greenwade wrote on Fri, Mar 1, 2024 05:21 PM UTC in reply to Niels van Ham from 07:44 AM:

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?


Daniel Zacharias wrote on Fri, Mar 1, 2024 06:32 PM UTC in reply to Bob Greenwade from 05:21 PM:

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.


HaruN Y wrote on Fri, Mar 1, 2024 11:07 PM UTC in reply to Niels van Ham from Tue Feb 27 08:02 AM:

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


Bob Greenwade wrote on Sat, Mar 2, 2024 01:41 AM UTC in reply to Daniel Zacharias from Fri Mar 1 06:32 PM:

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!)


25 comments displayed

EarliestEarlier Reverse Order LaterLatest

Permalink to the exact comments currently displayed.