Check out Atomic Chess, our featured variant for November, 2024.


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

Comments/Ratings for a Single Item

Earlier Reverse Order Later
PawnX: new modest vatiant[Subject Thread] [Add Response]
Matteo Perlini wrote on Tue, Nov 6, 2012 08:45 PM UTC:
PawnTrap
by Matteo Perlini


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.


Rules


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]

Alfred Pfeiffer wrote on Wed, Nov 7, 2012 11:43 PM UTC:
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?

Matteo Perlini wrote on Thu, Nov 8, 2012 12:51 AM UTC:
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.

Matteo Perlini wrote on Tue, Nov 13, 2012 02:20 PM UTC:
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?

M Winther wrote on Thu, Nov 15, 2012 04:54 PM UTC:
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

Matteo Perlini wrote on Mon, Nov 19, 2012 09:58 AM UTC:
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.

M Winther wrote on Tue, Nov 20, 2012 06:52 AM UTC:
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

Matteo Perlini wrote on Tue, Nov 20, 2012 12:34 PM UTC:
**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.

M Winther wrote on Tue, Nov 20, 2012 05:36 PM UTC:
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

Matteo Perlini wrote on Mon, Nov 26, 2012 10:24 AM UTC:
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:

(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?

M Winther wrote on Mon, Nov 26, 2012 03:06 PM UTC:
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

Matteo Perlini wrote on Fri, Nov 30, 2012 02:36 PM UTC:
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?


M Winther wrote on Tue, Dec 4, 2012 08:23 AM UTC:
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

Matteo Perlini wrote on Tue, Dec 4, 2012 08:40 PM UTC:
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? :-)

M Winther wrote on Wed, Dec 5, 2012 04:33 PM UTC:
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

Matteo Perlini wrote on Thu, Dec 6, 2012 02:00 PM UTC:
Mats, with "add" the program still doesn't work. Anyway, I'm following
your advice and simplify the rules. ;-)

Matteo Perlini wrote on Thu, Dec 6, 2012 02:14 PM UTC:
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. ;-)

Alfred Pfeiffer wrote on Sun, Dec 23, 2012 11:42 PM UTC:
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.

Matteo Perlini wrote on Mon, Dec 24, 2012 02:01 PM UTC:
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

Earlier Reverse Order Later

Permalink to the exact comments currently displayed.