Malte Brill wrote:
> Malte, what did you do for drops, where you have 5 undos?
I did something I would not do again. :-)
I am cloning the playgrid and copy it to an undo card. If there are more
than 5 groups on that card I delete the one with the lowest layer. when
undoing I copy the one with the highest layer back to the main card and
delete it on the undo card. However, a much nicer approach will be to
store states in a custom property set and go from there.
like undo[1],undo[2],...undo[n|
and store all relevant data there.
My Klondike game has unlimited undo/redo and that's what I did. I stored
the state of the game in a list, pushing each state onto the top of the
list after every play. When the user chooses to undo, I pop the top line
off the list, use it to implement the desired state of the game, and
then push it onto a second list that is used identically to implement
"redo". The user is able to undo game plays all the way back to the
beginning of the game, and then redo the plays again all the way to the
final move that was made.
This was pretty easy in a game where you have a limited state change;
for Klondike I only needed to store the locations of 52 cards after each
move. But for a product like Rev, where the current state could be
almost anything, it would be much harder. We'd need an engine change, I
think, and I like Richard's idea of having a property we could read that
would return the current state of, say, a whole stack, for instance.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
