Limited recycle? Log Out | Topics | Search
Moderators | Register | Edit Profile

Zillions of Games Discussion Forum » Designing Games for Zillions » Limited recycle? « Previous Next »

Author Message
Sblkwlf (Sblkwlf)
Posted on Thursday, June 06, 2002 - 11:30 pm:   

Actually, this is two related problems. i'm needing a way in which to allow for limited recycling of captured pieces. The particulars are as follows.

1)A component of the game i'll be trying to implement (still working on the graphics at this point, am yet to begin the actual zrf. Baby steps, baby steps...) would allow for an "exchange" of pieces based on their prescribed values by employing a drop.

For example Player A has one captured piece and an auxiliary original piece (both off the board). The captured piece is valued at 4pts and the aux. piece is valued at 5pts. The piece he is wanting to drop would require a total of 9pts in exchange for the privilege of doing so. While i'm aware that the piece to be dropped should start the game in a special zone, i don't know how to go about making ZoG value the pieces in a specific manner, and then make the computation necessary to enable the exchange.

Also i'd like to be able to differentiate between the pieces in terms of colors/players. That is to say, for example with the prior scenario, in order to drop the desired piece a player must have at least 5 blue pts and 4 red pts, or 4 green pts and 5 pts of any other color, etc. Is it possible, and if so what is the most effective way to go about achieving this?

and,

2)The game will be designed for 2 or 4 players, and while players may recycle captured pieces, if they capture a piece that they have previously controlled in the game it is lost from play (not recycled). My question is twofold. Firstly, how can i make ZoG maintain track of an individual piece's present/prior owners, so that when dropped the piece may be distinguished from the others a specific player is controlling in the case of future capture by an opponent? And secondly, how can ZoG be made to check if the player making a capture has previously owned the piece being taken at the time? Let me try and clarify it with an example.

In a four player game, Player A captures a piece that is controlled by Player C at the time of its capture. The captured piece was originally controlled by Player D. Assuming that a new piece graphic has been created to represent all of the piece's owners up to this point, how can ZoG be told that the piece will be lost from play if captured by Players A, C, or D, and recycled only if captured by Player B now?

Is this even possible with ZoG?

Any help with these issues is >greatly< appreciated.

Thanks,
-S-
Patrick S. Duff (Pduff)
Posted on Friday, June 07, 2002 - 4:36 am:   

First of all, I don't fully understand what you're trying to do, but it sounds complex. You didn't say if you've made other zrfs before -- this game isn't a good choice if this is your first one.

There are several alternatives to my binary counters which you could consider. The simplest is using piece attributes, if your game fits within the limits set by ZoG.

Another is a side board where you move markers up or down, something like in my gomoku9.zrf .

Or you could have hidden boards (never displayed to the player) where you keep track of piece value and ownership. For example, you could have a different hidden board for each owner A, B, C, and D, and then add or remove pieces from each board as pieces get captured or returned to play.

Consider a two dimensional hidden board where the columns correspond to owners or piece types, and the rows correspond to values. You may be able to define your exchange or return-to-play rules as "moves" on such a board, perhaps by a dummy player in between moves by the normal players. If so, ZoG will probably play your game well.

--
regards, Patrick Duff

Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Password:
Options: Enable HTML code in message
Automatically activate URLs in message
Action: