Check out Symmetric Chess, our featured variant for March, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

Later Reverse Order EarlierEarliest
Grotesque Chess. A variant of Capablanca's Chess with no unprotected Pawns. (10x8, Cells: 80) [All Comments] [Add Comment or Rating]
🕸💡📝Fergus Duniho wrote on Fri, Dec 8, 2023 02:04 AM UTC in reply to Bob Greenwade from 01:36 AM:

Thanks, I defined the King as KisO2isO3irO4, and that works.


Bob Greenwade wrote on Fri, Dec 8, 2023 01:36 AM UTC in reply to Fergus Duniho from 12:24 AM:

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.


🕸💡📝Fergus Duniho wrote on Fri, Dec 8, 2023 12:24 AM UTC:

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.


🕸💡📝Fergus Duniho wrote on Fri, Dec 8, 2023 12:12 AM UTC:

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.


David Paulowich wrote on Mon, Jan 5, 2009 11:58 AM UTC:

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.


🕸💡📝Fergus Duniho wrote on Mon, Jan 5, 2009 04:26 AM UTC:Poor ★
I think this is not such a great game. It is flawed by having opposing Bishops along the same diagonals, which makes it too easy for the Bishops to eliminate each other early in the game. Univers Chess and Ladorean Chess also share this flaw. Besides the problem with Bishop placement, it also places the Queens and Equerries too close to common diagonals, making it too easy for them to attack each other early in the game. Univers Chess and Ladorean Chess do not share this flaw, which makes them slightly better games. Schoolbook Chess and Embassy Chess share none of these flaws. Between these two, Schoolbook Chess seems to me to be the better game.

Bernhard Hermes wrote on Thu, Oct 30, 2008 07:46 AM UTC:
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...)

H. G. Muller wrote on Wed, Oct 29, 2008 10:54 PM UTC:
You are completely off base with your accusations. Why would I wait 4 months to revivive an old discussion that I already was involved in and that died a natural death? That makes no sense. I always answer swiftly. :-) and ;-) are standard smilies. Millions of people use them. I might as well accuse you of every annmous post that ends with a perion after the last sentence...

George Duke wrote on Wed, Oct 29, 2008 10:33 PM UTC:Good ★★★★
'':-)'' is Muller's own characteristic notation, as for example Muller's Comment 25.October.2008 at ''Zillions and GC,'' using the same '':-)'' at the end. So in the last two immediate comments. H.G. Muller is holding conversation with himself, anonymously as ''__'' and then with the user identification, following closely. That is fine. I actually also slightly prefer Threads where I name the topic and make up to all Comments, like current ''Anand_Kramnik.'' The particular style as variety keeps direction if not always depth and clarity. Now credit Grotesque's using the year 1992 Falcon-initiated form of castling two or more over. The problem of course, discussed more mid-decade, is that really all of these on 8x10 are Carrera-Capablanca randomized set-ups. Somehow for the general chess public, it would be better if all like Grotesque were under one roof, from Duniho's, Trice's, Trenholme's, to Winther's several ''Carreras'' on 8x10. Suppose for example, a string of ''Rococos'' differed only in position of Swapper, Immobilizer as to which one is oppositely-cornered, and Chameleon and Withdrawer as to which sits next to King. It is self-evident they would all still be Rococo. It is obvious point by now for regulars, but I always try scaling my Comment in context to draw more interest from casual viewers. Also relevant is thread ''FatallyFlawed M/C,'' that Marshall and Cardinal are proven subpar pieces of historical interest mainly, and active designers pretty much omit them nowadays.

H. G. Muller wrote on Wed, Oct 29, 2008 08:59 PM UTC:
I actually like that proposal a lot!

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

Anonymous wrote on Wed, Oct 29, 2008 07:53 PM UTC:
'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 ;-)

H. G. Muller wrote on Thu, Jun 19, 2008 05:15 PM UTC:
'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.

Reinhard Scharnagl wrote on Thu, Jun 19, 2008 04:25 PM UTC:
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).

H. G. Muller wrote on Thu, Jun 19, 2008 03:31 PM UTC:
'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.

Reinhard Scharnagl wrote on Thu, Jun 19, 2008 02:22 PM UTC:
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.

H. G. Muller wrote on Thu, Jun 19, 2008 01:35 PM UTC:
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.

Reinhard Scharnagl wrote on Thu, Jun 19, 2008 11:54 AM UTC:
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.

H. G. Muller wrote on Thu, Jun 19, 2008 10:52 AM UTC:
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.

Reinhard Scharnagl wrote on Wed, Jun 18, 2008 09:29 PM UTC:
'... 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?

George Duke wrote on Thu, Jan 17, 2008 07:20 PM UTC:Poor ★
Progression. Twenty Comments here down to only 1 the last three years. Much ado about essentially nothing for 10 years 1996-2005 within venerable behemoth CVPage for 'new' starting arrays and tweaked castling principles after early 17th-Century Carrera's Chess. Finally, the particular genre of hair-splitting, evidenced now by inactivity, is laid to rest. Thirty-odd Carrera's derivatives, including famous Bird's and Capablanca's, clump together as failed attempts. Let us end the misery putting them down for the last time. Euthenize them, if it were figuratively possible, on the supposition that an idea has life. Creative Pietro Carrera's curiosities, Centaur(BN) and Champion(RN), original for their time, contemporaneous with Shakespeare and Pocahontas, came on the heels of 'defeat' of the Spanish Armada in 1588. Foredoomed in employing overwrought, ineffectual Chess-compounds, the stream of copycats for 400 years, one and all, proved destructive of critical skills and subtle play inherent in legendary, stand-alone utility Knight. R.I.P., Centaur. Requiescat in Pace, Champion.

Gerd Meyer wrote on Thu, Sep 20, 2007 09:57 PM UTC:Good ★★★★
A good game which I tried out with some homemade paper pieces - a worthy enhancement of classical chess.

Mark Thompson wrote on Thu, Jan 20, 2005 04:31 AM UTC:
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.

David Paulowich wrote on Sat, Jan 15, 2005 07:33 PM UTC:
Reply to the 2004-09-24 comment by George Duke: Thanks for reminding me of The Kibitzer #31 'Bring Back Free Castling!'. I have used that article to add some improvements to my comments on the Carrera's Chess page. Also to comment on the Piececlopedia article on the 'Duke' (the piece named after you). <p>PAIRWISE DROP CHESS: free castling and no dice required!

Anonymous wrote on Sat, Sep 25, 2004 07:18 AM UTC:
Another interesting idea for a large family of variants would be to arrange White based on one variant and Black based on another, not randomly but predeterminedly. In shorthand these might be termed things like 'Carrera's v Bird's'. The order (White first) would be significant as the first example would give different play from 'Bird's v Carrera's'. These would be intermediate between Chess with 'same' and 'different' armies, as the armies would start with the same pieces but in a different order. There is no rating as a further 'Good' would risk contributing to an unintended downrating.

Sam Trenholme wrote on Sat, Sep 25, 2004 03:33 AM UTC:Excellent ★★★★★
I think this is a great idea! As it turns out, I independently came up with my own opening setup with leaves no piece undefended in the opening: RQNBKABNMR (where A moves like Bishop + Knight; M moves like Rook + Knight). There are actually a number of such possible setups. <p> - Sam

25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.