| Author | Message | ||
| Mats W (Kålroten)
|
The game HexQuint, where I introduce simultaneous dropping and capture, is now downloadable from my homepage. It seems to work, probably due to the hexagonal board. If it's a good game I cannot judge, however. I already have new versions of Quad and HopQuad. I finally realized that the initial position is won for white (I think). So I introduce the rule that white must drop the second stone on the rim. Mats | ||
| Greg Schmidt (Gschmidt)
|
HexQuint - Nice game. Zillions plays it well too.  | ||
| Mats W (Kålroten)
|
There is however the problem that the engine thinks it can achieve a draw by intercepting a threatening five-in-a-row by dropping a piece. And when this piece is captured it drops a new piece on the same square which is captured again, and so on. He thinks it will become a draw by repetition this way. But he only loses pieces because one needn't go all the way. However, by changing *repetition* to loss-condition it seems like this problem is removed and it plays stronger I believe. You needn't download the program again. Just change the draw-condition to loss-condition for repetition. | ||
| Mats W (Kålroten)
|
I made an important discovery. One can change the playing style of the engine by adding the same moves again in the *moves* command. In HexQuint.zrf I have done the following: (moves (move-type cust_type) (interception-shift n n ne nw se sw ) (interception-shift s s ne nw se sw ) (interception-shift ne ne s n nw se) (interception-shift nw nw s n ne sw ) (interception-shift se se s n ne sw) (interception-shift sw sw s n nw se) ;same move commands are repeated to tweak ;the engine to regard pieces as more valuable (interception-shift n n ne nw se sw ) (interception-shift s s ne nw se sw ) (interception-shift ne ne s n nw se) (interception-shift nw nw s n ne sw ) (interception-shift se se s n ne sw) (interception-shift sw sw s n nw se) (interception-shift n n ne nw se sw ) (interception-shift s s ne nw se sw ) (interception-shift ne ne s n nw se) (interception-shift nw nw s n ne sw ) (interception-shift se se s n ne sw) (interception-shift sw sw s n nw se) (interception-shift sw sw s n nw se) (interception-shift se se s n ne sw) ) ) As you see the same interception-shifts are repeated. On account of this the engine thinks that the pieces are more valuable. Thus he begins to play more aggressively and tries to capture pieces instead of, as before, passively allowing the opponent to capture his own pieces. I could not use the method of adding "(add)" in the moves command because that would cause the engine to regard 'pass' moves. It doesn't matter if one disallows 'pass move' in the options command. Usually one can solve this problem by adding the moves to a 'move-priorities'. However, this is not possible in this case because two different move types (drops and interception-shift) occur interchangeably. One should not double the drops moves, however. That gives the program hickups, it seems. The difference is remarkable. HexQuint now plays much better than before.This method can be used in other programs as well. I am now testing this method for Kaufmann's "Descent Chess" and it works remarkably well. The program starts to play fine. Earlier it played like an absolute fool. Frölische Weinachten und ein glückliches Neues Jahr! Mats | ||
| Greg Schmidt (Gschmidt)
|
I think others have discovered this as well. All you really have to do is to place more "add"'s in the move as opposed to replicating the entire move. I assume the latter approach ends up being more efficient with respect to the Zillions engine. Take a look at the following topic under "Designing Games for Zillions" Topic: Capturing friendly pieces = good, not bad! Read the posts by Keith Carter there. -- Greg | ||
| Mats W (Kålroten)
|
I haven't read Carter's posts yet but the problem is that if I simply put "adds" in the move then the engine considers "pass" moves. As pass is not allowed in this game, I cannot use this method. Nor can I use "move-priorities" to circumvent this problem as I cannot differentiate "drops" from "interception-shifts". In HexQuint these two moves occur intercahangeably. I didn't give this tweaking work much thought, but I saw no other solution than duplicating the moves. Mats | ||
| Greg Schmidt (Gschmidt)
|
Interesting, I haven't encountered the problem with unwanted "pass" moves being considered. I wonder what causes that. -- Greg | ||
| Mats W (Kålroten)
|
Supposedly, when you simply write (add), this means that you add a move in no direction (that is, a pass), whereas, if you write (add n), then you add a real move, in this case to the north. In Kaufmann's "Battle" (Stratego) he uses (add) to tweak piece value. But as all drops occur before normal piece movement he can insert this statement: (move-priorities drop-move normal-move). So in this case the program won't consider pass, only the real moves. But if there is no priority between move-types, then you can't use (add), if pass should not be allowed. Mats | ||
| Greg Schmidt (Gschmidt)
|
Looking back at how I've used multiple "add"'s, it's always been with specialized bonus" pieces that have zero mobility so I think that's why I didn't see the problem. -- Greg |