Early on a Flash developer uses frames, as they are natively available in Flash player, to host various screens of their application (most often it's a game). Eventually they might stumble upon an issue that something goes wrong exactly because they have used frames, and overlooked the difficulties that arise from this, and seek ways to both retain their frame structure but also remove the obstacle of using frames with its complications. The solution is to use Sprite
descendant classes, or exported frames as MovieClip
s with a single frame (to those that design in Adobe Flash CS), and manually switch the contents with addChild()
and removeChild()
.
The manager class should have all of its child frame classes ready, and whenever a transition is called, a function similar to this can be used:
var frames:Vector.<DisplayObject>; // this holds instances to ALL children
var currentFrame_alt:int; // current frame. Can't use the property
function changeFrame(frame:int):void {
removeChild(frames[currentFrame_alt]);
addChild(frames[frame]);
currentFrame_alt=frame;
}
All children can both dispatch and listen to events with Event.ADDED_TO_STAGE
used as an entry point for whatever happens after gotoAndStop()
targetting that frame, and any outgoing transitions can be coded as events based on strings, which are being listened in Main
class, which then performs the transition.
frames[0].addEventListener("startGame",startGame); // assuming frame 0 is a "Play" button
function startGame(e:Event):void {
changeFrame(1); // switch to frame 1 - will display frames[1]
}
Of course, the set of strings should be predefined, for example, intro screen could have two buttons to start the game, "Start game" and "Start muted" for example, and the buttons should dispatch different events, which will then be handled differently in manager class.
This pattern can go as deep as you need to. If any frame of the project contains a MovieClip with multiple frames, it can also be decoupled into sprites with this method.