Comments/Ratings for a Single Item

I have something similar in Short Sliders.

The Queen being on White's left, try ilO3irO4. The ID (or so I'm told) reverses it automatically for Black.

How do I make the Interactive Diagram allow up to 3 spaces for Queen-side castling and up to 4 spaces for King-side castling? The way it currently is now allows up to 4 spaces on each side.

Added Interactive Diagram to page. This diagram makes use of Game Courier sets, and it includes a static image to display if JavaScript isn't enabled.

Worthy of mention is the CRNBAKBNRQ setup, which is used in Victorian Chess. I have been placing Queens and Chancellors in the corners of various size boards since 1997.

I am very sorry and apologize since my lack of signing my comment below has led to a misunderstanding. It was late, and I simply forgot.
My name is Bernhard Hermes, and I am not H.G.Muller, and I sometimes use signs like :-(

(And, it seems, I sometimes add unnecessary 's's to English verbs...)

I actually like that proposal a lot!

In more lightweight games we coud have A=Alfil and C=Cannon.

'Thus a FEN string always should use those piece letters with a well
defined, preferable traditional meaning: this moment I suggest
J/A=Archbishop(N+B), C=Chancellor(N+R), G=General/Gladiator(N+B+R).'

I was under the impression that the most 'traditional' name for N+B+R is
Amazon. Thus it would still be able to have a good encoding using
well-known names, namely C-Cardinal, M-Marshall and A-Amazon -- seems to
me this would use names everybody in the chess variant world immediately
understands. They just don't happen to just by chance match Archangel and
Centaur ;-)

'I regard this to be a very big weakness,  ...'

It is not that bad, if you realize that there is a different mechanism in WB protocol to achieve the same thing: by sending a move to the engine, you implicitly ask the engine if this move is valid. If it isn't, the engine ignores it, and sends an 'Illegal move' message to the GUI. The GUI then undoes the move on the display, and relays the illegal-move message to the user, or engine opponent. As most engines are not considering the possibility that their moves might be illegal, the game then usally hangs, however. But the GUI doesn't have to know about the rules in this case.

