| Author |
Message |
Matthew Burke (Morat)
| | Posted on Friday, December 20, 2002 - 8:17 pm: | |
I am trying to put together a zrf for a game by Dave Boll which I'm calling (for lack of a better name) Boll's Game.
The darned thing works correctly, sometimes. And I'm not having a lot of luck figuring out why. I would appreciate it if someone else could take a look and see if they spot the problem.
The file is available at http://zog.bluedino.net. Rules for the game are included in the file. Note that it's got win conditions that require ZoG 2.0, but I've got some 1.x compatible conditions in their that you could uncomment (and comment out the 2.0 conditions).
Thanks! |
Dan Troyka (Dtroyka)
| | Posted on Friday, December 20, 2002 - 11:14 pm: | |
Could you be more specific about the problem? I looked briefly at the game rules and code and identified one potential problem. If the move logic for an NRook moves one space n, the test (if (piece? NRook s) will return true because the square of origin is considered still occupied by the NRook. This means that the logic will detect an adjacent pieces of the same type even though there is only one piece, and flipping will occur. This problem will happen only when a piece moves one square. Flipping will occur in such cases because the square of origin is adjacent and considered occupied by an identical piece.
To solve this problem you should modify the code to treat the square of origin as always empty. Probably the easiest way to do this is to never check the square in the direction from which a piece came, because that position can never be occupied. |
Matthew Burke (Morat)
| | Posted on Monday, December 23, 2002 - 11:36 am: | |
Dan,
thanks for the pointers. I've made the change you suggest and, I think, it's working better. If I'm following correctly, I also fixed the (if (piece? NRook) ... etc. because the square moved to is not occupied yet until the move has made. Yes? I deal with this by just placing an appropriate (set-flag piecetype true) in each of the move macros.
Still not quite there yet. I can't be more specific because I haven't yet found a consistent pattern to the problem. Basically sometimes the piece types don't flip when they are supposed to. Even odder, occasionally you can move a piece to a square that has no other adjacent pieces and it flips anyway.
I wish I had a source-code debugger! I think the next thing I'll try is to put some additional squares off to the side and create TruePiece and FalsePiece pieces. Then I can inspect the values of the flags by having the appropriate type piece placed on an appropriate square.
Any other thoughts, hints, etc. appreciated. |
Matthew Burke (Morat)
| | Posted on Monday, December 23, 2002 - 12:13 pm: | |
Well, let me follow up my own post. I've added code that lets me see the values of the flags each turn and from that I've determined that the flags aren't being set correctly (or, if you'd like, I don't have a proper idea of how zillions code works).
I think the following is happening: suppose I move a piece 3 squares. The flags are reset and then we do a while loop with an add in it. At the first step, the adjacent cells are checked, flags set, and the add performed. Then we move to the next step, ditto. But the flags weren't reset! Same for the third step.
Now I need to figure out how best to cope with this. |
Dan Troyka (Dtroyka)
| | Posted on Thursday, December 26, 2002 - 4:55 pm: | |
The problem could be related to the tests that take the form (if (piece? NRook) (set-flag neutral-p true)) . These will always return false because the space moved to is considered empty. To get around this you could use flags at the beginning of the move -- on the start square -- to determine whether the piece being moved is an NRook, WRook, or BRook, then use those flags in the mutate macro. |
Matthew Burke (Morat)
| | Posted on Thursday, December 26, 2002 - 6:07 pm: | |
Yes, that's what I did to finally get it working. Now one last problem to solve---the loss-condition isn't working out correctly.
I'm starting a new thread for that since it's essentially a different topic. |
|