| Author |
Message |
Fergus Duniho (Fduniho)
| | Posted on Monday, March 17, 2003 - 10:47 am: | |
I have just realized and confirmed that neither my Shogi ZRF nor the Zillions Shogi ZRF is fully accurate. The problem is that each will sometimes allow a Pawn drop to checkmate a King -- even though that is against the rules. When the space in front of the enemy King is attacked by another enemy piece, both ZRFs will allow a Pawn to be dropped there. The assumption has been that this piece will be able to capture the Pawn, and it won't be checkmate. But when that enemy piece is pinned, and its player has no other means of avoiding checkmate from a Pawn drop, a Pawn drop will cause mate. I have confirmed this in both ZRFs by setting up the appropriate situation, dropping a Pawn in front of a King, and checkmating it with the drop. While there may be some complicated way to implement Shogi accurately, what would be really helpful would be another command. You might call it "attacked-by-unpinned?". This would indicate whether a space was attacked by any unpinned pieces. In this context, a pin would be understood as being unable to move to a space without revealing check on a checkmatable piece belonging to one's own side. |
Fergus Duniho (Fduniho)
| | Posted on Tuesday, March 18, 2003 - 7:22 am: | |
Here's a more general approach to the the idea I described yesterday. Have a pair of keywords called 'vulnerable?' and 'not-vulnerable?'. 'vulnerable?' would work like 'attacked?' except that it would not count attacks that would be illegal in the position that would result from the move. Using the 'not-vulnerable?' keyword would also eliminate the need to use move-types to identify non-king moves in Shogi.
And here's an alternate suggestion for fixing the illegal Pawn drop problem in the Shogi ZRFs. Introduce a pair of keywords called 'endgame?' and 'not-endgame?'. These would indicate whether making a particular move would end the game. But it might be trickier to program, because it has to calculate the results of the move before it will know the value of the condition. Since it will work more easily with an a simple add than with a more complicated move, it might be better to just introduce a new kind of add that can be used only when it won't end the game. This could be paired with another new kind of add, which would allow an add only if it will end the game. Both kinds of adds could prove very useful in games. You might call them add-continue and add-stop, or you might think of better names. |
Jeff Mallett (Jeffm)
| | Posted on Tuesday, April 29, 2003 - 5:51 pm: | |
"This would indicate whether a space was attacked by any unpinned pieces."
These are trickier things one might first think. One reason is that the concept of a "pin" itself isn't generic, when one can define moves that do anything. Pinned pieces usually can move, as they are usually pinned only in a single direction. In some games you might have a piece that capture the pawn in some ways and leave its king(s) in check and in other ways that don't.
So, the only foolproof way of doing things would seem to be the second suggestion:
"'vulnerable?' would work like 'attacked?' except that it would not count attacks that would be illegal in the position that would result from the move."
However, think a second... what move are we talking about here? You are checking this "vulnerable?" condition in the move code that may or may not lead to the addition of a move or several moves. The move can't be checked to see if it leaves a piece under attack when it hasn't even been fully defined, much less generated.
As an example, pretend that I'm writing a chess variant and there is a white R on a1, a black P on a7, and a black R on a8. White's R on a1 is not under attack now, but if the black P on a7 were removed, white's R would be under attack by black's R, right? Now suppose the move code for another white piece goes like this:
( n (if (not (vulnerable? a1)) (capture a7)) add)
Thus, this move will capture a7 (making a1 vulnerable) only if this move doesn't make a1 vulnerable. This move will not capture a7 (leaving a1 non-vulnerable) only if this move does make a1 vulnerable. A paradox that shows that this command can't be implemented.
The only generic solution I'm seeing right now is a new kind of "add" or argument to "add" (since at that time the move is fully defined) that generates the move assuming that playing the move doesn't lead to a certain square being attacked. To be honest though, I don't think this command will be useful in many other games, whereas I know lots of other commands/features that would be generally useful, so adding isn't high on my priority list. |
Alexander E. Stevens (Dienyddiwr)
| | Posted on Monday, June 09, 2003 - 4:52 am: | |
what about a keyword for checking if a move will result victory at all? I think that'd work and be much more generally useful.
in the case of shogi, you'd just have it check in the Pawn's Drop code. |
John Kewley (Jkew)
| | Posted on Friday, September 24, 2004 - 5:42 pm: | |
This sounds like a similar problem I had to solve for my Zillions Chu Shogi program.
It was part of the complicated conditions regarding Lions taking Lions, in particular the rules for "hidden attackers" (which weren't implemented in Steve Evans' version). I'd have to go back and check and see if I can transfer the technique I used to basic Shogi.
Cheers
JK |
|