There is a big advantage of having the GUI understand the game, though, when you cannot rely 100% on the engines. Then the GUI itself can judge the legality of the moves sent to it, make the engine that does the illegal move forfeit (you don't want to give engines the power to make their opponent forfeit...), and forfeit engines that do make false illegal-move claims. And in WinBoard_F this functionality can be switched on optionally in many variants. The other variants can still be played, with legality checking off.

| if there is only ONE castling move possible at all, it will be 
| matched by ANY string starting with 'O'. 

Why would you want that? It still would not help to understand all games of variants that interchange the O-O and O-O-O notation.

I am not sure why you would want to allow translation in PGN, but not in FEN. In WinBoard I added the external option (/pieceToCharTable) to alter the piece indicators. These would then be used consistently in both FEN and PGN, without any internal tags. The most common case where this is needed is for reading PGN files from a different language. The problem with the tags you propose, is that they still would have to single out one language as 'standard', and other languages will never agree with that. So I think it is better to make that specification external. After experience with some less-known variants (e.g. Knightmate) I realized that this translation should be independently settable for the external interface (saving and loading FEN and PGN), and each engine. This to play engines using different 'standards' against each other. It might even be desirable to have a separate translation table for external reading and writing, so that the GUI could be used to convert PGN files in one language to another one.

I don't think the J-system you use for Janus Chess is acceptable: it only works for opening positions. It should be possible to play from arbitrary positions specified by FEN. And you have no way to indicate that Pawns cannot promote to C in positions where there is no A/Janus on the board. The only logical solution would be to use the J for Janus Pawns, different from Capablanca Pawns by not being able to promote to C. But for Chancellor-Chess positions without a Chancellor, you would then need yet another letter for 'Chancellor Pawns'. And this is what I don't like at all. In Seirawan Chess you would need Capablanca Pawns on an 8x8 board, different from normal Pawns, so you would also need different indicators for Pawns in normal and Capablanca. Or use different letters for Capablanca Pawns on 8x8 and 10x8 boards, to preserve compatibility with existing 10x8 FENs. It quickly prolifirates, and becomes very awkward... Much better to just consider them different variants.

H.G.M.: '... there is no way in WB protocol to request it from the engine ...'

This is true also for UCI. I regard this to be a very big weakness, which I have avoided in SMIRF's TMCI protocol, which is unfortunately used by nobody else but your Smirf-O-Glot. 

Because engines using that new FEN and multi-variant approach still have to be written, why not to extend used protocols in this point? A GUI SHOULD be able to ask an engine for ALL possible moves. There is no need for an intelligence for this inside the GUI, because it would not be able to grow with upcoming new variants.

H.G.M.: '... the O-i-h system ...'

Nevertheless I would like to use following convention for stored PGN files: if there is only ONE castling move possible at all, it will be matched by ANY string starting with 'O'. 

The use of different letters e.g. M (Marshal) instead of C (Chancellor) or C (Cardinal) instead of A (Archbishop) should not be handled by the FEN string, but by a new to be defined PGN translation tag e.g. for embassy chess: [translate 'M=C C=A']. This is for showing traditionally translated piece letters (to be used on the GUI and PGN only, but NOT inside FEN). An exception to this is the use of J=Janus, having the special meaning of avoiding any Chancellor. Here it would be necessary to use also an additional tag [translate 'O-O=O-O-O O-O-O=O-O'] because of the unlucky old switched encoding decision inside of Janus.

Thus a FEN string always should use those piece letters with a well defined, preferable traditional meaning: this moment I suggest J/A=Archbishop(N+B), C=Chancellor(N+R), G=General/Gladiator(N+B+R). ANY big piece type MENTIONED inside the INITIAL sent FEN might be used for promotions, additionally all the well known 8x8 and 10x8 standard pieces (but using J would disable C).

'If the effort isn't too big' is a big if. Normal chess, Capablanca, FRC and CRC are similar enough not to cause too much trouble. Although I consider it already a nasty trait that some of the rules have to be implied by the board size, such as to which pieces a Pawn may promote. If a board width of 10 is taken to imply Chancellor and Archbishop are allowed, the problems with Janus Chess or Chancellor Chess I would consider already pretty bad. To unify those with Capablanca/CRC would require different letters for their Pawns. In Janus Chess you would have to indicate the deviating castling mode amongst the rights.

In the O-i-h system you would always be able to deduce if the K-side or Q-side rook is to be used by the ordering of the King and Rook destination? I guess we could indeed consider it a defining property of a castling that it swaps the order of King and Rook. I am not aware of any exceptions to this, even in FRC/CRC the King is required to be between the two Rooks. So I guess your system is acceptable for in the PGN, with the additional preference rule that if there is only one castling possible to the given side, it would be written as O-O or O-O-O.

The way the move is transmitted between engine and GUI in WB protocol is a matter specific to the WinBoard GUI. And WinBoard does generate the list of allowed moves itself, there is no way in WB protocol to request it from the engine. As this type of castling with multiple King and Rook destinations is about as crazy as they get, anticipating this format would probably enough to cover everything. Even the normal castling requires the GUI to recognize castlings, and know which Rook to move and where. (This caused problems when I had Fairy-Max play Cylinder Chess, as a King crossing the side edge was considered a castling, and led to the displacement of a second piece on the display board!) In fact, with the assumption that the relative orientation of King and Rook destination squares implies which Rook has to be used (and even if there are several Rooks on that side, only the one nearest to the King could be involved in castling), there is no need to convey any information in the 5th character other than that it is a castling. So an O here would be quite convenient, as promotion pieces have to be lower case in WB protocol.

For a really dumb interface (like my battle-of-the-Goth javascript viewer) it is necessary to fully specify from- and to-square of each piece that is moved separately. So there I transmit O-O as e1g1h1f1 and e4xf5 e.p. as e4f5e4f4.

H.G.M.: '... how much effort one should put into upkeeping a unified approach ...'

Why not, if the effort isn't too big? So let's try out some ideas.

H.G.M.: uses: 'Ke1-i1&Rj1-h1'

Maybe I am too traditional, but I would like to have an encoding startig with 'O'. Here I would suggest to write 'O-i-h' using the first column letter for an untypical King's target square and the second one for an untypical (not inner neighbored) Rook's target square.

H.G.M.: '... but simply as FROM and TO square ...'

Appending a letter (I would prefer the involved Rook's/piece's source column letter) is only a partial solution, because this forces the GUI to somehow generate the input gesture squares, which demands, that its programmer has anticipated this (what is not necessarily the case at a new variant). But, because the problem of two unique squares representing this move exists nevertheless, it would be covering more, to use those square coordinates also for to communicate the move.

Nevertheless here again is an encoding problem, when a free castling would also allow to place the Rook on different selectable squares. Thus I still have problems with such types of castlings.

My understanding of a GUI is, that it has not to know much about chess. It has to ask for all the possible moves, have the user make a selection e.g. by clicking at two squares, and to communicate this choice to the engine, using the move code it has sent before by request.

Well, one has to think ahead a little bit to keep the road to future extensions open, and not paint oneself into a corner. This is why I tackle a fairly large number of cases at once.

I don't see the unicity of the FEN strings as a serious problem; if the logic behind the various systems would allow a certain castling to be described in multiple ways, one can supply an additional rule to specify which method should be used preferentially. e.g. if K or H could be used to unambiguously specify king-side castling, one should use K. In the FEN reader I would not even pay attention to that, and have it understand both, as this is usually easier.

An important issue is how much effort one should put into upkeeping a unified approach, in which both game state and played variant are unambiguously specified by the FEN. One might wonder if it is sensible to require, say, that a position from Janus Chess and a position from Capablanca Chess should be considered as different positions from the same variant, 'fullchess'. This puts a lot of extra burdon on the FEN:

For indicating game state, the castling rights have to indicate only which pieces moved. Wanting the FEN to specify the castling method, or other aspects of the rules (e.g. if Pawns can promote to Chancellors, or not), might just be asking for trouble.

So perhaps I was overdoing it. It might be more useful to consider variants like Janus or Grotesque as distinct from Capablanca. KQkq could then be used to indicate castling rights in all three cases. Games with more than 2 Rooks could use the Shredder-FEN system without any problem, as long as there is only one King (so that all rights disappear once this King moves). Only in games with multiple Kings AND multiple Rooks there would be a problem.

This only leaves move notation. In particular in variants where a castling to a particular side can be performed in more than one way, like in Grotesque. A very general way to solve this in PGN would be to provide a mechanism to specify moves that displace more than one piece, by joining the moves with an &. So an alternative to write h-side castling in Grotesque could be Ke1-i1&Rj1-h1 (or in short, Ki1&Rh1).

In WinBoard protocol, the moves between engine and GUI are not transmitted in SAN, but simply as FROM and TO square appended to each other, with an optional 5th character to indicate promotion piece (e.g. e7e8q). Perhaps the best system there would be to encode variable castlings by using k or q as the 'promotion' character, to indicate if the K-side or Q-side Rook is to be used, and make the squares indicate the to-square of King and Rook, respectively. These notations would always be recognizable as not indicating promotions, as both the mentioned squares would be on the same rank.

To H.G.M.: Harm, you are proposing a lot of things simultaneously. So let me answer slowly. There should be a main primary demand, that such an extended FEN should end in an IDENTICAL string, when applied to common chess variants. Otherwise I would not like to support it. There already has been a quarrel concerning X-FEN and Shredder-FEN, which is incompatible to that demand. Nevertheless in the early days of X-FEN I modified its definition concerning a less important element to also cover the proposed additional demand to have a partial castling string in FEN NEVER longer than 4 letters. I would like to preserve that state of the art of X-FEN.

Actually I would like as a first step to merely support castling rights, where the castling piece will be placed upon the next inner square neighbored to the (one only) castled King. The King will be placed by default THREE steps from the a-side performing 'O-O-O' and TWO steps from the other side performing 'O-O'. The algebraic notation should use source and target coordinate, when the king is moving at least two steps when castling with the most outside Rook. Otherwise the coordinate of the involved piece has to replace the (redundant) target square. This is for to serve two goals: a) to avoid a mixing up with traditional King's moves, b) to give the GUI a unique information, by which input gesture a castling should be intended without any doubt. Such a modification should not be interpreted as a 'capturing' of the involved piece, instead as a jostling it for to have it join the castling procedure. 

