Internal Movie Clip Animation

Looking backwards

When Flash was first introduced, it had only rudimentary scripting capabilities, so the program was mainly used for animations and simple, button-click interactivity. In those days (roughly 1997-2001), most Flash work was done using multiple frames in the timeline. With the advent of ActionScript, ActionScript 2.0, and now ActionScript 3.0, Flash has come to support more robust scripting, allowing more advanced applications, such as games, simulations, and front ends for databases and Web services. Since heavily scripted projects often require only a single frame in the timeline, we can think of the modern Flash era as the Single Frame Age.

Even in the time of the One Frame, however, there is sometimes good reason to revert to the older way of doing things, when for instance you want to loop a particular visual display or behavior within a dynamically executing main action -- as in the example above.

Look at what you are seeing. First, envision three axes, the familiar X (horizontal) and Y (vertical) from the Cartesian system, plus a Z axis perpendicular to the screen.

The mannequin figure in our demo moves in all three axes. Like our bouncing ball, he moves up/down and left/right; but he also has his own internal animation in the Z axis, spinning like a top.

When he is moving right in the X axis, he spins from left to right in the Z. When he moves the other way in the X axis, his Z spinning also reverses.

When the mannequin moves down in the Y axis, the entire spinning figure rotates counterclockwise in the X axis. The figure rotates the other direction when moving up in the Y axis.

As in the bouncing ball example, much of this movement is controlled by scripting; but since the Z-axis is out of easy reach in ActionScript 2.0 -- just wait for 3.0 -- the mannequin's spinning on his own axis comes from somewhere else: from a series of looping frames built into the Movie Clip. When a loop is embedded in a Movie Clip in this way, we will refer to it as internal.

You'll probably want to use internal Movie Clip animations at some point. To help you master the technique, here's a quick anatomy of the simple project shown above.

Animations

You could draw your own animation frame-by-frame for a simple character. If you're not much good at drawing or animating, however, you might want to use a special tool.

The animations in this project (shown above) were generated with Poser from Smith Micro, a relatively inexpensive but powerful tool for modeling and animating human figures. Poser will output an animation directly to Flash format (.swf). The process involves quantization (posterization) of the image, so the result looks more like a sketch than a photograph.

If you think of Flash as a vector animation program, this sketchiness won't bother you. If you want more color depth and subtlety, you could try shooting video -- Flash imports QuickTime.

Architecture

The main Flash movie for this project consists of a single layer and a single frame, but the Movie Clip installed within that frame, called spinningMan, has within its timeline 48 frames. These frames were imported from the .swf files generated in Poser.

The first 24 frames in spinningMan show the figure rotating 360 degrees to the viewer's right; the second run of 24 frames shows the reverse rotation.

If we simply ran all 48 frames, the figure would spin one way, then the other. To prevent this, we attach an action (that is, an ActionScript statement) to the keyframe at 24, the last frame of the right-to-right rotation. The statement says:

gotoAndPlay(1);

This instruction sends the internal playback head of the spinningMan animation back to the first frame, skipping the second, left-to-right rotation. But since we also want to see that rotation under certain circumstances, we place a second action on the keyframe at 48:

gotoAndPlay(25);

This instruction creates a second loop within the 48 frames of spinningMan.

Scripting

The spinningMan Movie Clip is linked to an ActionScript class called tumbleManClass. This class is largely identical to the code you developed in Lab 1 to control the bouncing ball. A few changes have been made in the enterFrame handler. The if/then clauses controlling vertical movement pick up some new instructions:

  if(YWay == "down")
    {
      rotation -=4;
      y +=YChange;
    }
  if(YWay == "up")
    {
      rotation +=4;
      y -=YChange;
    }

The rotation property of a Movie Clip controls its rotation in the X/Y system. It is measured in degrees. Subtracting from the current rotation value causes the Movie Clip to rotate counterclockwise; adding rotates the other way. We don't need to worry about the values assigned to rotation, because the Flash player automatically resets that value to zero when it passes 360.

As you can see, these two additional statements give us the rotation of the mannequin clip in response to up or down movement; but the mannequin also changes his spin, which is animated through his sprite frames. That trick is accomplished by adding two more lines to the boundary tests for the right and left sides of the screen:

  if(x > 400)
    {
      XWay = "left";
      XChange = 5+Math.floor(Math.random()*5);
      tumbleMan.gotoAndPlay(25);
    }
  if(x < 0)
    {
      XWay = "right";
      XChange = 5+Math.floor(Math.random()*5);
      tumbleMan.gotoAndPlay(1);
    }

The new third line in each of the if/then constructions sends a gotoAndPlay instruction to the Movie Clip that contains the mannequin animation. This clip has been assigned the instance name tumbleMan.

As you can see, the gotoAndPlay statements send the sprite animation either to frame 1, restarting the left-to-right spin, or frame 25, restarting right-to-left.

There's a slight design flaw implicit here: if the command to jump to the beginning of a spin sequence happens while the sprite is in the middle of aanother sequence, the animation may appear to drop frames. However, you need to be watching rather closely to notice this glitch, and since the whole project is sketchy or cartoony, we can probably get away with a little roughness. If you keep your animation loop relatively small -- 24 frames is a good working limit for the standard 12 fps playback rate -- then the sequence jumps won't be noticeable.

There are ways to eliminate this problem, but they would make the demonstration code harder to understand, so they're not discussed here. See if you can come up with your own solution.

Source Files

Since this project uses the completed version of the bouncing ball code, which is the core requirement for Lab 1, I won't provide the ActionScript file for this project. The discussion above should tell all you need to modify the ball code. Be sure to change the class file name to tumbleManClass, and to make sure the class name and constructor method are changed accordingly.

The Flash source file (.fla) for this project, containing all the animation frames, is available in the shared account in the subdirectory internal_mc_Animation.

Variant

Finally, here's a variant on the demo project in which the Poser figure rotates in both the X and Z axes. This one doesn't use the rotation property to rotate the Movie Clip, but jumps to one of four sprite loops depending on whether the Movie Clip is moving right-and-up, right-and-down, left-and-up, or left-and-down.


University of Baltimore Logo

Last updated: 06/24/08 16:26:21
Copyright © 2008 School of Information Arts and Technologies