@Zied & Raphael:

If you read back through the comments on this topic, you will see that we have had an intense discussion in 2018 on what the future of the 'Recognized' label should be. At that time we corrected some obvious omissions of variants that are played by millions even today (Jangi, Makruk), or in their time dominated the chess scene (Shatranj, Chu Shogi). At that time a sort of concensus arose that it could be discontinued, as the categories for which novel variants could qualify would just duplicate the 'favorites' list.

We have to blame Ralph Betza for hijacking the name Aanca, and assign it to the bent slider that first makes a W step and then continues outward like B. Unfortunately this new meaning of Griffon / Aanca became so well settled that it will be difficult to eradicate. There was a discussion about this in the comments on Team-Mate Chess (which also features a Betza Aanca).

Note that such a confusion is not unique: the Spanish word for a Bishop is Alfil, but in English Alfil is used in the original sense of the Shatranj piece. It will be even harder to make the Spanish Chess community see the error of their ways, and make them drop their erroneous use of the word Alfil.

My conclusion was that the simplest solution is to just accept that chess men have different names in different languages, which are not always translation of each other (e.g. Bishop - Runner - Elephant - Fool - Counselor), and that this can also be the case for unorthodox pieces. That way Griffon would be the English name for the piece that the Spanish call Aanca, while Aanca would be abused in English to dscribe the Betza piece, similar to how the Spanish abuse the word Alfil to describe a Bishop.

As off now, I changed the name of the W-then-B piece from the (historically incorrect) Betzan 'Aanca' to 'Acromantula'. In the Harry Potter series Acromantula refers to a species of giant, poisonous, man-eating spiders of high intelligence. As the piece can move along eight rays, so that its move pattern does resemble a spider seen from above, the name seems fitting.

Why not my suggestion of Monoceros, ...

Because it does not start with an 'A'.

Besides, 'Monoceros' is just Greek for Unicorn. If we use those two names for different pieces, how should the Greeks distinguish them? As there seemed to be opposition against calling the Grant Acedrex N-then-B by its original name Unicorn, because we already associate that name with another piece, I think we should make Monoceros the English name of the N-then-B. This also sounds more like the originally intended Rhinoceros (which unfortunately was also already taken).

And note that I already have a piece called Unicorn in Team-Mate Chess. I tend to use this name for an augmented (or a royal) Knight (in this case WN), because XBoard has a piece image for it, and it is one of the most knight-like pictograms there that is not actually a Knight. I don't want two different pieces in Team-Mate Chess to have names that are just each other's translation in some other language. (Even though the move patterns are rather similar, the Acromantula just being a sliding version of the leaping Unicorn.)

Oh, I see that this article article was actually written by me. I had completely forgotten about that. I now adapted it as you asked. I also added a note about 'Lioness'.

Jean-Louis will probably be able to say more on this, but new translations of the Alfonso Codex have created a sort of consensus that Murphy was indeed completely wrong, and that the 'Unicorno' piece is an N-then-B. It depends a little bit on the interpretation of 'forward', whether this means "in the direction of the promotion rank" or "outward". The manuscript also contains descriptions of the real-life animals on which the pieces are modelled. And from this it is obvious that it is intended to depict a Rhino, even though the illustrator of the manuscript obviously had never seen one in his life, and hasd no clue as to how it looks. The move is supposed to reflect the behavior of the real-life animal, "starting with a leap, and then charging forward in a straight line". That doesn't suggest a reversal of direction after the leap; no real-life Rhino would be agile enough to do that. So it is pretty certain that 'forward' meant 'outward'.

@Greg: Interesting list. One thing I noticed is that it says

Anqa (Arabian) - Legendary Huge Satanic Eagle with Human Face. sometimes can resurrect herself like phoenix did.

So accoding to this Aanca is not Spanish for the mythical Elephant-eating bird, which was called 'Roc' in Arabic, but an Arabian name itself for an entirely different beast. And this latter beast is actually very close to what in Greek / Roman mythology is called a Harpy. This suggest the correct the correct translation for Aanca is Harpy.

[Edit] I looked up the translation of the Alfonso Codex, and from the description of the Aanca is is obvious that this is the Elephant-eating bird. So so much for the accuracy of the list... This is the quote of the translation of the Unicorno description:

The rhinoceros is a very large and very strong beast with two horns – one on its forehead and
one on its nose. Its nose horn is so strong that it can spear an elephant in the gut and lift it from
the ground. The forehead horn is very sharp and cuts powerfully. This rhinoceros is as large as
an elephant and ash coloured. It has ears like a pig and when it is angry its eyes turn as red as
ruby. When it begins to run it runs far after it gives a jump like a horse and so does its piece. The
rhino’s move is composed of two different steps. First, like leaps like a knight. It may remain on
that square if it wishes or may also continue to any square on the diagonal(s) of that square,
maintaining its movement in a forward direction from that square.

I remember having looked at the original text, and although my 13th-century Spanish is just as bad as my modern Spanish, it is still enough like Latin / French / English that is is easy to verify this translation is entirely correct. I had no doubt about that at all.

What I dislike of 'Arachnid' is that it is not the name of a species, but an entire class of species, which not only contains spiders, but also scorpions and other orders of animals. Like calling a piece 'Insect', 'Mammal' or 'Bird'. Or even perhaps 'Vertebrate'.

BTW, the thesis that names from mythology would be better known breaks down completely on this list; for almost any creature in it you can be very sure no one ever heard about it. So the question arises: why bother picking an existing historic mythological creature if  no one ever heard of it anyway? The more I think about it, the more I start to like 'Antigryph' (or 'Antigryphon', if you want): a piece that moves opposite to the Gryphon.

Nice application of the Interactive Diagram. I didn't try to digest this game yet, but I have a general question about your presentation. Your article contains this list of piece descriptions in English. Do you think it makes sense to have the Interactive Diagram, or perhaps the Design Wizard for the diagram, produce such a list automatically? For most pieces it will not be that difficult to 'rephrase' a Betza move description in English. And your list for these games could serve as guidance for what we want a description to say. (E.g. for Gold = WfF, should we make it say "moves one step orthogonally, or one step diagonally forward", or "moves one step in all directions, except diagonally backwards".)