To encode the castling rights: the default is to address the most outer Rook by traditional letters 'Qq' for the a-side, 'Kk' for the opposite side. In any other case the column letter of the involved piece should be used: in upper case, where a white colored piece is addressed, in lower case, where that piece would be black colored.

Now to different castling methods: because such methods would target all possible castlings (never different methods for different pieces) it does not make sense to encode this related to the elementary castlings. Instead the whole partial castling string inside a FEN has to be addressed. In SMIRF I solve this by applying a special prefix letter, which has to be different from any possible column letter to avoid misinterpretations.

Now let me stop at this point, to have the written text being discussed.

I am still contemplating how to generalize the castling in Joker80. There are two issues there: how to commnicate the move from and to the GUI, and how to indicate the existence of the rights. Currently WinBoard protocol has two mechanisms to set up a position: by loading the engine with a FEN, or (obsolete) through an edit command to enter a list of pieces+squares combinations. The latter mode does not support transmission of castling rights at all, and is only a legacy for backward compatibility with old engines. So for loading position, we only have to provide a mechanism for indicating castling rights in a FEN.

The FRC-type notation only indicates the position of the Rook. The King does not need to be indicated in games where there is only one King, and the positioning of Rook w.r.t. King implies where both will end up. This means we would have to devise some other notation for cases where the King ends elsewhere. I am not sure if it would make sense to generalize so much as to allow castlings where the Rook does not end up next to, and on the other side of the King. There is of course no limit to the craziness of moves that could be called a castling, but one would have to put a limit somewhere, to not fall victim to the 'maximum-flexibility, minimum-usefulness' principle.

