Check out Atomic Chess, our featured variant for November, 2024.

Enter Your Reply

The Comment You're Replying To
H. G. Muller wrote on Sun, Oct 13, 2013 10:48 AM UTC:

A few more issues that I haven't thought through very well yet:

Royalty - Bex proposed a modifier to indicate royalty, but I wonder how useful that is. Betza notation is about indicating moves, and the concept of royalty doesn't only affect the royal piece, but the moves of every piece. (You cannot move pinned pieces, and when in check you cannot move most pieces.)

Nevertheless I see some use for a modifier that indicates you cannot make the move (or leg of a multi-leg move) when the square you are going to is under enemy attack. This can be useful for the 'pas through check' issue on castling moves. It can also be useful to encode the Chu Shogi restrictions on Lion trading, where you cannot capture a protected Lion from a distance with another Lion.

Flags - For encoding of e.p. captures it would be nice to have some support for e.p. rights. Such rights are just as much apart of the game states as the occupancy of board squares, so it would be logical to have moves that affect them express this explicitly, just as they explicitly specify they will clear out a specific square they jump over.

One way to do this would be by introducing pseudo-atoms S (set) and T (test). S would remember the current square, T would compare the current square with the remembered square of the previous ply, and fail (= block the move) if they are not equal. This would allow encoding for the FIDE Pawn as

fmWfcF(ifW02-S)(rcW-T-lW)(lcW-T-rW)

The last three moves (in parentheses, for clarity only) would describe the double push (initial only, and at the end remembering the location of the pushed Pawn), and the rightward and leftward e.p. capture, respectively. The latter capture a sideway adjacent Pawn via a W step, but then test with T if this Pawn was just double-pushed. If not, the move is blocked, but if it is, it steps forward to its destination. (Clever use of the chirality rules would allow merging of both e.p. moves to a single chain, starting with fscW, but I did not want to cloud the discussion here with that.) Seems straightforward enough to be worthwile...

Berolina e.p. is more tricky, because neither the skipped square nor the location of the e.p.-capturable Pawn provide enough information to unmbiguously specify the allowed capture. So you need to remember both, which requires a further specification of S and T. This could be written as S1, S2, ... (a bit ugly, because the literal interpretation of this would be repetition of the S or T atom, which is not what we mean, and would be pointless). So Berolina Pawns would become

fmFfcW(ifF-S1-mF-S2)(crW-T2-blF-T1)(clW-T2-brF-T1)

S2 remebers the Pawn position, and the first sideway W capture checks if it removed that Pawn. Then it doubles back to the square originally in front of the capturing Pawn, and test there with T2 if it is now on the square skipped b that Pawn. (Note there is no need to specify this should be empty: the double-push already verified that.)

Limiters - Modality modifiers restrict what an atom can do, e.g. c for capture only. They might not always restrict it enough, however. Suppose we are playing with an 'iron' piece that cannot be captured. Or perhaps 'relatively iron', so that it is only immune to capture by a certain piece, or even by a certain move of a certain piece... The Ultima Chamelion suggests itself: it can capture pieces only in the way pieces capture it. And the way we implement the explosions of Atomic Chess, by having 'ejected fragments' capture the surrounding pieces, needs to exempt Pawns. It would be nice if we could detail the c modifier to more precisely specify what exactly we are allowed to capture. (Where the default of course is 'all opponent pieces'.) Like c{L,+Ky} for "can only capture Lion or promoted Kylin", or c{!P} for "cannot capture Pawn". A 'reciprocal capturer' in a FIDE context would be

mQc{P}fFc{N}Nc{R,Q}Rc{B,Q}Bc{K}K

Knight-relay Chess could also use a limiter on the t modality that hops over own pieces only: every piece would have the move t{N}N-bN-aN, which tests if there is a friendly Knight to hop over at a Knight-jump's distance, and when successful doubles back to the square of origin, and from there moves like a Knight in all directions. It had to make the small detour to pick up the Knight move!

