| Author |
Message |
Y Dienyddiwr Da (Dienyddiwr)
| | Posted on Thursday, September 07, 2000 - 3:27 pm: | |
make a piece able to capture only if
he is currently being defended.
i have go this to work, but only when he is
being defended by a different kind of piece.
i believe the engine is actually checking
to see if the defender is defended to allow
it to defend.... so it keeps looking for
another piece to the previous piece, which defends the previous piece, and so on, until it runs out, at which point it says nevermind.
any ideas? |
Sean Duggan (Dream)
| | Posted on Friday, September 15, 2000 - 11:25 am: | |
Probably, the easiest way to do this would be to build your own algorithim to check the board and see if a piece is defending
Pseudo-code:
Scan first square
if Pawn, check to see if square is defended, if so, raise flag, end loop.
if Bishop, check to see if square is defended, if so, raise flag, end loop.
if Knight, check to see if square is defended, if so, raise flag, end loop.
Go to next square, continue loop.
Yes, it's messy and hard to port to other games, but it just might work. |
Y Dienyddiwr Da (Dienyddiwr)
| | Posted on Friday, September 15, 2000 - 5:37 pm: | |
Yeah i was thinking of that too.
also thought of a backwards idea.
If this only counts with pieces of the same type,
then i could try having the piece see if IT
is defending anyone, and if it is, in theory, the piece it checked will be defending it back.
I'll check both our ideas out ^,^
(im working on 5 games at once, just recently
got ZoG and i havent stopped pulling out games
i made when i was little =) |
Y Dienyddiwr Da (Dienyddiwr)
| | Posted on Sunday, September 17, 2000 - 10:30 pm: | |
My idea worked, but, i think (like most
of my games =\) the computer has a hard time
with that aspect of the strategy. It doesnt
use this rule to its advantage, and at times,
doesnt even plan with this rule in mind
(leaving helpless pieces in the middle of no
where, advancing pieces where there is no
support) for the most part it works pretty well
though. I have a knack for wigging this program
out =\ (Download nanometer and try the "Free
Radical" variant and you'll see what i mean) |
Malcolm Maynard (Daviim)
| | Posted on Thursday, June 19, 2003 - 1:28 am: | |
Forbid a [chess] piece from mating
Okay, I noticed that the shogi ZRFs do allow you to checkmate by dropping a pawn, which is supposed to be verbotten. I'm also looking at trying to create another [regional] chess variant that forbids certain pieces from checkmating the opposhing king. Any suggestions on how to prevent a particular chess piece from mating the oppossing kingbut also being allowed to check normally too?
~*~ Malcolm ~*~
daviim@yahoo.ca |
Jeff Mallett (Jeffm)
| | Posted on Thursday, June 19, 2003 - 4:31 am: | |
I could use clarification about what you mean by forbidding a piece to checkmate. Suppose that a pawn promotes to a knight, which creates a discovered check with a queen and black is mated. Would it be forbidden by a prohibition on pawns (the piece that moved) or queens (the checking piece)? And what if the knight was checking so it was double-check? What if the promoted knight's check was redundant, e.g. the king is double-checked, but would be fully checkmated by just the queen? (Yes, I can construct such a position.)
These questions all pertain to the meaning relating to chess. In Zillions of course, we have to be able to answer a lot more questions than just these... If you are forbidding the piece that's checking, what if it's checking a different checkmateable piece from the one being checkmated. What if it's checkmating one enemy, but the move is simultaneously checkmating a different enemy with a different piece? If you are forbidding the piece that's moving, does it really have to move or does flipping in place count? Is it okay to checkmate by moving a piece you don't own? Is it only the key move, or any of the cascades? What if it is only one cascade of many and really doesn't have anything to do with why the enemy is checkmated? And so it goes...
The scary thought experiments occur when you realize that if you forbid a piece from mating, the move you are forbidding might be the only move that could have stopped a mate. So, you're defining a mate in the current position based on whether a future position is mate. To find out whether that future position is mate, you have to look at moves to stop the mate, which in turn must be weeded out based on whether they cause mate in future positions. And so it goes... |
Malcolm Maynard (Daviim)
| | Posted on Thursday, June 19, 2003 - 6:15 am: | |
Actually, I wasn't thinking of anything quite that complicated! Neither of these situations are variants of my own -- shogi and another regional variant are what I'm looking at.
These are the following considerations for the two cases I'm thinking of:
1. Promotion is not a factor, as in both cases, promotion isn't possible.
2. The piece in question can move and check the opposing king.
3. The piece in question can not put the opposing king in checkmate, but only by moving.
4. No cascades.
5. No moving of opponent's pieces.
6. No board or zone restrictions.
That should be about it (I hope)...
~*~ daviim ~*~
daviim@yahoo.ca |
Malcolm Maynard (Daviim)
| | Posted on Sunday, June 22, 2003 - 6:58 am: | |
Okay, related to my first question about how to bar a piece in a chess variant from checkmating, but allowing it to check...
Any suggestions on how to check to see if the opposing king is safe to move if your piece puts it in check? The [abstract] logic would be like this:
If NOT (enemy king attacked and squares around it attacked by you)
Then add piece here
Else do NOT add piece here
Just some suggestions on how to check the appropriate square (i.e. where the king is) and the squares around it (where it should be able to move) are all I need. I should be able to figure it out from that point on...
~*~ daviim ~*~ |
Jeff Mallett (Jeffm)
| | Posted on Sunday, June 22, 2003 - 2:09 pm: | |
It's easy to find out whether the squares around the enemy king are attacked in the current position, prior to your proposed move being played. This is done with the attacked? command. However, there is no generalized Zillions command for checking to see whether your move will do something after its played in the definition of the move itself. I think a discussion of the paradoxes this would create is somewhere else in this board.
That being said, it is possible use game-specific knowledge to implement move code that checks to see if a square would be attacked after a move. How hard this is depends on your game. For example, suppose all the pieces in your game move like rooks. First you'd mark the square you intend to move to. Then you'd scan orthogonally outward from the enemy king square and its neighbors, ignoring (hopping over) the "from" square. If you hit a friendly piece or the marked square, an attack has been found. In a chess game, which also has diagonal attacks and knight moves, this is more complicated. |
Malcolm Maynard (Daviim)
| | Posted on Tuesday, June 24, 2003 - 1:39 am: | |
Just curious too about one thing to do with flags.
When you use a [named] flag, does Zillions effectively treat it as a seperate flag for each player? That is, if there's two players and one named flag, would Zillions be keeping track of two flags, one for each player?
~*~ Daviim ~*~ |
Jeff Mallett (Jeffm)
| | Posted on Tuesday, June 24, 2003 - 2:32 am: | |
flags are like temporary variables -- they don't have life-spans outside of a move block. So they aren't really saved for one player, much less two. |
Malcolm Maynard (Daviim)
| | Posted on Tuesday, June 24, 2003 - 4:25 am: | |
Okay... Because I also need to keep track of true or false to a succession of events. Basically "did this happen last turn?" Would there be any point in using flags for that, or would some manner of dummy location and dummy counter be a better way of keeping track of that (for both players)?
~*~ Daviim ~*~ |
Jeff Mallett (Jeffm)
| | Posted on Tuesday, June 24, 2003 - 1:15 pm: | |
Because of their scope, flags can't be used for this. Piece attributes (for example) are changed only when a move is played whereas flags are created/changed only during the move generation process. This is an important distinction to understand.
Use last-to?/Last-from? if appropriate, otherwise use piece attributes of the affected piece if appropriate, otherwise use "dummy" objects. Moves can change piece attributes of dummy pieces or the existence/piece-type of pieces on dummy positions. These changes can be checked for in move code. (If using "dummy" things sounds kludgey, it is, and it's one of my top priorities to obviate it with a better system.) |
Malcolm Maynard (Daviim)
| | Posted on Sunday, June 29, 2003 - 5:48 am: | |
Anyone know how I should go about writing code that does the follwing:
1) change-type in one specific location
2) add piece into the current location, which is not the same as the above.
The code I've got just stops short of the piece that I want it to be able to capture.
Would something like add-partial be needed here?
~*~ Daviim ~*~ |
Jeff Mallett (Jeffm)
| | Posted on Monday, June 30, 2003 - 2:36 am: | |
You don't need an add-partial for this. Your move should just do the change-type where it wants to, go to the destination square, and do the add. From what you've said, it should be straight-forward, so there's probably just some little thing wrong in your code. If you can't figure out, maybe you should post the relevant code snippet here so the code vultures can devour it. |
Malcolm Maynard (Daviim)
| | Posted on Monday, June 30, 2003 - 7:25 am: | |
Actually, I think I might have messed up the logic statements before the change-type and add statements. What it should be is something along the lines of:
(
; long winded logic statements here, which
; were probably wrong
(change-type marker <dummy-square>)
add
)
Now, that should work, right?
~*~ Daviim ~*~ |
Jeff Mallett (Jeffm)
| | Posted on Monday, June 30, 2003 - 1:01 pm: | |
yes |
Malcolm Maynard (Daviim)
| | Posted on Monday, June 30, 2003 - 1:02 pm: | |
AHA!
Or, as good old Baldrick would say: "M'Lord, I have a cunning plan!"
The thing is I was getting nowhere fast with this marker and dummy pieces business. Then something occurred to me; why not just change the type of enemy piece during your turn and use victory/draw/loss conditions based on that.
What I am thinking of is having, say a Pawn attack a king. It changes it to a different kind of king as part of putting it in check.
So, anyway, would code something along these lines work?
(if (and (enemy $1) (king $1))
(create Black king-Willy $1)
add
What I'm hoping to make a chess variant where checkmate can be a draw, not a win or loss, depending on what piece checkmates the enemy king...
~*~ Daviim ~*~ |
|