views:

46

answers:

3

I am making a Flash puzzle game. When the user loads the game, it needs to ask whether to resume the game from the last state (if it exists). I have a serialization system in place, but I need to ensure that the loaded state is definitely the last state.

One solution is to save the state to a SharedObject every time the state changes (when the player makes a move). However, the game state sometimes includes a countdown, so I'd have to be constantly (or periodically) saving the state in order to retain it. I guess this is acceptable, but it seems kludgey.

Is there any event which is fired when the swf is closed? Or anyone else have another elegant solution to this?

(I'm not using AIR, but solutions requiring AIR are appreciated.)

Edit: Another important point is that I may not have control over the embedding HTML for the game, as it may be syndicated to many sites. So solutions involving javascript aren't ideal.

A: 

this one should help you

Eugene
Close, but not quite what I'm looking for I think. I don't want to warn the player to manually save the state of the game when they attempt to close the window, I want it to be quiet, automatic (and reliable).
aaaidan
+1  A: 

If your Flash is hosted on a HTML page, you can use the 'Window is closing' event notification to fire a message into your Flash object either using old-skool GetVariable() or new-stylee FlashCall() mechanisms.

Whether you'll actually be able to persist state before your Flash object is destroyed is another question... you could always do the (evil) 'Are you sure you want to close/navigate away from this window?' alert that some sites use.

Handling DOM Events in Flex

HTML 5 events

JBRWilkinson
Mmm, I think that's a good possible solution, but the game may be hosted on html that I don't control. I may not be in a position to request that the HTML contain such code.
aaaidan
+1  A: 

The on-close event sounds the right solution, but I wonder if you could 'split' your serialisation? i.e. save the full puzzle state on each move, but also have a secondary 'lightweight' state for your countdown (or anything similar) which could be updated each time the countdown changes.

That may be easier than trying to catch the close event and save before the page is destroyed (especially as browsers are not consistent in this area).

JulesLt
In lieu of an shutdown event, I think you're right about splitting the serialization. Will consider doing that if my existing serialization is too heavy to run every second. Cheers
aaaidan