| Author |
Message |
Patrick S. Duff (Pduff)
| | Posted on Saturday, August 19, 2000 - 3:13 am: | |
Instead of just "(open <filename>)", add support for "(open <filename> <variant>)".
"(previous-move? <move>)": as in "(previous-move? flip)" or "(previous-move? drop)" or "(previous-move? castle)". In my Reversi variant, I need to know whether a particular position's piece was dropped or flipped on the previous move. There are several kludgy ways of tracking this now, but this is nicer. "(previous-capture?)" and "(previous-capture? <piece>)" would return true if the previous move was a capture.
"(hex ...)": Similar in function to "(grid ...)".
"<position-conditions>": add support for things like "(row? 3)" and "(column? a)".
Use "(value <position>)" and "(value <piece>)" to assign numeric values. If not specified, each value is 1, as in the current "count-condition" implementation. Otherwise, "count-condition" would add up the piece values for all pieces remaining, or the position values for all positions occupied by a player's pieces.
"(score-plus <points>)" and "(score-minus <points>)" for use in move definitions. The "score" goal condition fires when score hits a specified high or low target, either from "score-plus" and "score-minus", or "count-condition". "score-remaining" could work like the current "pieces-remaining".
"(free-turn <moves>)" would be the opposite of "(pass-turn)". Player could use one of his free moves immediately following his turn, whenever they choose.
"(move-number? <number>)" would return true if the current move number is greater than or equal to <number>, so you can implement rules which are only in effect for the first ten moves, or only start working after move fifty, for example.
"(set-attribute <object> <attribute-name> boolean-value)": <object> can be "piece", "position", "player", "move", "board","row", "column", "zone", etc.. <attribute-name> is any user-selected name, such as "foo", which is queried via "<object>-foo?". (You could keep "set-attribute", "set-flag", and "set-position-flag" for backwards compatibility.)
Add support for "unlink (<direction> <position>)" to cancel links "to" the position.
"(stacking <option> <player> <position>|<zone>)": If <option> is "none", <player> cannot move to <position> if it is occupied by any player's piece. If <option> is "replace", <player> can move to <position> if it is occupied by a friendly piece, replacing it with the moved piece. If <option> is "capture", player can move to <position> if it is occupied by an enemy piece, capturing it. If <option> is "neutral", <player> can "stack" the moving piece on <position> if it is occupied by one or more neutral pieces (i.e., more than one piece may be on the same position). If <option> is "friendly", <player> can "stack" moving piece on <position> if it is occupied by one or more friendly pieces . If <option> is "any", <player> can "stack" moving piece on <position> even if it is occupied by one or more enemy pieces. Specify "board" as the <zone>to apply the stacking rule to all positions. <player> can be a list of players in parentheses to apply the stacking rule to multiple players. Multiple "stacking" commands may be needed to cover all possible situations.
To access a stacked position: "(stack? <number>)" would be true if there are at least <number> pieces at current position. "(stack <number>)" would return a <piece-type>, where 1 is the piece which moved to that position earliest (i.e., the "bottom" of the stack), 2 would be the next piece to move there, and so on. When a piece moves away, the ones after it move "down" in numbered position. "(stack bottom)" would be the earliest piece, and "(stack top)" be the most recent piece to move there.
A large number of variants could be generated by making a simple addition to the rules language. Each game could have any number of "(option name <question text>)" statements which ask the user a question in a pop-up window and save the response. The rule file would have things to test the option settings, like "(if forced-jumps? ... else ...)". For example, in Fox & Geese, the user could select whether the top zone is a fox win or not, whether fox jumps are forced or not, whether geese can move up or not, whether geese can move diagonally or not, whether the fox can move diagonally or not, whether there is a second fox or not, etc.. This would allow variants to be defined by combinations of option choices, rather than every possible combination having to be a predefined variant!
How about *.zxf for rules files which are under development, i.e., not yet ready for release. The interface could be set to reload them with a single mouse click (on a reload icon) without having to load a different game first, and there could even be some debugging or other development tools or options which are only active for *.zxf files.
Add support for "(change-owner <position>|<direction> <player>)".
You might consider supporting the syntax "(previous-from? <position> <player>)" and "(previous-to? ...)". This would allow access to the moves just made by each player. To find out what kind of move they made, I'd want something which returned a <move-type> value, such as "(last-move-type? <player>)". Also, "(last-piece-moved? <player>)".
Add support for "(not <position>)" and "(not <zone>)". |
Marek Ctrnact (Marek14)
| | Posted on Sunday, August 20, 2000 - 11:44 am: | |
The support for (open "filename" "variant") already exists - try, say, (open "Chess.zrf>Extinction Chess")
I would like a character #, which could be used like this:
#3 - any square in 3rd row.
a# - any square in a column.
## - any square in the grid part of the board.
This way, promotion zones and similar things could be programmed much shorter. |
Patrick S. Duff (Pduff)
| | Posted on Sunday, August 27, 2000 - 11:55 am: | |
The current syntax for (links ...) is:
(links <direction>
(<position> <position>)
...
(<position> <position>)
)
As in:
(links n (a1 a2) (a2 a3) (a3 a4) (a4 a5) (a5 a6))
(links s (a2 a1) (a3 a2) (a4 a3) (a5 a4) (a6 a5))
I want the syntax extended so this also works:
(links n (a1 a2 a3 a4 a5 a6))
(links n s) ; make s links opposite to all n links |
Patrick S. Duff (Pduff)
| | Posted on Sunday, August 27, 2000 - 12:21 pm: | |
The current syntax for (dimensions ...) is:
(dimensions
(<string> (<x> <y>))
...
(<string> (<x> <y>))
)
I want the syntax extended so there can be multiple pairs of (<x> <y>) coordinates after each <string>.
Right now it steps (<x> <y>) pixels once, then steps (<x> <y>) pixels again, then steps (<x> <y>) pixels again, and so on, re-using the coordinate until done.
I want it to have this same go-to-the-beginning-and-repeat behavior with multiple coordinates.
So (<string (<x1> <y1>) (<x2> <y2>) (<x3> <y3>))
would step (<x1> <y1>) pixels, then step (<x2> <y2>) pixels, then step (<x3> <y3>) pixels, then step (<x1> <y1>) pixels, and so on, re-using the list of coordinates until done.
Also, I've discovered that negative offsets don't work in the (<x> <y>) steps. I needed negative offsets to fit a hexagonal grid into a rectangular border, but was forced to use hundreds and hundreds of arguments to "(positions ...)" and "(links ...)" instead. I could have done it all with a single grid statement and two coordinate pairs, as in:
(dimensions
("A/B/C/D" (10 20) (-10 20))
("1/2/3/4" (20 0))
) |
Jeff Mallett (Jeffm)
| | Posted on Tuesday, August 29, 2000 - 4:28 am: | |
> (links n s) ; make s links opposite to all n links
Note that an alternative to this is:
(define south (opposite n))
It turns out that going "(south)" will be just as fast as going "s". |
Dan Troyka (Dtroyka)
| | Posted on Monday, September 04, 2000 - 7:55 pm: | |
I would also like to see Zillions read multiple links in the same direction from a single space. In games, for example, where the only relevant directions are to diagonal squares or horizontal squares (or to bigger spaces or smaller spaces), it would be easier to denote all links in the relevant direction by the same definition. As it is, if there are four diagonal directions, you need four unique definitions. It gets tedious when you're manually defining positions and links. |
Jeff Mallett (Jeffm)
| | Posted on Saturday, February 17, 2001 - 4:09 pm: | |
Patrick S. Duff wrote:
>Also, I've discovered that negative offsets don't
>work in the ( ) steps. I needed negative
>offsets to fit a hexagonal grid into a
>rectangular border, but was forced to use
...
Negative step offsets must be working, because Zillion's ZRF for Chinese Checkers uses them, e.g.
(dimensions
("a/b/c/d/e/f/g" (-15 25))
("1/2/3/4/5/6/7" (15 25))
) |
Jeff Mallett (Jeffm)
| | Posted on Saturday, December 14, 2002 - 2:15 am: | |
>Add support for
>"(change-owner <position>|<direction> <player>)".
Zillions of Games 2 adds the "create" command, which is pretty powerful. The "create" command can be used with this syntax:
(create <player> <position>|<direction>)
among others. With a piece on the square already, this effectively does what you want, although the pre-existing piece is really captured rather than changed.
>Add support for "(not <position>)" and "(not <zone>)".
This is already there: "not-position?" and "not-in-zone?" |
|