Ratings & Comments

Actually every move should be marked as illegal for a player that has no royal in a game where royals are defined. It is just that the absence of royalty is only tested when a piece with special (royalty, baring, anti-trading) properties is captured, as the AI assumes royalty still exists before the move, or the search branch would already have been terminated earlier. So it only tests it when it could have changed.

I guess the current AI would choke on tsume positions without King.

[Edit] For the purpose of highlighting the legality test now assumes a royaltyCount of 1 in the current position when in reality royaltyCount <= 0. In terms of scoring this fakes a single royal for the side that has none.

For the specification of a number of squares (e.g. the starting squares of the pawns) I support a shorthand I.D. where you only have to specify the lower left and upper right corner of a rectangular board area, separated by a dash. That doesn't help much in Smess, but for Xiangqi a0-i4 would give you the entire area below the River, and d0-f2 the white Palace.

Still, having to fully write down the list of coordinates for nearly all board squares is probably more cumbersome than using a FEN-like notation for the entire board. That would require the property of the square to be encoded by a single character, though. But that character could encode an index in a table of the properties. Like

a: R; b: BvR; c: BsR; d: fRrRfrB; ...

acabcbaca/bdbcacbdb/...

(Just a move assignment I made up on the spot.) For irregular patterns like Smess there is no way to avoid specifying all squares explicitly, but regular cases one often encounters are homogeneous ranks, alternating squares on a rank, identical ranks or pairs of ranks. This is acually a problem that is very similar to coloring of the board, so the solution you use in the Diagram Designer for that should be applicable here.

For the specification of a number of squares (e.g. the starting squares of the pawns) I support a shorthand I.D. where you only have to specify the lower left and upper right corner of a rectangular board area, separated by a dash. That doesn't help much in Smess, but for Xiangqi a0-i4 would give you the entire area below the River, and d0-f2 the white Palace.

Are you saying this is something your code already supports or that it is an idea you would be behind?

Still, having to fully write down the list of coordinates for nearly all board squares is probably more cumbersome than using a FEN-like notation for the entire board.

It would be more compact, but it would take the same mental effort^* as it would to write out each coordinate in a select-case structure like I proposed, and the select-case structure would have the advantage of being easier for a person to read and understand, as it would allow someone to go directly from the coordinate to the Betza code without taking the time to mentally unpack the FEN-like string.

* or more actually as you would be taking the extra step of compressing your data.

The current code supports the format for indicating starting squares of the pieces, which it currently the only place where it interprets square coordinates. But if it was needed to process case labels referring to board squares, it could use the same shortcut.

I am not yet convinced enumerating the squares as case labels is the most convenient solution for the reader, though. To know how a piece moves he would have to search it amongst the case labels. Even if we adopt the convention to order these alphabetically, if there are many different square properties, he still would have to examine all the lines. But if the board is represented as a FEN he would know exactly where to find the square, as a FEN is basically an image.

Another problem with the case labels is that it is hard to find a shortcut for checkered patterns, which can be expected to be a common case. For Elk Chess it would be annoying if you have to write 32 case labels of the dark squares for the N move, and the other 32 case labels for the R move. The shorthand rules already used by the I.D. for the morph  FENs make it easy to represent such patterns in a compact way.

But I guess that in the context of the I.D. we should above all ask ourselves the question "where will it be displayed, and what is the intended audience. The Diagram definition would normally be invisible to viewers of the page. And if this info would be displayed at all, it would not have to be displayed in the same format as in the Diagram definition.

I think the most convenient way to present this info to the reader is put the list of squares in parentheses behind the piece name in the piece table. Each move would have da different entry in this table. In the simplest implementation it would be the responsibility to write this list himself as part of the name. But it could also be added automatically, based on the square-property FEN. In principle it would be a comma-separated list of squares, but some regular patterns could be recognized (rectangles, which includes files and ranks, or chrckering), an special verbal descriptions could be shown for those (such as "on dark squares").

Of course the reverse could also be possible: the person creating the Diagram could write the list of squares, or the special phrases behind the piece names, and the Diagram script could recognize those, and apply the indicated moves accordingly.

