[AS3] Managing Game Frames with Timeline?

[moselekm]

Hey guys, I'm relatively new to AS3, never did AS2 or anything. I am from the C++ side. But I've decided to get more and more indepth with AS3 as time went on and wanted to make a really simple economy game for myself and friends on Flash.

I am making it all out of custom classes and the timeline is just single frames that hold the different menu and HUD screens for the player. But I later found when you'd go from let's say your 'Construction' frame back to your basic HUD, the HUD frame would be reset and all the information found on the Construction Screen (purchases and variables) would also be reset on the frame.

Maybe it was dumb to think I could 'rewind' the timeline and expect it to look the same. Either way, if there is anyway I can salvage it with some snippets, that'd be great. Otherwise, any tips on how to make a game that simplifies itself with different 'screens' would be great.

I was thinking another alternative would be to make ObjectContainers in the library, Class them, and call them like that to the TimeLine with addChild. But that seems way too sloppy to be the common-dev-thing-to-do.

[henke37]

Don't think "frames" for screens, think "Sprites".

[moselekm]

Originally Posted by henke37

Don't think "frames" for screens, think "Sprites".

Can you elaborate a little?

I know what Sprites are, but all the articles I have read say the differences of them as size is minimal and MovieClips are more dynamic; so I always just extend with movieClips so I've never actually used the base class: Sprites.

[maskedMan]

Yeah, every time you navigate from one frame to another, that frame's objects will all be re-instantiated from scratch if they weren't already on the frame you just came from. Similarly, when you leave a frame that has an object on it for a frame that does not, flash wants to be rid of the object that no longer exists, so unless you reference it somehow it will fall out of memory.

Furthermore, one big reason to never use frames to represent state is that there can be bugs with sounds on timelines that are buried deep down. Let's take the following example:

You have 7 frames on your clip, and you want to gotoAndStop frame 1 while you're on frame 7 (or vice versa). Under the hood, Flash MIGHT instantiate everything that existed on frames 2-6 along the way... it's as though the playhead "skims" the timeline instantiating as it goes. But they didn't *really* instantiate in a way that you can track. If you put code on their timelines, it won't execute... or even in their constructors, puzzlingly. Since they never were added to the stage, you can't catch them with an ADDED_TO_STAGE listener, and because they didn't execute any script they'll just "play" like any movie clip's default behavior would be... and that means any sounds on the timeline will play. And go nuts. Forever.

This means that using frames to represent state in AS3 is a really bad idea. It's much better to keep your separate states as different movieclips in the library and to instantiate them as needed. That way you can keep their data wherever you need to, and *you* control insantiation and destruction... not the timeline.

[moselekm]

Originally Posted by maskedMan

Yeah, every time you navigate from one frame to another, that frame's objects will all be re-instantiated from scratch if they weren't already on the frame you just came from. Similarly, when you leave a frame that has an object on it for a frame that does not, flash wants to be rid of the object that no longer exists, so unless you reference it somehow it will fall out of memory.

Furthermore, one big reason to never use frames to represent state is that there can be bugs with sounds on timelines that are buried deep down. Let's take the following example:

You have 7 frames on your clip, and you want to gotoAndStop frame 1 while you're on frame 7 (or vice versa). Under the hood, Flash MIGHT instantiate everything that existed on frames 2-6 along the way... it's as though the playhead "skims" the timeline instantiating as it goes. But they didn't *really* instantiate in a way that you can track. If you put code on their timelines, it won't execute... or even in their constructors, puzzlingly. Since they never were added to the stage, you can't catch them with an ADDED_TO_STAGE listener, and because they didn't execute any script they'll just "play" like any movie clip's default behavior would be... and that means any sounds on the timeline will play. And go nuts. Forever.

This means that using frames to represent state in AS3 is a really bad idea. It's much better to keep your separate states as different movieclips in the library and to instantiate them as needed. That way you can keep their data wherever you need to, and *you* control insantiation and destruction... not the timeline.

Awesome! Thanks for clarifying. It's really obvious now that I have read your post on why it doesn't work.

[bluemagica]

Since you are with a c++ background, I would strongly suggest using FlexSDK along with FlashDevelop and flixel, it will save you a lot of confusions, it is more programmer friendly, and also absolutely free.