| Author |
Message |
Michael Rouse (Snarfangel)
| | Posted on Monday, April 16, 2001 - 10:05 pm: | |
A couple of years ago I came up with a hexagonal chess variant called Hexmate where the King had the combined movement of knight, bishop, and rook (see www.chessvariants.com). This works well through the midgame, but after playing several games, I came to the conclusion this gives the king too much mobility in the endgame -- you need an overwhelming advantage to checkmate.
The solution I came up with was to give the king an "inherent" movement of one hex in any direction, and add knight, bishop, and/or rook movement as long as there was at least one piece with the same color and movement remaining on the board. If you lost all of your bishops, paladins, and queens, for example, your king would no longer be able to move as a bishop (unless a pawn were promoted to an appropriate piece).
Enough of the background! (grin) There is a ZRF on the old game, with the king's movement as follows:
(piece
(name King)
(help "King: R + B + N")
(description "King\A King can move as a combination of Rook, Bishop and Knight, making it the most powerful piece on board. However, with its checkmating, the game is over.")
(image White "images\giant\wking.bmp" Black "images\giant\bking.bmp")
(moves
(R-moves)
(B-moves)
(N-moves)
My question is, how can I change this so that the king's movements depend on which pieces he has left? (I didn't do the original ZRF, and I'm not much of a programmer. I can, however, attach the ZRF to e-mail if the entire file is necessary to figure out how to code the king's movement.)
Thanks!
Mike Rouse
mrouse@cdsnet.net |
Dan Troyka (Dtroyka)
| | Posted on Tuesday, April 17, 2001 - 7:27 am: | |
I doubt there's a simple solution to this problem. You could define a dummy piece on a dummy square (one for each player) with several piece attributes: 5-bishops true, 4-bishops false, 3-bishops false, and so on to 0-bishops false, then 5-rooks true, 4-rooks false, and so on to 0-rooks false, and 2-knights true, 1-knight false, 0-knight false. The starting true attribute for bishops, for example, would depend on the number of pieces on the board at the start of the game that can move like a bishop (I'm assuming 1 queen, 2 paladins, 2 bishops). When you capture an opponent piece that can move like a bishop, the attribute of the dummy piece would be adjusted accordingly (to 4-bishops and so on). When the opponent King moves, it tests the attributes of the dummy piece. If 0-bishops is true, then it cannot move like a bishop. If a piece is promoted, then the attributes are revised upwards. (You would probably need a 6-bishops attribute for the unlikely situation where a pawn is promoted to a bishop-moving piece when no bishop-moving pieces have been captured.) There can only be 32 attributes in a game, but I think you could stay under the limit.
An alternative approach is to scan the board before any king-move to test each square for whether a friendly bishop-moving piece is on it. If such a piece is encountered, the king can move like a bishop. If not, it cannot. This would probably be less efficient from an AI perspective.
Feel free to e-mail me at dtroyka@justice.com if you would like more substantive help.
Good luck! |
Dan Troyka (Dtroyka)
| | Posted on Tuesday, April 17, 2001 - 2:59 pm: | |
By the way, an alternative approach to the endgame problem would be to make "baring" a loss. This happens when the King is a player's last piece on the board. Baring has been around for centuries as an alternative way to lose chess-type games. You could code this simply by adding (loss-condition (White Black) (pieces-remaining 1)) to the already existing script. It would probably make for a very different endgame, where the object is less checkmate and more capturing other pieces, but it could prove interesting. |
Michael Rouse (Snarfangel)
| | Posted on Wednesday, April 18, 2001 - 1:40 am: | |
I like the idea of making "baring" a loss, and I think I'll add it. It makes sense that a king plus another piece (or pieces) should win over a king by itself. You might not have the cool "two knights and a king versus a king" checkmates (simply because the game would be over before then), but it would cut out some of the tedious "chase the losing king into the corner in fifty moves" type endings.
I still like the idea of basing the king's movement on the remaining pieces of the same color. It would make checkmate as well as baring a possibility in the endgame, and it would add more strategy in capturing and in pawn promotion. I'm looking at the ZRF's in some of the chess variants that use chameleons and mimics to see if there are any that base the movement options on what pieces you have left.
Thanks again for reminding me about baring! I never really thought about it, but it's a good way to for a win rather than a draw. Once I figure out how to adjust the king's moves based on the other major pieces of the same color, I'll have to see if I can come up with a kind of "Fischer Random" version for Hexagonal Chess (grin). |
Peter Aronson (Peteraronson)
| | Posted on Sunday, April 22, 2001 - 7:49 pm: | |
There's another approach to detecting the presence or absence of pieces with various types of moves to use in controlling the King's movement. However, it depends on using a feature (fairly widely used) that is not officially supported by Zillions of Games: using flags between move generation blocks.
Here's how you do it. You define three different move types with the following priorities:
(move-priorities initialize-move set-move normal-move)
All of your existing move blocks are assigned to the normal-move move-type by making the following statement the first statement in every moves block:
(move-type normal-move)
Then, at the top of the King's movement block (before the above statement), you add:
(move-type initialize-move)
((set-flag knight-move-ok? false)
(set-flag bishop-move-ok? false)
(set-flag rook-move-ok? false)
)
This initializes all of the movement flags to false. It will always get run first because initialize-move has the highest priority (and you always have a King), and it will never actually generate a move because it doesn't have an add statement.
Now we need to initialize the movements to true where you have a piece with the proper move types still in the game. At the beginning of the Queen's movement block we add:
(move-type set-move)
((set-flag bishop-move-ok? true)
(set-flag rook-move-ok? true)
)
This'll get executed as long as you have a Queen in play, and will set the bishop and rook moving flags to true, since it is higher priority than any move with an add. Similarly, for the Duke you add:
(move-type set-move)
((set-flag knight-move-ok? true)
(set-flag rook-move-ok? true)
)
And for the Paladin:
(move-type set-move)
((set-flag knight-move-ok? true)
(set-flag bishop-move-ok? true)
)
For the Rooks:
(move-type set-move)
((set-flag rook-move-ok? true)
)
For the Bishop:
(move-type set-move)
((set-flag bishop-move-ok? true)
)
And for the Knight:
(move-type set-move)
((set-flag rook-move-ok? true)
)
Finally. You create special versions of the movement macros for the King (a Knight move macro, a Bishop move macro and a Rook move macro) and in each one add an appropriate test:
(verify (flag? knight-move-ok?))
This should require the minimum amount of processing time and bookkeeping. However, Zillions isn't guaranteed to support it in the future. |
Karl Scherer (Karl)
| | Posted on Monday, April 23, 2001 - 5:04 am: | |
Of course instead of using flags or attributes
to count numbers of pieces you can also
store counters in off-board positions.
(positions with negative coordinates)
I have used this a lot in my games. |
|