Comments by HGMuller

GitHub is a website where programmers publish the  source code of the programs they develop. It is not a site where you can play anything. But of course some of the programs published there are games. Those could be downloaded and compiled to run on people's own computers, and often the programmers already offer a compiled executable for download. To offer something there that others could use, you would have to write a program that plays it.

Jocly is one such program available on GitHub. It is a gaming platform for use on websites through a web browser, or running on your own PC through JoclyBoard. It is mainly a user interface, but is designed in such a way that it can easily extended with new games, with already a lot of supports for the tasks most chess variants have in common. So you would only have to program the part that is unique to your variant, in JavaScript.

We have a version of Jocly installed on CVP, and there is also one on my website, where people could browse to, and play the games they support.

Western sources are usually wrong. Of course on can question if there actually is something  like THE original historic rules, as different manuscripts not always agree. So rules might have changed with time and place, like they did for medieval Chess. But since a Teaching King is described as Queen plus Lion Dog, and its move diagram is drawn as that of the Queen with three perpendicular line elements on each move close to the origin, it is pretty certain the LD was more than Q3.

The FF should probably be changed here to conform to this.

In principle, yes. If these are not too different in style.

And I do hope, one day, to get some of my simpler variants on there.

Your variants are typically more 'regular' than Gerd's, in the sense that they could draw on existing chess-variants infrastructure of Jocly. For example, there is support for rectangular and hexagonal boards of any size and shape, but not for boards with switches, which would have to be programmed from scratch. There is support for normal, and even single locust captures, but not for 'recruiting' moves that make captured pieces appear elsewhere, or for neutral pieces.

For your variants the programming would be limited to indicating the piece moves.

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.

I think it should be possible to use multi-character IDs in morph and captureMatrix by using comma separation in the rows these occur. This is untested, though. And the Play-Test Applet won't generate this format, but just concatenates the IDs, even if these are multi-character. So you would have to insert the commas by hand.

afs(afzafq)W(afqafz)W

No, that is not it; there is no step on the main orthogonals. The repeating unit involves three steps, not two (afzafqaz), and the repeat of it would thus only visit one of ever three squares in the path. So that you would need three moves to cover the entire path. And the plain W would have to be mentioned separately:

Wafs(afzafqaz)Wafsafz(afqazafz)Wafsafzafq(azafzafq)W

I suppose a bracket notation for this could be a lot simpler

[W?fF(?fzW?fqF?fzF)]

The option to terminate the move at the question marks allows collapsing the three different 'phases' into one.

In Dutch we also have the word 'koerier', which I think is the same as the German Kurier. It describes the carrier of an important message, usually on a mission to deliver it fast. Michael Strogoff (of the Jules Verne story) is known in Dutch as 'de koerier van de Tsaar'. Doesn't necessarily have to be on foot; in WWII times military 'koeriers' employed motor cycles. In modern times we speak of 'drugskoeriers', who are people smuggling illegal drugs across the border by carrying those on (or usually: in) their body.

/play/pbm/sets/*.php

W and F instead of R and B. And afaf(afafaf)W can be written as nHH, a non-jumping Threerider. [W?nHH] for the other move does not work yet. (It ignores the n.) Eventually it should be possible to write this as [W(?nD?W)].

The Zerdinal has mating potential, and it might be useful to give a link to a pre-programmed checkmating applet for it. (E.g. in the Notes section.)

/membergraphics/MSinteractive-diagrams/EGT.html?betza=ZB&name=zerdinal&img=zebrabishop

That also applies to the Half Duck, which does not have its own Piececlopaedia page where such a link can be found. There is no checkmating applet that can do crooked sliders like the Snake, but the non-lame sub-set FN easily forces checkmate, even on 16x16 boards. Forcing checkmate for a piece that has FR3 moves, such as the Tetrarch, is trivial (even on a quarter infinite board), and probably does not need an applet: the piece alone can drive the bare King to a corner.

I would avoid the use of yy in the move description of the Aviaanca, as this is really an undocumented feature of XBetza, to make recognition of some bent riders in the bracket notation possible as long as the latter is still implemented through pre-processing. It will be abandoned when the bracket notation will be parsed directly. Better use [W?AA].

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

Sorry, I was out of town for a few days, and had no time to figure out the answer on this one.

The presets you compare with were not automated through the PTA, so there is no reason why these should behave the same.

Are you sure the game ends when the King moves out of check? Normally an illegal move should not terminate the game; it should just be refused (in this case with the message you quote), and then through using the browser 'back' button you should be able to retry another move. This is also what happens if you insist moving a piece to a non-highlighted destination.

If this is the case the only thing that isn't working exactly as it should is the highlighting: the King jumps get highlighted even if they are forbidden because of check. But there is no way to exploit this; in the end legality is enforced by refusing the move.

The way the PTA-generated GAME code enforces 'not out of check' rules is by having the potentially forbidden moves generate e.p. rights on the square of origin. Using such a move then would allow the opponent to capture the moved piece (i.e. the King) en passant, making the move illegal.

Unfortunately the 'accelerated check test' used for determining the legality of the moves to highlight (in order to prevent this from becoming excruciatingly slow for large games) doesn't detect this: it generates all opponent moves from the current position to mark squares that are under attack on the board. And then only rejects King moves that go to such an attacked square. And in this case the problem is not that the destination is attacked, but that the origin is attacked.

I suppose I could solve this in the accelerated check test by suppressing the virginity of a King that is in check during the generation of the highlights.

[Edit] I now changed the move generator to suppress initial moves of a piece that should not move out of check, when it is in check during the accelerated check test. Please test if this solves the problem.

If HGM has the time and the possibility to add the parametrisation of the hand space in the drop model, of course I'll use it, but I don't know if it's that easy to do.

In the current drop-model.js you can request extra ranks for hand pieces above and below the board, in case there are more piece types that can go in hand than there are board ranks. Does that satisfy your needs?

The coloring is very splotchy, though more so on curved surfaces than on flat surfaces, as can be seen in this color image of a color scan of my Likebook Mars:

Conventional solution for this problem is to apply 'dither' to the image: add white noise to the brightness of the individual pixels, randomly chosen from a homogeneous distribution that has the width of one brightness quantum.

It should be explained in the commit message of the drop model. Unfortunately that is not easy to access now that GitWeb is disabled on my website (I haven't had time to fix that yet). But if you have pulled the pullreq branch you should be able to see it on your local machine.

Don't count on automatic conversion of the Interactive Diagram to GAME code, though. There are some aspects of this variant that are not supported yet by the betza.txt include file that powers such GAME code. In particular the captureMatrix, which is used to make the flying pieces block each other.