Comments/Ratings for a Single Item

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.

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.

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.

'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?

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.

'... 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?

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.

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.

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.