The Flash Connection Make mine Actionscript 3.0!

Source File: 

structure_tutorial.zip

Here's the finished SWF file, fully functional (even if it is a bit shrunken down for display purposes). You can click the buttons, get game instructions, switch screens, and drag continent names to where they belong. I realize of course that it's missing some of the things that would make it a truly finished game: a scoring system, a "start over" button, maybe a timer, some sounds, or other enhancements. What it did, though, is served the purpose of being a good, simple example file. You can download the ZIP at the end of this page.

While it may seem a bit disconcerting (for yourself or others) to open the FLA file and find that there is nothing on the stage and nothing on the timeline, I believe that if you try out this system and get used to it, you will find it far superior, and wonder how you got by without it. On the designing end, to work on a "screen" you will just double click it in the library. From there, you can do whatever layout work you want, creating more objects and giving them instance names. Then, on the developing end, you can edit the class file and use those instance names to program the behavior. The way things look and the way they act are wonderfully separated.

In your class, whatever you want to have happen up front (at object creation) should be put into the constructor. Whatever you want to have happen when the screen is added to or removed from the display should be put into the addedHandler or the removedHandler functions. What event listeners should you add and remove inside these functions? Any ENTER_FRAME handers, and any event handlers that were added to the stage, for sure. For example, you may have a screen that adds event listeners to the stage for keyboard events. You would want to add and remove such listeners whenever the object is added and removed from the display to keep them from firing when you don't need them. However, event listeners added to buttons need not be added and removed in this way. When they are not on the display, they can't be clicked on, rolled over, or interacted with anyway. Of course, it is ultimately up to you as to what kind of housekeeping you want to do with these added and removed handlers.

It's important to realize that instantiating an object with the "new" keyword puts it into the computer's memory. Adding it to the display with addChild just displays it. Removing it with removeChild just takes it away from the display. But removeChild doesn't remove it from memory. This is another great thing about this system: it gives you total control over what happens and when it happens. You will notice that unlike the system of timeline navigation I described at the beginning of this article, where things are reset when you revisit the frame, using this system you get to decide whether things get reset or not.

I will give you an example: Run the FLA file once. Click "Play the Game" at the Intro screen. Then, from the Learn screen, go to the Drag screen. Drag three continents to where they go and let them lock into place. Now switch back to the Learn screen. Now switch back again to the Drag screen. Notice that everything is just as you left it! That's because while the screen was not being displayed, it was still being held in memory. What if we wanted it to reset each time? Try this: Open Main.as and add a line to the gotoDrag() function that instantiates the drag screen all over again:

public function gotoDrag():void {
	removeChild(currentScreen);
	drag = new Drag();
	addChild(drag);
	currentScreen = drag;
}

That second line inside the function is the new one. Right after the currentScreen is removed, and just before the drag screen is added, I inserted a line to make the drag object instantiate again. This will make a totally new object, that new object's constructor function will run, and the drag variable will point to that new object instead of the old one. Everything will effectively be reset. Save this file and test the movie. This time, when you drag three continents to their place, then go to the Learn screen, then come back again, everything is reset. Knowing this, can you now imagine how you might easily make a "start over" button for this screen?

Since using this system is completely modular, when changes or updates are required, you will know exactly where to go to make them. Also, you can make your changes without them affecting everything else. Since classes have their own scope, if you like to use variable names like "currentClip," you can reuse them in your other classes. With hardly any hassle whatsoever, and with just a few edits to the document class, you can add or remove screens from your application at will. Coming back to applications later to update them becomes practically painless! Especially when compared to the "main timeline navigation" approach.

I have written this tutorial and included a lot of "how-to" stuff about things like tooltips, arrays, and drag-and-drop. But I also didn't want to get bogged down in that other stuff. What I mainly wanted to do is to create a simple application that would demonstrate the superiority this system of classes linked to library symbols for screen changing. In this tutorial we made a simple game with just a few screens. But you can take this system and apply it to any kind of application you want. The "screens" might be pages for a website application, for example. One screen might be your home page, another your photo gallery, yet another your contact page. The great part is that working on any one screen is isolated from everything else, and they can all be easily brought in or taken away from the overall system. So, your only limit is your imagination!

The screen switching can also be linear, or based on certain conditions, or whatever you want. For example, suppose our game had another level beyond the Drag screen. But we don't want to make that available until all the continents have been matched up. Just make a counter variable, increment it each time a match is made, and then don't show the button that advances to the next screen until all the matches have been made!

As always, I hope this article has helped to inspire you and spark your imagination, and I appreciate all of your comments. Happy coding!