Another problem with the case labels is that it is hard to find a shortcut for checkered patterns, which can be expected to be a common case. For Elk Chess it would be annoying if you have to write 32 case labels of the dark squares for the N move, and the other 32 case labels for the R move.

Using wild cards, it could look like this:

[aceg][1357]: [bdfh][2468]: R; *: N;

I looked into whether JavaScript has wildcard support, and I did not find any native function that supports it. But I did find an article called Wildcard Pattern Matching in JavaScript with a short function that does wildcard pattern matching by converting a wildcard pattern into a regular expression and then doing a regular expression match. Here is the function:

function wildcardMatch(text, pattern) {
    const regexPattern =
        new RegExp('^' + pattern.replace(/\?/g, '.').replace(/\*/g, '.*') + '$');
    return regexPattern.test(text);
}

To test it, I wrote a pair of loops to generate all the coordinates on a Chess board, and I had it display each coordinate only if it matched the pattern. Then I tested it with the patterns "a1", "*", "[abcd]?", [e-h]?", and "[aceg][1357]", and I got correct results each time. Since it's actually doing a regular expression match with some slight changes to the pattern, I also tested "([aceg][1357]|[bdfh][2468])" and got it to display all the black spaces.

But I guess that in the context of the I.D. we should above all ask ourselves the question "where will it be displayed, and what is the intended audience. The Diagram definition would normally be invisible to viewers of the page. And if this info would be displayed at all, it would not have to be displayed in the same format as in the Diagram definition.

There are two types of people who would be interested in looking at it. The first is someone with a knowledge of Betza code who finds it helpful for learning the rules of a game. The second is a programmer who wants to understand how it was programmed in order to be able to do something similar.

But if the board is represented as a FEN he would know exactly where to find the square, as a FEN is basically an image.

For each type of person who would be interested in looking at the code, I think that using a FEN-like representation of the board will add an extra layer that requires some interpretation for a full understanding. For most games that give the same piece different powers on different spaces, short wildcard patterns (or just regular expressions) could be used to distinguish light and dark squares, one side of the board from the other, or isolated sections of the board from the rest of the board. Only a game like Smess or Storm the Ivory Tower would need the whole board spelled out, and the code could be made more compact by grouping together squares on which the same piece has the same powers of movement. This could be done with a switch-case structure as I first suggested, or it could be done as a single regular expression that includes all relevant spaces. A switch-case structure, though, would still be helpful for providing a default value without the need to devise a wildcard pattern or regular expression to match the remaining spaces. It could just be applied to any space that had not matched any previous pattern in the sequence.

Note that by select-case in earlier comments, I meant switch-case, though it does look like BASIC does call it select-case instead, and I do also have background in BASIC.

Yes, of course. A chancellorrider cannot pass the barrier on the same file. Applies to the cardinalrider and amazonrider in the same way with regard to diagonal movement.
 

Why put the same image there three times?

Which image three times?

OK.
The first is the setup, which can't be superfluous.
The second shows 'Play It!'; what's superfluous about that?
The third shows Game Courier as a picture. My way of pointing this out. Can be turned into a gray mouse by inserting a simple sentence, e.g. 'play it on Game Courier'.
OK.

Well, if the first diagram shows the same setup as the second, but without the 'Play it' option, I would say the first diagram is superfluous. Which information exactly would not be conveyed to the reader if it was omitted?

Well, you have to say what is part of a complete presentation.

Can the setup be omitted if the 'Play it' item follows under 'Notes'? Mind you, under 'Notes', i.e. at the end of the presentation. That doesn't make sense, does it?

The setup is the opening for a reason. Everything that follows can be understood as a supplement that serves as further explanation.

Incidentally, we shouldn't think the reader is so stupid that he can't sort the information provided correctly.

A German saying goes: 'Doppelt hält besser' or twice is better than twice - it should be no different in English.

There might be contexts where this proverb applies, but articles explaing game rules are not amongst those. In principle every added sentence or image make those worse, and have to justify their presence by providing essential new information.

The setup section is intended for presenting an image of the initial position. So the 'Play it' Diagram can go there. As it does in the large majority of articles we have here. Then there is no need for having a second, redundant image.

Like there is no need to repeat a number of times that there is no morphing on the f-file...

Okay, I've rearranged it.