Using a Document Class
The frenetic action you see above demonstrates a simple but important modification of our first Lab project, the ball-in-a-box. Each of the 350 particles in motion here is running an ActionScript class virtually identical to the version of ballClass.as we built together. Two added lines scale the bouncing object down from its native 40x40 to 10x10, the better to fit the screen, but that's just about the only change to ballClass, the ActionScript object class that animates each particle.
While it's interesting to note how easy it is to scale and multiply anything you can build in an object-oriented system, it's even more enlightening to consider how these changes are done. If you tried to build the demo file above, using the method from our Lab, you'd need considerable time and patience. You would have to hand-build 350 layers in the main movie timeline, then drag an instance of the Movie Clip mc_ball into each one!
There is a much easier way, involving something called a document class. A document class is an external ActionScript file, just like ballClass.as, which is linked not to a Symbol in the Library, but to the main movie itself.
In the past, ActionScript coders often wrote main-level or root scripts, and installed them on the first frame of a certain layer, or attached them to a dummy object parked outside the visible Stage. ActionScript 3 allows us to bypass these awkward methods by linking to a document class.
I. Linking the class file
Setting up this link is actually simpler than linking a Symbol to a class file. With the main movie (.fla) active in the Flash editor, bring up the Properties panel, if it is not visible already. To be sure you are viewing the main movie's properties, click anywhere in the light gray space that surrounds the rectangle of the movie;s Stage (its main window). You should see something like this:
In the type-in field next to Document class:, enter the filename of the class to which you want to link, omitting the file extension. We'd repeat our complaint about this questionable interface design, but you've heard it before. As in our example here, it's a good idea to use "Doc" or "Document" in the name of your document class file. That way you'll be able to find the document class easily among the tabs of the Flash interface.
II. Structure of the document class
Here's the entire document class for the demo at the top of this page:
package
{
import flash.display.MovieClip;
public class bouncerDocClass extends MovieClip
{
public function bouncerDocClass():void //CONSTRUCTOR
{
for(var i:Number=0; i<350; i++)
{
addChild(new ballClass());
}
}
}
}
There is only one import here: the MovieClip class, since we are scripting the main movie, which is itself a Movie Clip (!).
Within the Constructor for bouncerDocClass, we run a for loop with an index counter that runs from 0 to 349, for a total of 350 iterations. On each iteration, we do two things with one statement:
addChild(new ballClass());
Within the first set of parentheses, this compound statement uses the new method to invoke the Constructor of ballClass, creating a fresh instance of this class, which is our old friend from Lab 1. You'll recall that this class was linked through the Flash editor to the Movie Clip mc_ball; it's that linkage that allows the graphics defined with mc_ball to carry over into our modified project.
On the left side of the main parentheses, we use the addChild() method of Movie Clip to add the new instance to the display list, making it visible on the stage.
If you have any experience with earlier versions of ActionSctipt, this procedure may seem a bit confusing. In earlier versions, we could instantiate new objects by attaching Movie Clips and other Symbols from the Library. However, ActionScript 3 imposes a new strictness about instantiation: we can only summon up new classes. So we instantiate the class, not the Symbol (mc_ball). When we instantiate the class, the graphics defined in the Symbol (the green ball) come along for the ride; so the end effect is the same as in the old days.
III. Why use document classes?
Note that this project requires nothing in the main timeline. (We've added a framing graphic to make the outlines of the stage more easily visible, but that detail is strictly optional.) With document classes, it is possible to work almost entirely outside the timeline.
As we've indicated, the document class approach is indispensable when you find yourself working with hundreds or dozens of objects. Using code to generate and manage instances is simply the only way to work on such levels of scale. Thus document classes hold the key to such applications as particle effects, arcade-style games, and complex interfaces.
As we go, we'll note a few cases in which document classes cannot be used, or must be used in conjunction with the more traditional, editor-based approach. Nonetheless, you should become familiar with document classes, because they greatly expand your scripting power.
IV. Source files
The source files for this project are:
- bouncer_with_docClass.fla
- bouncerDocClass.as
- ballClass.as
You may download them from the folder documentClassDemo_021408, within MULTIMEDIA, in the shared account on student-iat.
|