The Chess Variant Pages
Custom Search

[ 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 Earlier
This item is a game information page
It belongs to categories: Orthodox chess, 
It was last modified on: 2002-11-29
 By Uri  Bruck. Cross-Eyed Chess. Two player variant on cross-shaped board. (12x12, Cells: 84) [All Comments] [Add Comment or Rating]
George Duke wrote on 2005-02-04 UTCGood ★★★★
'ABCLargeCV': Cross-Eyed Chess makes good use of unpopular Camel, which can turn corners annoyingly here. And Nahbi itself of course is one-path rider to the eight Zebra squares and eight Knight squares, plus Cannon-pawnlike (requiring intervening piece) Dabbabah in noncapturing mode. The Pawn's becoming Wazir-moving Ferz-capturing within the sixteen squares enhances the interest.

Uri Bruck wrote on 2002-12-11 UTC
The quote from Double King Chess looks like a good description of checkmating both kings simultaneously.

Anonymous wrote on 2002-12-10 UTC
<html> <body> <p>Thanks, I've enjoyed working on the game. Take a look at the zrfs for <a href=''> Double King Chess</a> and <a href=''> Full Double Chess</a>. I'm planning to code the win-conditions for Cross-Eyed Chess the same way. In these games, after one King is captured, the other King can no longer be moved into check, and a win is declared when it is checkmated. If it so happens that the other King is already in check when the first one is captured, it will be checkmated if it cannot remove itself from check.  Regarding the third win condition, Double King Chess describes double checkmate as follows:</p> <blockquote> <p><font color='#000080'>A player must always have a 'royal' piece as leader of his/her forces, but needs only one; the other can be given up. When a player has both 'kings' a 'check' usually isn't dangerous, but 'checking' becomes real (like regular chess) when a player has only one royal piece. <br> A move that 'checks' both kings simultaneously is a half-empty threat because on the next move only one of the royals can be captured. (*) The player can sac one royal in order to save the other. <br> <br> The only sense in which a '2K checkmate' can occur with both royals on the board is if a move checks both 'kings' and FORCES both the capture of one 'king' and checkmate of the other on successive moves. (Scores 1 1/2 points.) </font><br> </p> </blockquote> <p>This "2K checkmate" is not directly implemented in the zrf for Double King Chess presumably because of its complexity and because little is lost by requiring the capture of one King to occur before checkmate is declared.  If double checkmate is defined in this way, then I'm inclined to follow the lead of the author of this zrf and not try to implement it directly.  If double checkmate means that both Kings are checked and either could be captured on the next turn even though the remaining King might then be able to escape on the following turn, coding, I think, would be possible, but after looking back over the game and your post I'm reaching the conclusion that double checkmate has the meaning ascribed to it in Double King Chess.  Please let me know if that is incorrect.</p> </body> </html>

Uri Bruck wrote on 2002-12-10 UTC
Hello Dan, First, thank you for taking the time to do the Zillions implementation. I'll start with your first question: 'It seems to me that if the second King can be checkmated, it can never be captured. Are there circumstances in which the remaining King can be captured?' If a single king is checkmated, it means that there is no legal move to take it out of check, however 'The king is the standard chess king, with the exception that it may be moved into check, and it may be captured.' It's ok for the checkmated player to make another move that will leave the king in check, and then the king will be captured on the next turn. At first it might not seem to make sense to allow a king to move into check, and if you have just one left, it doesn't. Even if you have both of them it's still not a great move, unless it happens to be a winning move - a move that checkmates the other player. With two kings vs. one, the situation could arise. So capturing one king and checkmating the other is really the same as capturing both kings, checkmating the second just means the second capture is inevitable. If it's easy to code this, fine, if not, then that's fine too, because it amounts to the same thing. As for the third win condition, I haven't done any Zillions programming, although I've read the manual and some code. Without seeing the code it's difficult to answer. Perhaps the best answer I can give is that I prefer people to playtest the game as it was submitted, but if you think it would impact the AI, you can implement it one way, and then add the other implementation as a variant. Then even if the AI in the 'official' version is weakened, people can still playtest that version playing one another on-line.

Dan Troyka wrote on 2002-12-10 UTC
I just finished a Zillions implementation of Cross-Eyed Chess. It is currently coded so that the only win condition is capture of both enemy Kings. The second win condition, which has not been coded, is capturing one enemy King and checkmating the other. It seems to me that if the second King can be checkmated, it can never be captured. Are there circumstances in which the remaining King can be captured? The third win condition requires checkmating both enemy Kings. I understand that this means placing both enemy Kings in check so that neither can escape check on the next turn (even if, in fact, it would not have been possible to capture both Kings because capturing one requires removing the other from checkmate). This can probably be coded but the only method I can think of would substantially weaken the computer opponent. Do you have a preference as to how the win conditions should be implemented? The present version is best for AI purposes.

5 comments displayed

Later Reverse Order Earlier

Permalink to the exact comments currently displayed.