| Author |
Message |
mohamed el mokhtar messaoudi (Dumbguy)
| | Posted on Thursday, March 11, 2004 - 2:40 pm: | |
Hi.
I have a game for two players, Blue and Red. Each player has an off-board zone called a Storehouse, with eight cells ( B1 to B8 for Blue and R1 to R8 for Red ),linked thus:
( links Next (BlueStart B1) (B1 B2) ... (B7 B8) (B8 End)
(RedStart R1) ( R1 R2) ... (R7 R8) (R8 End))
BlueStart, RedStart and End are dummy positions. Part of the game is for a player, say Blue, to go from BlueStart in the Next direction till he encounters a free cell, where he must put a Checker, as instructed below:
(if (AmBlue?) BlueStart else RedStart)
Next
(while (and empty? (not-position? End) ) Next)
(opposite Next)
; I may be wrong, but I think there is no need to check actual player's
: whereabouts, since either the current cell is occupied and the player
; must step back to add a Checker, or the position is End, which is
; empty anyway (as set by game rules), and the player again acts the
; same. Hence:
(add Checker)
Problem is, when the Storehouse of the current player, say Blue, is entirely void, a Red Checker is put on the last cell of the opponent's Storehouse (that's R8), whatever the state (empty or otherwise) of R8. There is no instruction for a player to set foot in his opponent's Storehouse or manipulate his tokens, let alone play out of turn.
I can circumvent this by additional conditions tests, but why does it happen? Quite a lot of ZOG games use similar zones, with similar links and dummy positions holding identical names (End in my case), so it could'nt be a case of confusing names, could it?
My game (very simle, very linear) uses the same moves as in Draughts, so I am using the same code from various ZRF's.But apart from the problem just described, here is one other glitch I can not pinpoint:
When a Checker or a King faces an enemy King, some action (say Action2) on the latter must be taken after jumping over it. Instead, ZOG presents me with a pop-up message requesting of me to make one of two moves:
-a- jump over the enemy King and perform Action2 as set by my rules (along with scanning Storehouse etc., see above), or
-b- merely leaping over it,leaving it unscathed.
Here is the code for Checker (code for King is slightly different, but just as straightforward):
(define CheckerJump
($1
(verify (and enemy? (empty? $1) ))
(if (piece? Checker) (Action1) $1 (CheckerJumpAdd)
else
mark
(if (AmBlue?) BlueStart else RedStart)
Next
(while (and empty?(not-position? End)) Next )
(opposite Next) (add Checker)
back
(Action2) $2 (CheckerJumpAdd) )
Action1 and Action2 do not involve any fancy cascade's, or from/to sommersaults I could never code anyway. I have other minor (irritating) problems, but these will do for now.So, any clues?
Thanks for any help. |
mohamed el mokhtar messaoudi (Dumbguy)
| | Posted on Friday, March 12, 2004 - 12:57 pm: | |
I beg your pardon, all add's in my previous post should read "create", and $2 should read $1.Solves nothing, nevertheless. |
Sean Duggan (Dream)
| | Posted on Wednesday, March 17, 2004 - 11:18 pm: | |
Well, for the storehouse, might it be because both positions hold an End? Doing an opposite of Next from End could take you to either R8 or B8.
As for the doubled move, could it be because you call (CheckerJumpAdd) twice? |
Jeff Mallett (Jeffm)
| | Posted on Monday, March 22, 2004 - 5:34 pm: | |
I'd agree with Dream on your first problem.
With your second problem, I don't know, because I don't see the problem in the code you gave. The popup message does indicate that you are generating two moves to the same square. For all I know, this could be happening in a separate move block. |
mohamed el mokhtar messaoudi (Dumbguy)
| | Posted on Wednesday, April 07, 2004 - 2:31 pm: | |
Sean and Jeff, thanks to you both.It's been some time since I last checked for an answer, as I somehow managed to solve both problems. Meanwhile, I discovered my game concept has been reinvented many times over, so I am adding more moves and testing variants. One move type I'd like to implement consists in this: two friendly Checkers are sandwitching an opponent one. I would like the threesome to move one step to an empty cell (that is, the opponent Checker is carried away by the two friendly ones surrounding it), thus:
(define CheckerShift3
($1
(verify (and
enemy?
(piece? Checker)
(friend? $1)
(piece? Checker $1)
(empty? $2))) ;end verify
$2
(change-owner (opposite $1))
(change-owner (opposite $2))
add )) ;end macro
$1 denotes one step in a certain direction, say "north", and $2 two steps in the same direction. All directions are correctly stated in the board definitions. This macro does not work, in the sense that when the move is finished all three Checkers become friendly ones.I must be overlooking the obvious, as always, so if someone sees it..Some games seem to be featuring some similar move types, but I just can't yet grasp the intricacies of the macros involved.
Thanks for any help. |
Sean Duggan (Dream)
| | Posted on Wednesday, April 07, 2004 - 4:14 pm: | |
From the documentation:
Quote:The change-owner keyword makes the piece so that it’s owned by the player who is moving, in effect "taking over" the piece. flip, on the other hand, cycles through the players, changing the owner to the "next" one in its cycle. In games with only two players, this is equivalent to swapping the owner, i.e. "flipping" the piece.
Try using a flip instead. It works for me. |
mohamed el mokhtar messaoudi (Dumbguy)
| | Posted on Wednesday, May 05, 2004 - 3:37 pm: | |
Hi. Thanks,Sean. That did it. I discarded flip's because earlier versions of the game would not accept them,whereas it works now that all change-owner's are reversed back to flip's. ?. Still, I am not satisfied with my code (apart from a couple macros shamelessly stolen from other zrf's),as ZOG sometimes passes its turn when it should not.
I am shipping the game, since it is mostly playable.It's called MuchAdo (a fitting name).If ever it is accepted for publication, would you please consider revising the code?
Cheers and thanks again. |
Sean Duggan (Dream)
| | Posted on Sunday, May 09, 2004 - 12:01 am: | |
^_^ I'd be glad to look it over. Be careful on the publication if you are using other peoples' code though. |
|