[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]
Comments/Ratings for a Single Item
I tried your PawnX.zrf (computer vs. computer). Following happened: 1.Nf3 Nf6 2.e4 N:e4 3.h3 N:d2 4.K:d2 g5 5.N:g5 Bh6 "Stalemate!" Black wins. Is this what you expected?
Hi Alfred, thanks for trying PawnX. Yes this is what I expected, consistent with the rules. After Bh6, the white knight should capture Pf7 or Ph7 but he can't, otherwise the white king would be in check. So white is in stalemate, losing the game. In all my tests (AI vs. AI) the games never ended in so few moves. Moreover, games usually end with a checkmate. What thinking time did you set for the AI? In PawnX, AI has to look ahead more so it needs more thinking time. Did you do other tests? How did they go? P.S. For now, I have noticed is a losing strategy to develop non-pawn too early in the game. You should move more pawns in the opening, setting traps for the enemy. Yes, I see pawns as traps.
I'm implementing a variant with bishops, rooks and queen move up to 4 squares. I think this will be better because decrease the "pawn appeal" factor. I will let you know how it goes. Anyway, I need a little help with zillion programming. How can I implement the rule "if the king is attacked ..." before a move of a non-king piece?
If you want to know whether your king is threatened, you'll have to search
out where it is, and then check this square with the "attacked?" command.
But if you only need to know whether a certain enemy piece is attacking your
king, you could perhaps use the same principle as I use in
Coordinator Chess, for instance. I have added a "king gaze" move to the king's
definition, at a lower priority than standard moves, so the king never
performs them. Other pieces can then check if the king "sees" an enemy piece on the
diagonal or the orthogonal, or the knight jump.
M. Winther
out where it is, and then check this square with the "attacked?" command.
But if you only need to know whether a certain enemy piece is attacking your
king, you could perhaps use the same principle as I use in
Coordinator Chess, for instance. I have added a "king gaze" move to the king's
definition, at a lower priority than standard moves, so the king never
performs them. Other pieces can then check if the king "sees" an enemy piece on the
diagonal or the orthogonal, or the knight jump.
M. Winther
Hi Winther, >>>If you want to know whether your king is threatened, you'll have to search out where it is, and then check this square with the "attacked?" command. Yes, I need to know where the king is, but I don't know how to do that. Could you please explain it to me more in detail? I need this piece of code because I want to change my first rule in this one: 1. if possible and if the king is not in check, it is mandatory to capture an enemy pawn Thanks.
In that case, provided that you have win-condition checkmate set, you don't need to check whether the king is checked, because Zillions does that automatically. Zillions forces you to make a move that protects the king, and you cannot make another move. So it is easy to enforce the rule that an enemy pawn must be captured. Simply add another "move-type" in every piece definition. This move type is exactly the same as the normal move-type except that (1) it is set to higher priority (2) you must verify before the move is executed that an enemy pawn is captured: "(verify enemy?)(verify (piece? Pawn))". This will enforce the capture of an enemy pawn provided that the king is not in check. It will still enforce the capture of a pawn if the king is protected thereby. However, this technique will increase the value of the pieces relative to the pawns. So you need perhaps to tweak the value of the pawns (and other pieces, too) by increasing the number of "adds". You could use my technique of "tweak-shift", which is simple. Zillions tries to evaluate the pieces, but this is highly complicated, and it is necessary to improve this evaluation by tweaking the value of pieces. This improves the playing strength very much. My version of Chinese Chess beats the Zillions standard version every time. It is much better only because I have given the pieces a more appropriate value. M. Winther
**M. Winther wrote:** Zillions forces you to make a move that protects the king, and you cannot make another move. So it is easy to enforce the rule that an enemy pawn must be captured. Simply add another "move-type" in every piece definition. This move type is exactly the same as the normal move-type except that (1) it is set to higher priority (2) you must verify before the move is executed that an enemy pawn is captured: "(verify enemy?)(verify (piece? Pawn))". This will enforce the capture of an enemy pawn provided that the king is not in check. It will still enforce the capture of a pawn if the king is protected thereby. *** I have done this procedure, as you can see in the zillions file I have posted in the first post of this discussion. I have a higher priority move-type, called “tasty-movesâ€, for each piece that check if it is possible to capture a pawn. If this is not possible , then you can make “normal†moves. But there is a problem, a big problem. If the king is in check and you can capture a pawn, for Zillions’ AI the only possible moves are those in which you capture a pawn, but with those moves you cannot get the king out of check, so it is checkmate. Not what I want. There is another problem. The situation is that a knight is protecting a king from an enemy bishop: white has Ke1, Nd2; black has Bb4. But there is an enemy pawn in e4, so the knight can capture it. Now, I want that the knight doesn’t move because if it do so, the king would be in check. But for Zillions’ AI there is no possible move, so it is stalemate. Not what I want. Any ideas? p.s. I sent you an e-mail.
Sorry, I didn't know that it worked that way. It is generally recommended for newcomers to Zillions programming to begin with a simpler game. This is a very, very, complex game. I suppose, the simplest way to solve this is to introduce yet another move-type which has the highest priority of all. This move-type is exactly the same as the normal moves (where pawn capture is not enforced). The only difference is that you must verify that the king is threatened before execution of this move-type is allowed. So you must loop through the board squares until you find the friendly king, and verify that it is threatened. Thus, only if the king is attacked, this priority move will be executed, and the player can thus make a move that is the same as a normal move. Should there be no move that can save the king, then Zillions will signal mate, which is correct. However, for the king itself, it's not necessary to make this loop, because you can check (verify attacked?) where it is placed. /M. Winther
Hi M. Winther,
>>>It is generally recommended for newcomers to Zillions programming to begin with a simpler game.<<<
I know, but I cannot limit my imagination. :-)
>>>I suppose, the simplest way to solve this is to introduce yet another move-type which has the highest priority of all.<<<
I think it is enough just two type of move: normal and "tasty". In the tasty moves, with higher priority, you verify (KING-NOT-IN-CHECK AND IT-IS-POSSIBLE-TO-CAPTURE-A-PAWN).
>>>So you must loop through the board squares until you find the friendly king, and verify that it is threatened.<<<
I'm having big trouble here. I wrote:
The idea behind is: a scan all the board and if any king is in check it is moved a marker in the dummy square named "king-check". I use "capture king-check" to clean the dummy square. (Assume I already defined all the links with "next", starting from the dummy square START.)
The problem is this piece of code doesn't work. What am I doing wrong?
>>>It is generally recommended for newcomers to Zillions programming to begin with a simpler game.<<<
I know, but I cannot limit my imagination. :-)
>>>I suppose, the simplest way to solve this is to introduce yet another move-type which has the highest priority of all.<<<
I think it is enough just two type of move: normal and "tasty". In the tasty moves, with higher priority, you verify (KING-NOT-IN-CHECK AND IT-IS-POSSIBLE-TO-CAPTURE-A-PAWN).
>>>So you must loop through the board squares until you find the friendly king, and verify that it is threatened.<<<
I'm having big trouble here. I wrote:
(piece
(name Controller)
(dummy)
(moves
(
capture king-check
START next
(while on-board?
(if (and attacked? (piece? King))
(create Marker king-check) )
next
)
add
)
)
)
The idea behind is: a scan all the board and if any king is in check it is moved a marker in the dummy square named "king-check". I use "capture king-check" to clean the dummy square. (Assume I already defined all the links with "next", starting from the dummy square START.)
The problem is this piece of code doesn't work. What am I doing wrong?
Matteo, with this solution you don't account for the case when the king is in check and the king can be protected by the capture of a pawn. I suppose you must enforce the pawn capture in this case, too. So "normal moves" might protect the king without capturing the pawn, although there is such a possibility.
So perhaps you should try the solution I suggested. Add yet another move-type, the highest of the three. To verify that the king is in check you could do like this, for instance (at least if it's white's move) :
a1
(while (on-board? r) ;correction: r
    (if (and (piece? King) friend?) (verify attacked?))
    r    Â ;r is the same as direction e except that h1 is connected with a2, etc.
)
/Mats
So perhaps you should try the solution I suggested. Add yet another move-type, the highest of the three. To verify that the king is in check you could do like this, for instance (at least if it's white's move) :
a1
(while (on-board? r) ;correction: r
    (if (and (piece? King) friend?) (verify attacked?))
    r    Â ;r is the same as direction e except that h1 is connected with a2, etc.
)
/Mats
Mats, you are right, I didn't consider that case. So now I have 3 type of move (from higher priority to lower): check-type, tasty-type, normal-type.
Your proposed solution, I guess, it is very cpu consuming, because for each move we have to scan all the board. In my last post I was talking about a neutral player that check if the king is in check before each player (and move a dummy-piece if it is so). What do you thing about it?
Anyhow, I have tried to implement your solution but I had a parse error. I defined the move in this way:
(define shift1-check (
START
(while (on-board? next) (if (and (piece? King) friend?) (verify attacked?) (set-flag found? true))
next
)
(verify found?)
$1
(verify not-friend?)
(set-flag found? false)
add
))
Where is the error?
Your proposed solution, I guess, it is very cpu consuming, because for each move we have to scan all the board. In my last post I was talking about a neutral player that check if the king is in check before each player (and move a dummy-piece if it is so). What do you thing about it?
Anyhow, I have tried to implement your solution but I had a parse error. I defined the move in this way:
(define shift1-check (
START
(while (on-board? next) (if (and (piece? King) friend?) (verify attacked?) (set-flag found? true))
next
)
(verify found?)
$1
(verify not-friend?)
(set-flag found? false)
add
))
Where is the error?
Matteo, sorry for the belated reply. Of course, you must jump out of the loop as soon as you find the king, so you should write:
(while (and (on-board? next) (not-flag? found))...
The parse error is that you write (verify found?). It should be (verify (flag? found)).
/Mats
(while (and (on-board? next) (not-flag? found))...
The parse error is that you write (verify found?). It should be (verify (flag? found)).
/Mats
Mats, thanks. This solves part of the problem. The whole solution is this one:
(define shift1-check (
(set-flag found false)
START
(while (and (on-board? next) (not-flag? found))
(if (and (piece? King) friend?) (verify attacked?) (set-flag found true))
next
) (verify (flag? found))
back
$1
(verify not-friend?)
(set-flag found? false)
add
))
But, the problem is the huge computational complexity of this implementation. It takes some seconds just to calculate the movable pieces. So this solution is not a practical one.
I have tried to implement a solution with a dummy piece that check whether there is an attacked king, if so move a dummy piece. But it seems I don't know some basic concepts.
At the end of each players' moves, I want the dummy player do that:
- clear the position "king-check"
- scan all the boar
- if the king is attacked, then create a marker in position "king-check"
This is what I have implemented:
(define checking
(
cascade
(capture king-check)
add
(set-flag found false)
START
(while (and (on-board? next) (not-flag? found))
(if (and (piece? King) friend?) (verify attacked?) (set-flag found true))
next
)
(verify (flag? found))
back
(create Marker king-check)
)
)
Unlucky this solution doesn't work. Any ideas? :-)
(define shift1-check (
(set-flag found false)
START
(while (and (on-board? next) (not-flag? found))
(if (and (piece? King) friend?) (verify attacked?) (set-flag found true))
next
) (verify (flag? found))
back
$1
(verify not-friend?)
(set-flag found? false)
add
))
But, the problem is the huge computational complexity of this implementation. It takes some seconds just to calculate the movable pieces. So this solution is not a practical one.
I have tried to implement a solution with a dummy piece that check whether there is an attacked king, if so move a dummy piece. But it seems I don't know some basic concepts.
At the end of each players' moves, I want the dummy player do that:
- clear the position "king-check"
- scan all the boar
- if the king is attacked, then create a marker in position "king-check"
This is what I have implemented:
(define checking
(
cascade
(capture king-check)
add
(set-flag found false)
START
(while (and (on-board? next) (not-flag? found))
(if (and (piece? King) friend?) (verify attacked?) (set-flag found true))
next
)
(verify (flag? found))
back
(create Marker king-check)
)
)
Unlucky this solution doesn't work. Any ideas? :-)
Matteo, it is the search tree which is the heavy operation. The problem is here that the king search is involved in the search tree, which has thousands of branches. You should consider changing the rules a bit to make it easier to program, until you know how to do it. Anyway, these 'create' and 'capture' commands do nothing if not followed by an 'add'. After the last 'create' there is no 'add', so it won't happen. You probably only need an 'add' in the last position, and that cascade seems superfluous(?). You don't need to 'capture' the king-check piece. It is superfluous. You could also use 'change-type' instead of 'create', to avoid a capture sound. /Mats
Mats, with "add" the program still doesn't work. Anyway, I'm following your advice and simplify the rules. ;-)
Here the updated version of the game, with a new name too. :-)
PawnTrap
by Matteo Perlini
You can download the zillions file here: PawnTrap.
All rules of Orthodox Chess (FIDE Chess) apply, but with the following modifications:
1. if possible, it is mandatory to capture an enemy Pawn;
2. Bishops, rooks and queens can move just up to 3 squares;
3. stalemate is a loss for the stalemated opponent.
Let me know your feedbacks please. ;-)
You can download the zillions file here: PawnTrap.
All rules of Orthodox Chess (FIDE Chess) apply, but with the following modifications:
1. if possible, it is mandatory to capture an enemy Pawn;
2. Bishops, rooks and queens can move just up to 3 squares;
3. stalemate is a loss for the stalemated opponent.
Let me know your feedbacks please. ;-)
Matteo, there are some curios effects with your PawnTrap.zrf. 1) King may move into check if there are possibilities to capture a pawn. Example: 1.d4 Nf6 2.e4 Nxe4 3.Kd2?! Nxf2 2) No defense against checks if there are possibilities to capture a pawn. Example: 1.d4 e6 2.b3 Be7 3.f3 g5 4.Nh3 Bb4# "Checkmate: Black wins!" I assume this is not intended by you but a weakness of your zrf.
Hi Alfred, thanks for taking the time to test my game. 1) In that situation you can move the King in d2 because d2 is not under attack of the Knight. For each piece, if a piece can capture a Pawn, that piece have to capture that Pawn. So, in your situation the King is not moving into check. 2) This is a problem. If you read the previous messages in this topic you see I have tried to solve this problem, without success. I'm not able to implement the rule "if the King is in check, capturing a Pawn is no more mandatory". If you can solve this problem I would be grateful to you. :-) Anyway, I have found without this rule the game is playable as well.
19 comments displayed
Permalink to the exact comments currently displayed.
What if pawns, although military weak men, were rich merchants? Of course, they would have a lot of money with them, so they would be a delicious booty.
This is the thematic justification for the following modification of the original chess rule: if possible, it is mandatory to capture an enemy pawn.
This little rule alters the gameplay deeply. Each move is more important and has much more consequences. The game is more positional and players are more pushed to look ahead.
You can download the zillions file here: PawnTrap.
All rules of Orthodox Chess (FIDE Chess) apply, but with the following modifications:
1. if possible, it is mandatory to capture an enemy Pawn;
2. Bishops, rooks and queen can move just up to 3 squares;
3. stalemate is a loss for the stalemated opponent.
Let me know your feedbacks please. :-)
EDIT: name and rules updated [06DIC2012]