| Author |
Message |
Blue Mushroom (Bluemushroom)
| | Posted on Saturday, November 13, 2004 - 9:42 pm: | |
Sandbox Mode:
Sandbox Mode would allow you to remove the computer restrictions on how pieces can be moved. You could arrange the pieces however you wanted. Then at any time you could return to rules-restricted movement and engage the computer opponent to play from that starting position.
In this way you could explore hypothetical game situations that the computer might not ordinarily play itself into.
This would also save time if you have a particular board configuration in mind. You wouldn't have figure out a game that legally leads to that configuration.
On the surface this seems like a trivial addition to the software. However, now that I think about it, because of the flexibility of the game programming language, maybe not? Might this lead to situations that a given game wasn't meant to handle and thus causes a crash or something?
Perhaps then what might be modified is the game language so that you can ensure your game is "sandbox safe". There could be keywords that specify additional code specifically to handle transitions into and out of sandbox mode. Then a future version of Zillions would only allow sandbox-protected rule sets to be moved into sandbox mode.
How does that sound? |
Keith Carter (Keithc)
| | Posted on Saturday, November 13, 2004 - 10:46 pm: | |
If I understand what you are saying the ability is already there. To drop a piece on an empty space right click on the space and choose the piece. To remove a piece do the same and choose empty. There are some piece placement shortcuts. Hold down the X key while right clicking to cut the piece. Hold down the C key while right clicking to copy the piece. Hold down the V key while right clicking to paste a copied piece.
Once you have the board rearranged to the position you want to test then save the game at that point. Reload the saved game to do further testing. |
Karl Scherer (Karl)
| | Posted on Monday, November 15, 2004 - 4:01 am: | |
As much as I dislike to contradict you, Keith,
but the piece placement do not work in general,
because they do not carry along the piece-attributes and their values!
For example, if you castle in Chess
and then move the king and rook to their old
places with ctrl/x and ctrl/v, then you can castle
again, which is patently illegal.
Hence the new king and rook created with
the piece placement are both DIFFERENT from the
old king and rook you copied them from !!!
The sad consequence is that Zillions in fact
does NOT have a piece copying and/or placement
mechanism.
I think this is a serious design bug and should be corrected as soon as possible.
(Jeff, are you reading this?)
Cheers, Karl |
Keith Carter (Keithc)
| | Posted on Monday, November 15, 2004 - 4:22 am: | |
Fair enough Karl. The piece placement doesn't take into account such triggered attributes. The sandbox concept only works when placing pieces in their initial state. The sandbox concept would still work with a lot of games.
As a work around Karl could you have a castled king be a different piece type? So when the king castles it changes to a different piece type rather than setting an attribute? Then you could place either a King or a castled King piece on the board. Sandbox functionality is preserved.
Don't be shy about disagreeing with me.
Keith |
Karl Scherer (Karl)
| | Posted on Saturday, November 20, 2004 - 1:46 pm: | |
Workarounds can apply only to your own games, Keith.
One cannot (and usually does not want to) change games that other people have written.
Who wants that anyway?
Apart from that it will usually make an elegant code unnecessarily awkward.
Why make everyone suffer unnecessarily when
the big guns can do it with a brush stroke?
The easy, clear, logical and straightforward solution is that Zillions needs a proper copy
/shift board-editing feature which anyone can use for any game at any time.
The CTRL/C, CTRL/V trick is misleading anyway,
since it gives you the impression that everything
is OK, that the resulting piece is the same,
when it is not in general.
I would like to put a BIG WARNING SIGN up here to all users who play with board editing after the
first move!
Cheers, Karl
P.S.
Nice to see that you are still in good spirits.
By the way, I got as big update (lots new features) of DRAW on my website (http://karl.kiwi.gen.nz), will be out at the Zillions home page next week.
:-)) |
Keith Carter (Keithc)
| | Posted on Saturday, November 27, 2004 - 7:27 pm: | |
Hello Karl,
I agree with you that full fledged sandbox capability is the best solution. I am not saying the big guns at Zillions should not implement this feature in an upgrade. As a practical matter I do not think you will see such functionality soon.
I posted a mention of the current ability to cut/copy/paste pieces because I could not tell if Blue Mushroom was aware of the function at all. My suggestion to do the piece moving and replacing was that it be done before the first move. So some of the attiribute limitations would be avoided.
My proposed workaround would be limited to any authors who felt a full sandbox feature was important enough to put up with the extra effort and the less elegant code. I realize the sandbox subject is a wish list post and not a how to question.
Cheers,
Keith
P.S.
Nice to see your still posting your opinion on the board. Keep it up. I hope you are able to kickstart some activity or improvements. |
Greg Schmidt (Gschmidt2)
New member
Username: Gschmidt2
Post Number: 128
Registered: 1-2007
| | Posted on Saturday, January 15, 2011 - 12:49 pm: | |
I realize that I'm writing this over 7 years past the most recent post, but what the heck...
I don't believe there is a general way to add new pieces or move existing pieces that would work for all games. The reason is that the relocation or addition of a piece can violate the rules. When that happens, the game's behavior becomes undefined. For example, nothing would prevent moving a piece onto a location forbidden by the rules. What will the game do with that? What if the end of game condition requires one piece remaining and I add two pieces? Will the game end when one of the two pieces is captured or when both of them are captured? What if the state of a piece is being tracked using dummy positions and I add a new piece?
All of these things can cause problems and therefore I don't believe there is a universal solution that works. The best I can think of would be to allow the zrf code to control this feature but that would be complex to make work in the restricted zrf environment. IMO, a more reasonable approach would be to allow the game developer to turn it off via the "option" command. Maybe there could be some simple variations of that such as allowing piece relocation but not piece creation.
The Axiom client allows one to disable the board editing feature entirely for a game. That's about as far as I take it. I could see adding the ability of the game code to reject an edit as illegal and thus not allow the edit to be made, but that requires lots of smarts in the game code. It would be much easier to do in Axiom's programming model than in Zillions restricted zrf model.
-- Greg |
|