If the Design Wizard would generate such a list, the author could just copy-paste that in his article, and perhaps add some further explanations for the more complex pieces, or change any wording he did not like. The first column should really be images, I think. Just having the piece name there, and then starting the description also with the piece name, is a bit double. It would already be helpful if a table was generated with all piece images in the first column, and the name in the second, so that the author could write the move decription after the text. But for simple pieces also generating a reasonable text should not be too difficult.

What do you think?

I think it is very unfortunate that we do not have a universal naming scheme of the piece images in the various sets. Also, having different 'sets' of Alfaerie seems a bad idea. Alfaerie is one theme, and ideally someone wanting to use that theme should have all images available without worrying which set it is in.

Alfaerie is by far the most elaborate set we have. It could act as a reference implementation for image naming, and all less elaborate sets could use the same name space. And just leave names for symbols they do not have undefined, or use them as alias for a natural replacement.

Also note that the SVG renderer can make arbitrary cut-and-paste compounds of pairs of pieces (such as Rook + Bishop for a Chancellor, but also Knigh + Camel if someone desires one), or produce rotated versions of any piece.

My best guess is that the given piece values totally suck. The hoppers seem hugely over-estimated. Even in the opening phase of Xiangqi a Cannon is only marginally better than a Horse, while the Horse is only worth half a Knight in a FIDE context. The Cardinal seems hugely undrestimated; on 8x8 it is only about a quarter pawn weaker than a Marshall, and I would not be surprised if it is actually stronger than one in this game, as it is very adept in demolishing Pawn chains, and there are a lot of Pawns here.

I did do some piece-value measurements on a 12x12 board lately, but the results were a bit anomalous. It seemed the difference between a Rook on one hand, and a Bishop or Knight on the other could not be compensated with any reasonable number of pawns; the Rook always won, and giving the opponent one more extra Pawn did not change the average result. The problem seemed to be that too many Pawns remain on such a large board, and their path to promotion is long. And Pawns cannot self-defend against a Rook while a Bishop or Knight can never catch a passer, and Bishops often not even a blocked Pawn. So what happens is that the Rook just eats away all opponent Pawns, the opponent minor being tied up by preventing advance of a passer. And then it starts to push his own passers protected by the Rook, so that in the end the only way to prevent promotion is sac the minor. After which the Rook player promotes his other passers, or just checkmates with the Rook.

You are correct that I misunderstood things. But I still think that the problem that different graphics themes use different names for the same pieces contributes to the problem.

I suppose that with 'too limited' you mean that it would not be possible for each player to select his own preferred board theme. But if all corresponding pieces always had the same name for their image in any theme, it should be quite easy to provide that feature too. Users would just specify the theme they want to use. If the Cazaux theme disn't have a Camel image (so that you would get a blank image, or a question mark for the Camel when you selected that theme in a variant that featured a Camel), then it would obviously not be suitable for that variant, and users would discover that quickly enough. Or you would use a lying Knight as Camel in any theme that doesn't have a Camel, but does have a Knight.

It seems a bad idea to pick images just based on a single letter. For some variants there would not even be enough letters! What you describe sounds as a rather clumsy work-around for the problem that more unorthodox pieces exist than that there are letters. The logical way to assign piece IDs is to derive them from the piece name, and not the other way around. If a default way (such as the first letter) doesn't work because of collissions, the programmer could provide his own.

The wrong name is the least of the problems of this article. The contents is completely off too, as it is based on the Murray description. This was alredy commented on by me before.

There still is one thing in the rules that is not clear to me, in connection with the King jump: can the King jump over an enemy piece that is protected? In other words, are pieces considered to attack friendly pieces in their path?

The tiles button is not an automatic asset of the diagram, but just added JavaScript embedded in the HTML page, to run the diagram script again with other settings. I can easily hide it, but I would prefer to create the missing images. Problem here is that many of those will have to be 2-kanji tiles. E.g. Flying Dragon has the problem that both its kanji are in use by more common pieces (Flying Chariot = Rook and Dragon King). I am not sure it is a good idea to mix 1-kanji and 2-kanji symbols, so perhaps I have to redo them all, and make a complete 2-kanji set for (Maka) Dait Dai Shogi.

As to text descriptions, it appear that we are of different opinion on that subject. I would say these should be avoided at all cost, or you would get horrible articles like those in Wikipedia. The text unambiguously describes how to read the range in the 8 directions from the mnemonic piece symbols, and even people with JavaScript disabled get to see a board image with these mnemonic symbols. If there are people that do not know how to interpret the symbols, they read the text, and they would know. If they cannot understand that text, they would certainly not be able to understand a text that describes an individual piece. There is not a shred of hope that someone not capable of reading the mnemonic symbols would be able to play this game.

I don't think that is true. Whether a move that would be a pseudo-legal capture if the target square was occupied by a piece of opposite color is an attack or a protection depends on the color of the occupant of that target square: it would be attack on an enemy, and protection on a friend, irrespective of who has the move.

The interpretation that 'attacks' means "must have a legal capture to that square if it was his turn" is a perfectly reasonable one, that cannot be excluded in absence of an explicit statement defining it differently. In the Xiangqi chasing rule it even means "must have a capture to that square that would be legal if his King was not in check".

Indeed it was not obvious that the names can be clicked, and Fergus has already addressed that point in the text he added. The Interactive Diagram has a feature where it automatically creates a list of piece names (not to be confused with the piece table that normally is hidden directly below it) and the squares they are on somewhere in the article text (a 'satellite', for which you just have to provide an empty HTML list somewhere in your text with a certain 'id'), and such lists will then always be headed by the notice (highlighted with light-blue background) that you can click on the names. (E.g. see here.) But I did not use that here, as for games like this the list would become very long, and could not be kept in view together with the diagram. Which makes the clicking feature a bit useless, or at least very cumbersome. So I hand-formatted the list to surround the diagram. But I forgot to put the notice with it.