I would probably implement it like this: in the castling-rights field of the FEN, the letter indicating the file of the Rook that can castle (which does not necessarily have to be an orthodox Rook, as the FEN makes it obvious what piece is standing there) can be followed by a digit, indicating the number of squares the King ends up away from the corner. The final position of the Rook would be implied by this.

Example: normal King-side castling rights could be indicated by H1. The 1 would be the default (on an 8x8 board), and could be omitted for upward compatibility with Shredder-FEN. In Capablanca Chess the opening would have castling rights A2J1a2j1, equivalent to AJaj (or KQkq). Symmetric castling rights like in Janus Chess would be indicated as A1J1a1j1, or A1Ja1j when deleting the redundant defaults. Multiple castling rights to the same side could exist next to each other: A2A1J2J1a2a1j2j1 would allow short as well as long castling in both directions.

For transmitting the castling moves, one could use King captures own Rook. In games where the same Rook could be used for castlings with multiple King destinations, one could give the King step to its final destination in stead. If this could also be a normal King move, one could append an r as 5th character to identify it as a castling, using the syntax that would otherwise be used for promotions. In PGN one could use similar strategies to indicate non-orthodox castlings, and use suffix =R on a King move to specify castling.

I think this covers most cases encountered in practice. Problems only occur only if there would be multiple castlings with the same Rook, and at the same time castlings with a Rook on the left would have the same King destination as those with a Rook on the right. Because the move notation cannot indicate at the same time which Rook to use and specify where the King should go. But this seems to outlandish to worry about.

