| Author |
Message |
robert mate (Elcomadreja2)
| | Posted on Sunday, May 15, 2005 - 1:13 am: | |
I don't know how many of you know about this board game, but zillions appears to be a silly player so far. Right now all that's implemented is dropping pieces and sliding them in.
The losing condition is having all your pieces on the board. Since there is no way to get your pieces back off the board, the first player is going to win automatically. These rules are enforced properly, but zillions always thinks things are even, or even that it's not doing well as the second player... until that last piece of mine comes down. |
robert mate (Elcomadreja2)
| | Posted on Sunday, May 15, 2005 - 9:35 am: | |
Now that I think about it... do captured pieces go to the same pool as the pieces that drop in? |
Greg Schmidt (Gschmidt)
| | Posted on Sunday, May 15, 2005 - 11:37 am: | |
Only if you use the following statement in your game:
(option "recycle captures" true)
Because the default value for this option is false.
Good luck!
-- Greg |
robert mate (Elcomadreja2)
| | Posted on Sunday, May 15, 2005 - 11:59 am: | |
oh wow, how in the world am I going to code this? some of the piece get captured, some get returned to your hand.
Also, I've got some problems cascading.
(define shove (if(not empty?)
cascade
from $1
)
)
(define tomid (if (on-board? $1)
$1
(if(not-in-zone? newdrop)
(shove)
(shove)
(shove)
(shove)
(shove)
(shove)
(if(not-in-zone? newdrop)
add
)
)
back
)
)
The idea here is to push all the pieces over that are in line, but nothing can be pushed off the side of the board.
This seems to work most of the time, but never for the ne & se corners of the board, I should get 2 choices of where to move the piece,but instead I get 2 choices of where to move pieces further down the chain.
since the order of directions checked could matter, here's that bit of code.
(if (in-zone? newdrop)
mark
(tomid e)
(tomid w)
(tomid ne)
(tomid nw)
(tomid se)
(tomid sw)
) |
robert mate (Elcomadreja2)
| | Posted on Sunday, May 15, 2005 - 2:24 pm: | |
after the (option "discard cascades" true) line, this worked the way i expected it to. So all the pieces move around as they are supposed to. I'm not sure how to add the other rule in just now (recognize four in a row, some get captured, some returned to hand)
What I noticed though, is after I defined the moves correctly, zillions now sees that automatic win when it's 6 moves away. But it counts the drop and move as two different things, so, it really only sees it 3 moves away.
I think zillions will play better if I combine those 2 things into a single drop command. Got no ideas how to do that however. |
L. Lynn Smith (Interrupt27)
| | Posted on Tuesday, May 17, 2005 - 4:00 am: | |
My basic coding idea was to have a field full of null pieces which actually never move but are change-typed by an off-field piece(each player has one and it doesn't show up on the field).
This off-field piece would adjust the line accordingly, and decrement bar graphs for each player accordingly. A neutral player would make the capture adjustments to the field.
This would all be done as few moves as possible(no more than 4 each turn), not to impact the Zillions engine too harshly.
I had not worked out the actual dynamics of the win/loss conditions. I need to take some time and re-construct the original code.
Of course, all of the above is subject to adjustment with play-testing. |
L. Lynn Smith (Interrupt27)
| | Posted on Tuesday, May 17, 2005 - 5:13 am: | |
Upon further reflection, those moves within the turn were a little more complicated. Players needed to capture their own pieces.
Also the opponent was not allowed to make a move until the player has made a placement AND all possible captures. Those four-in-a-row GIPF-pieces offer a nice condition. There needed to be a form of passing to handle this(I've done something similar in Gle'x, a really complicated code.)
I can see forced passing and dummy positions galore. This game will definitely take some tweaking to get to play half-way decently. |
robert mate (Elcomadreja2)
| | Posted on Tuesday, May 17, 2005 - 9:35 pm: | |
Yeah, I was thinking I would have to break down and come up with some algrithm to scan the board to check for 4 in a rows (the go script does something like this to see when things get captured)
I thought about a netural player clearing out the 4 in a rows too... the problem is that sometimes the player has a choice of which one(s) to remove. This happens when things cris-cross.
My win/loss condition worked well enough, but it appears as though I need 2 places for pieces, one visible set on a sideboard (in hand), and on not visible (captured).
I did it this way (basic game)... I put 16 pieces into the availble pieces rather than 15, with the condition that a player losses immediately if all 16 pieces are on the board. |
robert mate (Elcomadreja2)
| | Posted on Tuesday, May 17, 2005 - 9:41 pm: | |
oh, but I guess if pieces can be captured you would have to subract captured pieces from the 16. |
L. Lynn Smith (Interrupt27)
| | Posted on Tuesday, May 24, 2005 - 12:37 pm: | |
After a few sleepless nights of re-constructing a previous attempt at this game, I came to point which prevented my completion. It has to do with the Gipf-piece capture dynamics.
For example: Let's suppose that there is a nice line of seven white Gipf-pieces in the e-file. Improbable, unlikely but potential. The white player now has the option of removing one, two, three, four, five, six, seven or none. And these numbers can be in a variety of combinations. If I am able to code all the potentials, the pop-up menu would be huge and cumbersome.
I am open to suggestions on how to handle this section of the code.
Maybe a series of partial moves where the player selects the Gipf-pieces to be removed. But this will not help the engine, it will burden the depth search astronomically. |
Karl Scherer (Karl)
| | Posted on Friday, October 14, 2005 - 3:52 pm: | |
Does it really mater whether the nodes in the search tree are positioned horizontally (some powerful moves) or vertically (moves split into many partial ones)?
I always thought it is the number of nodes (which are independent of the program, but only depend on the game rules) between the root and the target position which determine the quality of the search results. The engine has to work through all these cases anyway. |
L. Lynn Smith (Interrupt27)
| | Posted on Saturday, October 15, 2005 - 4:31 am: | |
With the Strength set at maximum and Time at Infinite, the effect might seem the same(but there can be subtle differences). There is a difference in the Strength vs. Time curve of each move generation. Given the same amount of Time, these will eventually reach a point of equalibrium. But with equal Strength(search depth), the partial move will impact the engine's AI as it may not actually be able to see past one player's actual move and therefore cripple its potential response. |
L. Lynn Smith (Interrupt27)
| | Posted on Saturday, October 15, 2005 - 7:39 am: | |
Please forgive my mis-spelling of 'equilibrium'. I know that there are a few lonely English scholars who cringe at such errata and often feel it is necessary to correct the offender with long boring dissertations about how un-professional it is for a person to make such. So before anyone prepares to make such an assault, let me now state that I recognize this typo and that I promise to never repeat it. At the least, not un-intentionally. |