Auto-generating a table of text descriptions (as another optional satellite) might be possible in the future. But for games with as many pieces as this, I think it is really detrimental. It just swamps the reader with (mostly redundant) low-density information, making it hard to find the pieces about which something interesting can be said. Of course the table could be hidden initially.

But in earlier discussions the issue came up that people might have disabled JavaScript in their browser, and that in this case we still want to show them the essential information. Hidden tables are no good when there is no way to open those, and tables that are generated on the fly would not be there at all. The latter is a second reason not to use the auto-generated list of pieces in an article; I uploaded a screenshot of the diagramm as it is initially generated as a static PNG image between <noscript> tags, to insure that in any case people would see the mnemonics, in addition to the surrounding list of piece names.

Well, perhaps I am exceptionally stupid then, because I did not understand it. Criticism is good; it can lead to improvement of the quality of the website. We should do it as much as possible. Authors should not be blind to imperfections in their work, and the normal response would be to repair the defects, rather than complaining about someone noticing them.

What make you think that we would only scrutinize your articles? The article attracted attention because it was newly posted. Not because it was you that posted it. As you can see my freshly posted article about Tengu Dai Shogi gets a lot of criticism.

Peer review works! It is a good way to guarantee quality.

How pieces interact with Pawns has a profound influence on their value. Because there are so many Pawns around. Whether a passer is unstoppable in a Pawn ending is determined by the famous "rule of squares". For a Ferz the area is nearly as large as for the King. The color binding doesn't hurt much, as it is not that important on what color you stop the Pawn, as long as you do it before it reaches the promotion square. For a Wazir the area where it can stop a passer is much smaller. I would indeed expect the Wizard to be better than the Wazir-Knight on a large board, due to its increased ability for catching up with Pawns. On 8x8 it might suffer from the Camel move falling off board too often.

I did some more work on the CwDA version of KingSlayer, and finally put the source code on line. The latest version now also supports the Daring Dragons army. This was not a trivial addition; this army needed several unusual features that were not implemented yet. For one, the Dragoons (KimN) need a divergent virgin move, and neither divergence nor virgin moves were implemented (other than in the hard-coded Pawn). The Wyvern has a ski-sliding move, which thoroughly affects the way we have to test for check, and what evasions to generate. It introduces a new mode of checking (which I call 'tandem check'), which is a double check where both checks come from the same direction. These can not be cured by capture of the checker, but unlike normal double check, it can be cured by interposition.