To cover cases where K and R do not end up next to each other, we could put a second digit in the FEN castling-rights specifier for the final position of the Rook wrt the corner. (I.e. normal king-side castling = h12.) This obviously could lead to problems on very wide boards, that require multiple digits to specify distance to the corner. So perhaps it is better to separate King and Rook destination by a period (h1.2). Indicating the move would be a problem, as two destinations might have to be specified to unambiguously identify the move (e.g. if all castlings are allowed weher the King steps any number of squares >=2 towards a Rook, and then the Rook can go to any square the King passed over.) One could just specify King and Rook final squares (i.e. O-O = g1f1), but in FRC there is no guarantee that this cannot be a normal move. In which case the 'r' could again be used as 5th character, to indicate castling. In PGN we could reserve a character used in stead of the piece indicator for castlings, say 'O'.

Conclusion: it is difficult to design a notation that would be general and universal; different games seem to need different ways to specify the moves and rights.

'... support for the 'free' castling ...'

This is not clear to me. I think it over to possibly implement free castling into SMIRF, but still there is missing a detailed explanation of rules and notations (I would suggest: O-c-O if King is castling to column c). Where could I have a closer look?

Here's that page I couldn't find before, that describes how to make fairy
chessmen out of regular Staunton pieces:

http://www.chessvariants.org/crafts.dir/fairy-chess-pieces.html

It's listed in the alphabetical index under 'How to make ...', but I think 
it would be better to list it in the index page of the Crafts section:

http://www.chessvariants.org/crafts.dir/index.html

As I say, I've used the technique described to make a Marshall and
Cardinal, though I haven't followed the full instructions for
dismembering a whole chess set to make the full range of pieces the author
shows. But I have enough to make an attractive set for Grotesque Chess.

'Also, given how the game (British Chess) is so based on British heraldry
and other British themes, it would be a grave insult to the British to
call it by that name [Grotesque Chess].'
	Being British myself, I feel more qualified to what is a grave insult to
the British, and it is because I found the name British Chess insulting
that I suggested giving the variant of that name a different one
distancing it ftrom Britain while reflecting a British oppinion of it!
	Where do you want further discussion on the above topic,here or on the
British Chess page?

This arrangement of simple pieces opens a whole new debate. RB-N--N-BR
alone protects all but the d and g Pawns. Therefore any arrangement of the
four compound pieces will protect all Pawns as only one lacks the required
diagonal move. What are the relative merits of the 12 distinct
arrangements (or even just the 6 with a centralised King)?
	In case anyone is wondering, it may be worth stating that the origin of
the piece names used here is Bird's Chess.
	I agree with the others that this variant is far from grotesque. Perhaps
as the distinctive feature is having Knights so near the middle a good
name might be Mid(k)night Chess. On the other hand Grotesque Chess would
be a far better name for the variant currently called British Chess, which
was mentioned in an earlier comment.

I perused Pritchard's ECV today, and I did find one game that had a
castling rule like Grotesque Chess's. The game is Supercapablanca Chess,
a 12x8 version of Capablanaca's Chess. Its castling rule states that a
King may move two, three, or four spaces toward the Rook. Its castling
rule would be equivalent to that of Grotesque Chess within the context of
Grotesque Chess, though as I worded the rule for Grotesque Chess, its rule
would not be equivalent to that of Supercapablanca Chess on its longer
board, since it would also allow the King to move five spaces toward the
Rook.

If I needed to, I would have just reworded the rule to match that of
Supercapablanca Chess. But I am grateful that you're willing to let
anyone 'use this form of modified free castling ... in any variant.'

I came to this form of castling mainly from a programming perspective. In
Game Courier, I had been distinguishing castling from a King's usual move
by noting where the King moves to. But when I thought of implementing
unrestricted free castling, this wasn't going to work out. Even more of a
problem from a programming perspective was giving the Rook a choice of
which space to move to. As I thought about the matter more, I concluded,
as you have too, that unrestricted free castling is basically two moves in
one, and that makes castling too powerful.

George Duke writes:

Fergus Duniho correctly points this assortment of pieces goes back 500 yrs.(Regina Rabiosa's debut), so hardly original.

No, I didn't mention anything earlier than Carrera's Chess, which is just under 400 years old. I don't know what Regina Rabiosa is.