Absolute location - Characteristic for Chess is that moves of pieces are defined relative to the square they are on. There are a few exceptions, however. In Chess960 a King always ends up on g1 after O-O, no matter where it started. It would be nice to have a way to describe "move to g1". This could be done in a general way by allowing a pseudo-atom to test if you now are on g1. This makes it easier to put restrictions on how you could move to g1, which, after all, might not b possible from anywhere, or always. (E.g. with Chess960 castling it would not be possible if the squares between your King's current location and g1 are occupied.) So you can use the full power of Betza notation to specify any method of locomotion, and then chain the pseudo-atom that tests if you are on g1 behind it.

In fact this looks very much like what the T pseudo-atom did. That one tested for being on a square that was remembered from a previous move, what we want now is doing the same for a constant, absolutely given square. Like T#g1. At some point in the description of the castling you could then have R-T#g1, meaning "slide like a Rook to g1", which would fail if a Rook could not get there. Looks a bit ugly, though. (But then again, Chess960 is an ugly variant. ;-) )

Suicide - Perhaps I was a bit rash in proposing xx as a special notation for a self-destructive eruption (= explosion). There already existed a way to encode this without this special rule. Pieces cannot destroy themselves, as you pick them up first (or the O atom would always be blocked), so dO does not work for suicide. But fragments from an eruption can kill you, if you are not careful to disperse them. A -xadK suffix on a move would expose all your friendly neighbors to lethal fragments, but -xdO would only expose yourself (just as lethally). For pure Kamikaze moves this does not seem inferior to the -xxO suffix that the extra rule had in mind. And for Atomic captures you would simply write -xdO-acdK suffixes on capture moves, specifying the fragments first destroy yourself, and then move on in all directions for a K step that captures and destroys.

User-defined shortcuts - This perhaps is a bit beyond the scope of Betza notation per se, but in definition of an entire game it might be convenient to be able to define your own atoms. Any Betza notation between parentheses behaves like it is an atom, syntactically, after all. To define Atomic Chess, it becomes a bit tedious to suffix every capture move with -xdO-ac{!P}d{!P}K. This whole combination could be written as -X, after the user defined what X means.

Creating objects - In a game like Amazons, a move consists of moving a Queen, and then having it throw an arrow to an empty square. So the move creates something that was not there before, rather than just moving or capturing pieces. Seirawan gating also does that. Perhaps this could be handled by creative use of the u modality modifier. This now is defined to 'unload' what you picked up in a previous leg by capture. Its use could be allowed even before you captured something, unloading something any piece 'carries' by default. This would solve the Amazons problem, where both sides throw the same dead objects, and mQ-auQ-ebQ would do it. Another interpretation of an 'unprimed' unload could be that you unload something from your holdings by default (where in Amazons your holdings are stuffed with Arrows, which have no moves). This would solve Seirawan, where every piece could get an extra version of its normal move prefixed with iuO- to unload a held E or H on the starting square of a virgin move. An alternative is to slam a limiter on the unload modality, u{L} to detail what you can unload.


Edit Form

Comment on the page Betza Notation

Conduct Guidelines
This is a Chess variants website, not a general forum.
Please limit your comments to Chess variants or the operation of this site.
Keep this website a safe space for Chess variant hobbyists of all stripes.
Because we want people to feel comfortable here no matter what their political or religious beliefs might be, we ask you to avoid discussing politics, religion, or other controversial subjects here. No matter how passionately you feel about any of these subjects, just take it someplace else.
Avoid Inflammatory Comments
If you are feeling anger, keep it to yourself until you calm down. Avoid insulting, blaming, or attacking someone you are angry with. Focus criticisms on ideas rather than people, and understand that criticisms of your ideas are not personal attacks and do not justify an inflammatory response.
Quick Markdown Guide

By default, new comments may be entered as Markdown, simple markup syntax designed to be readable and not look like markup. Comments stored as Markdown will be converted to HTML by Parsedown before displaying them. This follows the Github Flavored Markdown Spec with support for Markdown Extra. For a good overview of Markdown in general, check out the Markdown Guide. Here is a quick comparison of some commonly used Markdown with the rendered result:

Top level header: <H1>

Block quote

Second paragraph in block quote

First Paragraph of response. Italics, bold, and bold italics.

Second Paragraph after blank line. Here is some HTML code mixed in with the Markdown, and here is the same <U>HTML code</U> enclosed by backticks.

Secondary Header: <H2>

  • Unordered list item
  • Second unordered list item
  • New unordered list
    • Nested list item

Third Level header <H3>

  1. An ordered list item.
  2. A second ordered list item with the same number.
  3. A third ordered list item.
Here is some preformatted text.
  This line begins with some indentation.
    This begins with even more indentation.
And this line has no indentation.

Alt text for a graphic image

A definition list
A list of terms, each with one or more definitions following it.
An HTML construct using the tags <DL>, <DT> and <DD>.
A term
Its definition after a colon.
A second definition.
A third definition.
Another term following a blank line
The definition of that term.