The Dragonfly is a tricky piece, with binding to odd or even files. It requires special evaluation to handle it well in the end-game. One of the unusual properties is that it is a 'semi-major': it can force checkmate on a bare King, but the KFK end-game also has fortress draws. Which of the two it is, is about an even call, like a promotion race in KPK: If the bare King can reach the b-file before the Dragonfly gets there, he can take safe shelter on the a-file, and it is draw. Otherwise it is a win. From the material composition alone, you cannot make a good guess. So I put in a routine that makes a reasonable guess based on the actual locations. (Not perfect yet, as it doesn't take account of the bare King hindering the Dragonfly in its attempt to reach the b-file, or vice versa, but that only happens in a minority of the positions.)

When the weak side still has Pawns (e.g. KFKP), I classify the end-game as drawish. (But not as bad as for KBKP, where you have no chance at all.) This assumes that the Pawn can act as a sufficient distraction for the strong side that the weak side has a very good chance of reaching safety with his King in the mean time. In fact a fair amount of positions in this end-game are won for the Pawn! If the Dragonfly cannot visit the file the Pawn is on, you only have the King to stop it, and the Pawn can easily be outside its reach as well. So Dragonfly endings, like Pawn endings, should really test for 'unstoppable passers' in their evaluation. (At the moment, KingSlayer doesn't do that for either, with as a consequence that is sometimes trades the last (non-Dragonfly) piece in a near-equal position, and on the next move (where it can search much deeper) sees the score dropping to -8.xx because the opponent's promotion can no longer be prevented.

The version I uploaded has the announcement of equal-army sub-variants commented out. With all combinations of the 5 supported armies, the list of variants in the CECP variants feature had become so long that it crashed XBoard!

I also started implementing limited configurability: it supports a variant 'custom', for which the user can specify (in a file gamedef.ini) the armies as an arbitrary selection of all the supported CwDA pieces. In addition there are two user-configurable pieces that can be selected too. These pieces can be built as an arbitrary combination of the move sets used to construct the standard CwDA pieces, plus one user-specified set of leaper moves. I am still thinking about a way to also allow specification of divergent or lame moves on these pieces. It might also be useful to allow redefinition of the set of leaps that is only used for the Charging Knight, in cases where the latter doesn't participate. And perhaps to redefine one or two slider moves, e.g. by making the range of R4 configurable, or perhaps replaceable by B3 or B4, or fB.

[Edit] I now uploaded a Windows binary of the latest version to http://hgm.nubati.net/CwDA.zip .

I did not correct anything; this is not the Wikipedia, and people cannot edit each other's submissions. I pointed out that the rule description in your article was ambiguous, and why. At that point you could have rephrased that rule to make it unambiguous (like I now have done in the article about Metamachy that I authored, now that I finally understand the rule), and that would have been the end of it. Then you would have had the last word.

But for some reason that escapes me, you did choose not to do that, but instead argue about procedure: people have no right to criticize your submissions, want to have the last word, spoil your fun, make your variant look bad...

Of course that doesn't solve anything; the ambiguos rule description is still in your article. If you think that people will not like your variant when it has ambiguous rules, you have only yourself to blame for it by insisting the description must remain ambiguous. It is not my fault that it is ambiguous, and you should be grateful someone pointed it out, giving you at least an opportunity to fix it. But, as the saying goes, you can leed a horse to water, but you can't make it drink.

Well, that is no good. The glossary says.

attack - ... 2. n. under..... The state of lying within the capture zone of an enemy piece.

And capture zone says:

capture zone - n. For a given piece, those squares to which it can legally capture.

This is not at all the case here. For one you cannot capture to a square that is occupied by a friendly piece; such a presence would block the move. Secondly, a piece that would be pinned to its King would not have a legal capture even on an enemy, as it is illegal to expose your King to check. While the Metamachy rules still forbid the King to jump over such a square. All this was discussed at the hand of examples.

In fact the definitions in the glossary agree exactly with what I have been saying all along, and which I supposedly 'misunderstood' in the description of Zanzibar-XL. It seems that you are the one confused about what the terms mean or what the Metamachy rules are. So in fact you have ruined the article by replacing an exact and concise description of the rules by an indirect reference that gets it wrong.

I am shocked that you think you are at liberty to mutilate other people's contributions this way. Even if I would have written something that was plain wrong, the proper procedure would have been to point out my error and ask me to fix it. Please change it back to how I formulated it!

I would like to propose a definition of 'pass through check' as "passing through or jumping over a square where it would have been illegal to move your royal to, had that square been empty".

I see the current glossary doesn't contain a definition for 'check'. One could define it as a situation where a royal could be pseudo-legally captured if the player currently on move would pass his turn. But there could be a variant 'Recursive Chess' where it is not allowed to capture a royal when it exposes your own King. So it is perhaps better to define a legal move as a pseudo-legal move that does not expose your royal piece to capture, with the note that a move that terminates the game would never expose anything. Some game-termination rules are such that the actual game result is determined by an 'after-move': E.g. in Shatranj you can win by baring the King, unless the opponent can bare your King  in the next turn (in which case it is draw). Or, presumably, when he could capture your King (in which case you would lose by having played an illegal move). So on King baring, he gets an after-move. Variants like King of the Hill allow you to make the winning move to the center only if that move was legal, i.e. reaching the square is not enough, but there is an after-move that reverses the result when it can capture your King. And in Tai Shogi the royal is an Emperor, which can capture to any square on the board. Except that he cannot expose himself to recapture when capturing a royal. So there is an after-move in Tai Shogi even after capture of the royal, and the capture of the Emperor in this after-move has priority in deciding the game result over capture of the first royal! Recursive Chess could also be formulated that way.

So you are in check if the opponent, would it be his turn, has a winning pseudo-legal capture on your royal piece. In orthodox Chess any capture of the King would be instantly winning. But in Recursive Chess capturing the King with a pinned piece, (or in Tai Shogi capturing a protected Emperor with your Emperor) would be a losing capture, as in the after-turn your own King would be taken. So you would not be in check when you expose your King to capture by a pinned piece (or when your Emperor is protected). In al cases this can then be combined with the rule that moves that put your own royal in check are illegal.

If you want a scribble too mark the piece as a Silver, why not use an X with an extra line connecting the tips of the upper two legs? That resembles the move pattern.

I propose to change the definition of 'attack' by the following:

1. A piece is under attack when the opponent, would it be his turn, could *legally* capture it in the current position.
2. A square is under attack from a player when that player could *legally* capture an enemy piece standing on that square, given the remaining board occupation.
3. Colloquially, 'to attack' can also mean "play a move that creates one of the above situations".

Where *legally* would refer to the term 'legal', defined as:

Moves are legal when they would comply with all rules of the game. Moves are called pseudo-legal when they they comply with all rules except those that forbid to leave certain pieces (usually called *royals*) exposed to capture after a move.

Where *royals* would refer to an entry for 'royal':

A piece type is called 'royal' when capture or elimination of it terminates the game. With only a single royal per player, capture implies elimination. In some CVs a player can have multiple royals. We can then distinguish absolute royalty (first capture of a royal terminates the game) from extinction royalty (elimination of all royals of one player forces game termination).

CVs often have the rule that it is not *legal* to expose yourself to a game-terminating move of the kind described above that would result in your loss. (See *check*, *mate*.) In this case the mentioned captures cannot be part of any real game, and are only used as hypothetical continuations after moves that are not legal, to establish their illegality.

And for 'check':

A player on move is said to be 'in check' when his opponent, if he were on move, would be able to instantly decide the game in his advantage by capturing a *royal* piece.

(The condition that the capture should be a win is added to exclude cases like Tai Shogi, where capture of a royal by an Emperor would be a loss if recapture is possible. The word instantly was added to exclude situations where the capture of one of multiple royals is merely the first move of a forced winning line. Perhaps the term 'instantly decide' should be replaced by 'terminate', which could then get its own definition in the glossary.)

For 'mate':

A position where the player on move has no *legal* move is called a 'mate'. We distinguish checkmate (when mentioned player is also in *check*) and stalemate (otherwise), and the rules of the CV often assign a different result to those.

Possible entry for 'terminate':

A move is said to terminate a game if it fixes the game result without the players having to play any more moves. This does not exclude that the move is followed by a number of automatic hypothetical moves ('*after-moves*') to determine that the termination condition is indeed fulfilled, and what the game result should be. (E.g. *checkmating* terminates an orthodox Chess game, but two more hypothetical half-moves would have to follow to establish whether the royal can indeed not escape capture.)

After-move:

An after-move is a move in a hypothetical continuation of a *terminated* game for the purpose of determining whether the termination condition was fulfilled, was reached through a move that was *legal*, or what the game result is. E.g. when *baring* the opponent King is a winning game-terminating condition, an after-move can be needed to establish whether the capture that achieved it did not put your own King in *check*. If the result should be adjusted to draw when the bared opponent can counter-bare you through a legal move, two after-moves are needed. In this respect baring differs from capture of a *royal*, which typically does not allow an after-move, and thus never exposes your own royal to anything, so that any pseudo-legal move is also legal. The number of after-moves that should be taken into consideration, and their effect on the game result, is an essential part of definition of the winning condition.

Some remarks:

'Castle' in Xiangqi is really unusual; in almost every description in English I have seen, the 3x3 area is called 'Palace'.

Shogi does not have a castling move, but almost every text on Shogi strategy will tell you that the first thing you have to do in the game is 'castling', and then describe a large number of castle formations, usually with the King in or near a corner. I am not sure if we should refer to this different meaning of 'castling' in Shogi. Perhaps we could add a sentence that a 'castle' is a defensive constellation of pieces around the King near a corner (e.g. after you mentioned that the increased piece power made a centralized King unsafe). And that in Chess moving your King there (either through a special leap or the slow way) would trap the Rook, so that a single move has been provided to get the King in the corner without trapping the Rook in Chess. (In Shogi the corner piece of course is a Lance, which is trapped on the edge file by its own move, and it is usually integrated in the castle.

Fergus already remarked this: in some variants castling with pieces other than Rooks is possible. This should certainly be mentioned.

In the description of Fast Castling you don't mention whether it is allowed if any of the squares the King leaps over is under attack.

Perhaps we should mention something about notation for flexible/free castling (recommend one)?

Since you mention the terminology used in the ChessV option, you could perhaps also mention the XBetza notation for these types: O = castling, jO = close-rook castling, (usually prefixed with 'is' to stress that it is a sideways virgin-only move), the range indicator specifies the number of King steps, for flexible castling all possible castlings are mentioned separately. (XBetza does not support free or fast castling yet. I assume this would have to be done as a different atom, say S, because it is sort of a King-Rook swap. Where free castling would be nS (non-jumping), and fast castling S.)

ChessV's designation 'long' for Janus-Chess castling conflicts with the more common use of "long" for Q-side castling. I usually say 'asymmetric castling' when I refer to Janus Chess, although writing this makes me realize that I might as well call it 'symmetric castling', as the end result is the same K-side and Q-side. Perhaps 'symmetrized castling' would describe it best. In XBetza notation I have to define castling to the left and to the right as separate moves in Janus Chess (irO3 and ilO4). And because the setup is mirror-symmetric, left and right are swapped for black, meaning that the white and black King have different moves. Very annoying! In the Interactive Diagram I added an option castleFlip for this that automatically swaps the meaning of l and r on black castling specifications, so that the Kings can still be considered the same piece type. (Perhaps the meaning of l and r should always be swapped for black pieces in games with mirror-symmetric setups???)

Yeah, the shear size of Tai Shogi so far deterred me from making a page for it. You could look at Maka Dai Dai Shogi, though: this uses the same Emperor (except that you can only get it through promotion). This says:

The Emperor is a Universal Leaper: it can move to any square of the board. It cannot capture enemy pieces that are protected, though. That even holds for capturing the opponent's last royal. Protected here means that the Emperor could have been recaptured if the opponent would have been allowed to play on without royal.

In FIDE a King cannot capture a protected piece, but it can capture a protected King, so it is illegal to put it next to your opponent's King even when protected. For Emperors the opposite holds: you cannot capture a protected Emperor with it. (This difference is due to the after-move, and in the description of the Emperor I elaborate on the initial statement in terms of such an after-move.) Note that the historic rule descriptions of these games are very minimal. So it is not really known if the ban to expose your Emperor to capture is for every move, for every capture or just for capturing the opponent's last royal. Because no one in his right mind would ever even consider exposing his Emperor to capture if it would not be for the purpose of instantly winning the game or taking out the opponent Emperor, they don't waste words on it. Were the game to continue, being an Emperor behind means a certain loss. Also, Shogi is usually played under the rule "illegal move = loss", as opposed to FIDE, where "illegal move = take back". So it is completely pointless to make extra rules that make losing moves illegal in Shogi.

Anyway, this ignores the main point: the purpose of the glossary is to clarify matters by assigning unique meanings to concepts that universally apply. Not to promote confusion by making the definition of a term context dependent, possibly in an undesired way. If a term is ambiguous because its meaning depends on context, its use should be discouraged. If we describe such terms, it would be wise to accompany those with a warning like:

The meaning of this term is context-dependent, and to minimize confusion due to incorrect interpretation of the context, it should not be used in rule descriptions.

Historic rule descriptions are quite minimal, and in particular do not waste words on purely hypothetical matters. Turn passing is one such thing, as you never would want to do it in the first place. There also can never be a reason to not promote a Lion, so an unpromoted Lion in the zone that wants to pass a turn would be a double rarity. For Falcons and Eagles this is a different matter, as they might actually be more valuable than the BG and RG they promote to. (It seems these promotions were assigned mainly as leftovers.) Especially in a late end-game, when there is almost nothing on the board you could jump over. No way I would want to convert my Eagle to a Rook General when so few pieces are left that I could be in zugzwang...

Promotion rule is such that you can only promote on a noncapture when you enter the zone. It seems to me a turn-pass should count as a non-capture. So if you are already in the zone, definitely no promotion.

A more interesting question is whether they could promote when they are just outside the zone, and capture a piece in it through igui. Since promotion is at the end of a turn, I would say that after a turn pass you did not enter it. If you see it as a double move, the first move would enter it, but would not allow you to promote because it is not the end of your turn. The second move would not allow you to promote because it did not enter the zone and doesn't capture anything.

I have a problem uploading graphics. I have made some new images of shogi kanji tiles, and wanted to add those to the existing set in my Chu Shogi article (which currently only covers Chu Shogi). So that the diagrams for larger variants no longer have missing tiles when they use that image set.

Unfortunately the upload script is broken: it complains the directory /membergraphics/MSchu-shogi does not exist. It is probably right about that, because that is also not where the existing images are: these are in /membergraphics/MSchushogi...

... caching of the original images can cause you to see the wrong image ...

Indeed, I also have this problem after uploading an image to replace one that was accidentally uploaded under a wrong name. It keeps displaying the old image. As a consequence it now displays a Go Between for the black Golden Bird, and and White Elephants for the Western Barbarians, in the 1-kanji tile set for Dai Dai Shogi.

I've added the checkmating potential note to this page.

Nice! But perhaps you should also mention that the man loses this mating potential on boards of size 15x15 or larger. Also note that the symbol used for Man in the WinBoard/XBoard GUI is

@Fergus: Would it be easy for you to have the upload manager also accept archives (e.g. .zip or .tar.gz), and unpack those in the upload directory for the article? It is really very tedious now to upload a large set of piece images one by one.

Is 14x14 or 15x15 too large to generate the endgame table in an online setting?

I am not sure how far this can be pushed. It probably depends on the computers people use. But some people might want to try it on a phone... I suppose we would like it to work for almost everyone.

The problem is that the required amount of memory increases very aggressively with board size. With 3 pieces on an NxN board you have N^6 possible positions. So going from N=8 to N=16 requires 64 times as much memory. The time it takes would be proportional to size. For 3 pieces even 16x16 only requires 16MB, which by today's standards is small. So I suppose that can be done, and based on how long it takes now, it would then take some 10 sec to generate the table. I will have a look at it.

... I can't let archives unpack indiscriminately, because that would allow hackers to upload server-side scripts.

Indeed, that is a worry. Is the server configured to execute scripts anywhere, or just in some designated directories? It should still be made impossible to unpack anywhere outside the directory intended for the article. But I suppose that archiving commands to extract files can be called in a way that they ignore directory structure, and save everything in the current directory.

Savest would probaby be to extract everything to a temporary directory not accessible through the net, and then only copy files with some allowed extensions to the target directory, and delete what is left over.

Are you sure about those numbers? I cannot do the Omega Chess board, but my EGT generator for a plain 10x10 board says KBNK maximally takes 47 moves (average 39.4), and Knight + Wizard maximally 48 moves (average 40.1). I can imagine that having the Wizard squares could take 2 or 3 moves extra, but not nearly as much as what you mention. The hard part is usually to get the bare King in the desired corner. For Bishop + Knight it might not take any extra moves, as in the standard mating patterns the Bishop would automatically attack the Wizard square as well.

I agree that 50 moves does not leave much room for errors, and in general it can take longer to make progress in large games.

[Edit] Oh, I now also see your previous comment. And no, Kevin did not misunderstand me; for maximum DTM with a WD on 10x10 I get 52 moves, while 95.7% of the positions with the strong side to move are forced wins (see table below). On the Omega board this is of course no longer true; not even a Rook can force mate there. The WAD probably doesn't fare any better.

$ ./3men10x10 KwK
allocate 1010064 at 6d0040
        mated    mate
King captures 129224
mates      16         ( 0.01 sec)
in-1       40      64 ( 0.01 sec)
in-2      208     248 ( 0.01 sec)
in-3       88     916 ( 0.01 sec)
in-4      300     624 ( 0.01 sec)
in-5      224    1428 ( 0.02 sec)
in-6      468     768 ( 0.02 sec)
in-7      528    1696 ( 0.02 sec)
in-8      468    1728 ( 0.02 sec)
in-9      400    1836 ( 0.02 sec)
in-10     480    1080 ( 0.03 sec)
in-11     396    1328 ( 0.03 sec)
in-12     312    1416 ( 0.03 sec)
in-13     512    1192 ( 0.03 sec)
in-14     304    1656 ( 0.03 sec)
in-15      72     812 ( 0.04 sec)
in-16      56     304 ( 0.04 sec)
in-17      80     280 ( 0.04 sec)
in-18     168     392 ( 0.04 sec)
in-19     468     712 ( 0.04 sec)
in-20     768    1408 ( 0.04 sec)
in-21     768    2096 ( 0.04 sec)
in-22     708    2152 ( 0.05 sec)
in-23    1056    2080 ( 0.05 sec)
in-24     908    2812 ( 0.05 sec)
in-25    1640    2620 ( 0.05 sec)
in-26    1376    4128 ( 0.06 sec)
in-27    1516    3720 ( 0.06 sec)
in-28    3944    4524 ( 0.06 sec)
in-29    4536   10044 ( 0.06 sec)
in-30    6588   11060 ( 0.07 sec)
in-31    9456   15224 ( 0.07 sec)
in-32   15880   20516 ( 0.08 sec)
in-33   27248   32184 ( 0.09 sec)
in-34   33956   48452 ( 0.10 sec)
in-35   45448   56908 ( 0.12 sec)
in-36   60972   71044 ( 0.13 sec)
in-37   77556   89008 ( 0.15 sec)
in-38   88852  100212 ( 0.17 sec)
in-39   86540   90180 ( 0.19 sec)
in-40   81708   71664 ( 0.21 sec)
in-41   57772   46460 ( 0.22 sec)
in-42   40900   31352 ( 0.23 sec)
in-43   25296   20336 ( 0.24 sec)
in-44   19160   15656 ( 0.25 sec)
in-45   12944   11152 ( 0.25 sec)
in-46    8928    6976 ( 0.25 sec)
in-47    5456    4136 ( 0.26 sec)
in-48    2520    1968 ( 0.26 sec)
in-49     912     696 ( 0.26 sec)
in-50     224     200 ( 0.26 sec)
in-51      72      56 ( 0.26 sec)
in-52      32      16 ( 0.26 sec)
in-53       0       0 ( 0.27 sec)
won:     928744 ( 95.7%)
lost:    731228 ( 75.4%)
avg:       37.9 moves

Why does it say stalemate is not possible? It seems the diagram of which it is claimed the best Valkyrie move is capturing the Forest Ox (Vf1xf7) actually leads directly into stalemate, through that move. After it black has no legal moves, and after hypothetical null move white cannot capture both his Kings at once, so he is not in check either. (And besides, the last black piece could have been taken elsewhere, so that neither black King would have been under attack.)

Ah, I overlooked the addendum. So I guess what was really meant is "stalemate is a win". In fact stalemate is far more frequent here than in orthodox Chess. In the latter case the King has to be robbed of its legal moves by attacking all squares adjacent to it. Here you don't have to attack anything, as the King has no moves to begin with.

I guess you could also say that baring the King(s) is a win. But that is not the only way to get a stalemate. One or two Kings could block all moves of one, or even two Pawns.

Black to move is stalemated!

[Edit] This was very wrong; I failed to notice the Pawns also have backward moves. So I suppose the only stalemates are those where you have nothing but Kings.

The 'unload' modifier

I have been working on an extension of XBetza notation in WinBoard/XBoard: the 'u' modifier. This stands for 'unload', meaning a piece that was captured elsewhere is not removed from play, but reappears in a new location. This to allow pieces that displace others.

After some thinking it occurred to me that it would be best to have a move that has a 'u' modifier to unload the piece on the starting square of that move. This in contrast to other mode specifiers (such as 'm' or 'c'), which specify what the move can do on the destination square. This because the destination square is bound to be occupied by the piece that moves, while the starting square will naturally be emptied. Of course this could be cured by having unloads only on the destination square of a non-final leg of a multi-leg move, but that would just lead to complex representation of simple moves.

So ucR now means a Rook move that captures on the destination, but unloads that captured piece on its starting square. In other word, a move that can swap location with an enemy piece. Similarly, udR would describe a swap with a firendly piece, as in XBetza 'd' stands for "capture friend".

Of course it is possible to use the 'u' in a multi-leg move as well. E.g. afudQ would describe a Queen with a two-leg move. The first leg to an empty square ('m' is the default mode for non-final legs in XBetza), the second leg continuing (as Q) in the same direction ('f'), and doing the friendly swap (udQ). Normally a slider move continuing in the same direction would be pointless. (Well, not entirely; it guarantees the length of the move is at least 2.) But now that the intermediate square (start square of the second leg) is used for unloading, it suddenly becomes relevant where on the path it is. Like with locust captures, the user entering a move would first have to select the intermediate square (which WinBoard indicates by highlighting it in cyan, as with locust victims). After which the target square(s) get marked (in this case only one), and clicking on that would finish the move, where the piece in the destination is bumped to the intermediate square. This is part of the Valkyrie move in Odin's Rune Chess. The full Valkyrie would be QudQafudQ, a normal Queen, a Queen that swaps position with a friend, and a Queen that displaces a friend to a formerly empty square on the path it took.

I used XBoard, which I hacked to save all the PGN renderings of its pieces to separate files. XBoard works with external SVG piece images, and has a fall-back scheme where it first replaces a piece which it cannot find the image file for in the user-specified pieceImageDirectory by a file White/BlackTile.svg, before trying other options. So if you let it use a direcory that only contains a file with a blank Shogi tile, it will use it for all the pieces. XBoard works by internally rendering the SVG to raster images of the current square size, and uses those to draw on any board it wants to display. I just intercepted the produced raster images, and let it save those to PNG files.

And then it has an option -inscriptions, which can contain an arbitrary unicode string, where the individual or pairs of characters are printed over the pieces. So I just copy-pasted all the kanji from the Wikipedia pages to make such a string, set XBoard to the desired square size, et voila! Then I had to rename all the saved PNG files, so I could do the next batch. Still took me more than a day to get them all; I had to tweek the kanji-inscription procedure for some of the pieces to prevent the kanji from overlapping; especially the 'general' kanji was written higher than the others.

Well, I suppose that those discussions mainly were about what should be considered 'in check' or 'passing through check' in the presence of an Imitator. And that isn't really a subtlety of the Imitator, but of the checking rule employed by the CV. That is outside the scope of Betza notation, which only has the purpose of indicating pseudo-legal moves.

The main problem I see is whether the imitation is 'recursive', in the sense that it would be able to imitate a previous imitator. The same problem exists with move borrowing, btw. The way I currently implemented that in XBoard aims to be non-recursive. Because Odin't Rune Chess defined it that way, but also because recursive borrowing easily leads to infinite recursions, when two move borrowers can borrow from each other. You would have to keep track of which pieces you already borrowed from. Or better yet, which moves you already borrowed, so that you would never generate duplicat move. For XBetza duplicats are not a crime, though; you can for instance say KR or DR, where the first is sloppy, but a unique alternative for the second in unreasonably cumbersome.  For Imitation this problem doesn't exist, and I think the most common type would be recursive, imitating the last-moved non-imitator.

There also is the problem whether you imitate special properties of a piece (like promotion), or just the set of target squares. But this problem also exists with move borrowing or induction. E.g. in Knight Relay Chess you cannot promote a Pawn through an induced Knight move. (You cannot even move it to first rank, so this is really a confinement issue.) But promotion is again outside the scope of Betza notation, the latter just describes methods of locomotion. There are some CVs where the set of moves that allow you to promote is not equal to that where you can defer promotion. (In particular micro-Shogi, where you (mandatorily) only promote only on capture, but there also are variants where you can promote on a null move in the zone, while plain null moves are not allowed.) This would be most conveniently described by just giving a separate move description for promoting moves.

There is an article about 'Mimics' here on CVP, which I stumbled on when looking for Mimotaur. It also mentions a 'Strict Imitator', which imitates the actual move, rather than the piece type. I would say that is just another atom.

I try to remain pragmatic; Betza certainly was, with his z and q modifiers. If it is simple and useful, it is worth having, even if it is not perfect in the sense that it can do everything. The way XBoard uses XBetza move descriptions makes it already useful to describe approximate moves, so that it knows what is certainly not pseudo-legal. Having a recursive imitator in the toolkit would certainly be helpful.

The King has the simplest XBetza description of the unorthodox pieces: just xK to indicate it borrows moves from friends a K step away. The Pawn was straightforward, but gets a somewhat lengthy description, because both paths to the square two steps in front of it must be specified separately (because they bend in opposite ways).

The XBetza description of the Valkyrie uses the 'unload' operator for the moves that displace a friendly piece. There are two different kinds of such moves: a plain swap, which is specified as a simple move that unloads at the start when it captures at the end; the 'd' mode in udQ indicates friendly capture. (First-time use in a real variant!) Then there is a more complex move, that involves a third square. The diagram considers this a two-leg move with the unload square as intermediate. So you first have to click the square where the other piece is to end up, and then where the Valkyrie goes.

The Forest Ox is the worst of all. It combines a Knight move with a King-like rifle capture. XBetza cannot forge such different move types into a multi-leg move, so everything has to be reduced to a 'common denominator'. In this case everything is reduced to King steps, meaning that the initial Knight jump becomes two legs, where the intermediate square is made a don't-care w.r.t. the content of the square by allowing both moving and hopping. By using K as basic atom, each N square is reachable through two paths, but as neither is blockable that does not matter. After the first two legs for the Knight jump, two more legs follow for the rifle capture, the first making the capture as a normal capture in any possible direction, the second one to move back (cabK). Because of this description, one has to click the locust victim first, before clicking the target square of the Forest Ox.

Intelligent Diagrams!

I now equipped the diagram with a simple generic AI, so that you can play against it as a demo. It is not very strong; just a simple alpha-beta searcher with a recapture extension instead of an all-capture Quiescence Search, set for a depth of 2 ply. Somewhat like micro-Max 1.6. Except that it doesn't even have good piece values; it guesses these by itself.

Any Interactive Diagram should now automatically have the clickable phrase 'Play it!' on the line below the diagram that also served to open the piece overview. If this is clicked, the AI is switched on, and a button bar will appear. Any move played in the diagram will then automatically be replied to with a move of the opposite color. The diagram will continue to do this until you hide the button bar by clicking the 'Play It!' again. The diagram will collect all moves (both yours and those of the AI) into a game, and the button bar will allow you to navigate through that game.

Simplicity is a hallmark of elegance. So I think it is in general better to not use several completely different mechanisms for introducing pieces on the board. Use gating, dropping or brouhaha squares, but then stick to the method of choice.

Of course a question could be: why use any of these at all? What does it add to the game that some of the pieces start on brouhaha squares? They still have to make the first move as if the brouhaha square was a normal board square, so for the pieces themselves it makes no difference. One uses brouhaha squares to prevent distortion of the board regularity, which could interfere with checkmating abilities as these are on rectangular boards, such as the Omega-Chess Wizard squares do. So you can create room for extra pieces without side effects on the board.

But why would you want to create any extra room at all, if you already have so many empty squares on the back rank, in your initial setup?

@Greg & Thor: I used that same 'lonely King' setup in Elven Chess. I did not consider it odd at all. Why would you want the King to start in the front line? This way you have free castling paths immediately, so you don't have to worry about evacuating non-jumping pieces to clear the path, and destroying the Pawn shield in the process.

In an engine I solve this by making a Lion that captured a Lion (from a distance, etc.)  a temporary absolute royal for one turn. Then playing Ln x protected Ln is considered exposing yourself to check. (In my Crazyhouse engine I do something similar to enforce the ban on castling through check: castling initially ends up with the Rook replaced by a second King. After move generation of the opponent (which would detect the King capture) I then replace that by the Rook it should be. After Other x Lion I make the opponent's Lion iron for one move.

All you need is the concept of 'temporary promotion', piece types that at the beginning of their own turn revert to the unpromoted form. And then have some extra types that are royal and iron.

Btw, note that the counter-strike rule on Lions does not hold when the two Lions are captured on the same square. If a Kirin captures a Lion and promotes in that same move (to Lion), it is allowed to recapture it.

This is a test to see if the Interactive Diagram handles brouhaha squares well.

The autoGate option

I added a new option to the Interactive Diagram, to make it possible to use brouhaha squares also for Musketeer-style gating. This is mainly an AI thing: in the manual use of the diagram it was already possible to drag the pieces that should be gated from the brouhaha square where you put it to the board as a separate move. The design choice of not enforcing any turn order in the diagram was made precisely do allow that kind of double moving. The only thing that changes here by specifying autoGate=1 is that highlighting of the normal moves the piece has from the brouhaha square is suppressed on the extreme ranks.

But when the AI has to think ahead it has of course to know that the pieces are gated as side effect of any move of the piece in front of it. And the AI should not kinck in when the user has moved his back-rank piece before he had time to also perform the accompanied gating. This should now also work.

The Musketeer Chess demo

The diagram above gives a reasonable representation of Musketeer Chess, taking into account that we are not dealing with a program dedicated to a specific variant, but merely with an 'electronic chess board' intended to be a virtual representation of your woodware board at home. That it can indicate the pseudo-legal moves of the pieces you grab is merely an aid to the memory, which in chess variants can be pretty useful.

To use the above diagram as a Musketeer Chess demo, you can drag the selected Musketeer pieces from the piece table to the gating ranks. You would have to do that for both sides; the generic AI only knows how to push chess pieces over a board, and doesn't support any variant-specific stuff like selecting gating squares. After you placed the pieces, you can start the AI and play against it.

The AI of the diagram now also has a vague notion of the Lion anti-trading rules. It isn't perfect yet, because it does not apply the rule for 'bridge capture' yet; you can just generally forbid capture of protected pieces of a certain type. It also doesn't limit it to distant captures, but I guess that only means it unjustly forbids moves that you would never want to make anyway.

I am not sure what you mean by 'shuffling'. Something like in Chess960? The diagram just sets up the position that you specify. It would be hard for a general diagram to know what kind of shuffling is acceptable. (E.g. must the King stay between the Rooks? What if there even aren't Kings or Rooks? Or when there are multiple ranks of pieces? Or brouhaha squares?) And what should trigger the shuffling? Refreshing the pase, to re-initialize the diagram? Should there be a button for it, and if so, where?

It might be better to just start with the squares that contain shuffled pieces empty, and put all pieces in the 'hand' in the initial position. People can then first set up the shuffle the want by dropping the pieces, and start playing from there.

Of course it would also be possible to just embed a small JavaScript routine in the HTML page that does the shuffling in the way you want it.

BTW, I added a hidden feature to the Diagram. (This was really only for debugging purposed, and I am not sure I am wise to mention it. For people might take it serious, but they will probably discover it anyway.) When you click the 'move' header in the piece table, the column toggles to display the piece values estimated by the AI instead of the moves in Betza notation. Don't believe them; it makes exactly the same errors as most people do when guessing piece values!