[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]
Comments/Ratings for a Single Item
This condition in Zillions could probably be solved by having the dropped Pawn trigger the opposing King to immediately capture the dropping player's King(or a dummy piece on a dummy position which has been flagged as checkmate-able) if it has no other option. This may be accomplished by having this move placed within a specific move-type, and this placed last in move-priorities. In this move the King will verify the attacking Pawn for last-to? and the position behind it to be sure that it did not last-from? there. This particular move would then prevent the placement of a drop Pawn in this position since it would result in checkmate for the dropping player. [I've actually tried this and, so far, it doesn't appear to work. Some form of idiosyncracy related to the move-priority. Any ideas about a work-around would be welcomed.]
I knew that the move-priorities-trick does not work. Zillions resolves move-priorities before the checkmate condition. So it first concludes there is a normal move and then thus renders the special move illegal versus the move-priorities. And then it renders all normal moves illegal because of check. A possible solution is to take into account that defenders can be pinned by Bishops, Rooks, Dragon Horses and Dragon Kings. It is easy to implement (A defending capture move is either like a Bishop, like a Rook or like a forwardmost Knight, the relative position of the mating Pawn with respect to the mated King is fixed. This leaves six pinnable positions for defenders (four diagonal and two orthogonal). However, this does not solve the problem. It just reformulates the Pawn drop rule to 'A Pawn may not be dropped to check the enemy King when ... (long formulation involving the geometric explanation of some specific pins) ...'. It should be 'A Pawn may not be dropped to give checkmate'. In Shogi these rules may have the same effect, but it doesn't give a checkmate-detection that always works. If someone wants to use Shogi.zrf to make a Shogi variant with some different pieces, he or she can never know that the Pawn Drop Mate rule is well implemented. The same problem is there for Tamerlane 2000, where Princes can become Kings when the original King is mated (It is not implemented because detecting checkmate in Tamerlane 2000 is a nightmare). Another example is 'Thirty-Nine squares Chess' where you may leave your King in check, but you lose if you are mated (Kings return when captured). I have an ugly solution for the last example, but the ZRF is still too ugly and buggy to publish. A (dirty) solution would be that the Pawn Drop Mated player can declare checkmate after a pawn drop. On such a declaration, the whole position if flipped (A Black Gold on 3f becomes a White Gold on 7d, etc) and the player that dropped the Pawn is automatically checkmated if it were checkmate, but that player should win the game if he or she can continue with a legal move (Penaly for a false declaration). It takes a while to implement. You have to know whether the opponent just did a Pawn drop, the flip mechanism must be implemented. The flip must be registered (for instance by dropping a Sign piece on a dummy position). These Sign pieces should also enable a 'death penalty'-move if the dropping player manages to prove that it isn't checkmate. Anyway, it really fucks up the ZRF just to use the (checkmated ...)-command in a different context then ending the game.
3 comments displayed
Permalink to the exact comments currently displayed.