$MTBlogName encode_html="1"$

The easy explanation is to assume it is all about code… ‘designers don’t like code’.

I don’t think that is true - may designers want to learn scripted motion, but they simply don’t know what the concepts are. I therefore came to the conclusion that people don’t make the switch to ActionScript animation because there is no obvious analogy to base the process on - its not that scripted animation is hard… it’s because we the teachers have never tried to explain it using an easy and consistent analogy, followed by a general set of steps that show how scripted animation can be created.

To remedy this, I tried to step back and think up a simple system for visualizing what scripted animation is all about. I call this system target driven motion.

Imagine you had a piece of elastic with a ball on the end of it. If you tie the free end of the elastic to a post, then pull the ball back and release it, the ball will fly back towards the post. Here's the steps that will take place...

• You tie the elastic to the post, then release the ball.
• The ball moves towards the post, pulled along by the elastic
• The ball hits the post

Simple huh?

Surprisingly, these steps also define everything we need to do for scripted motion to work:

1. We need to set a trigger. The trigger is analogous to releasing the ball. It defines the start of the animation.
2. We need an animation target. The target is the place we want the ball to hit. In this case, it is the post, or more correctly, the point where we attach the free end of the elastic.
3. We need to define some code that controls the animation of the ball moving towards the target. We will call this the animation code.
4. We need a halt condition. We need to define when the animation can stop. In this case, the halt condition is when ‘the ball hits the post’.

And that really is everything we need to consider for our analogy:

• We need a trigger that starts the animation. For our code to be useful, the trigger should be an event (or linked to one, such as the user clicking a button). Animations that start as soon as the swf starts are cool for Flash experiments, but not normally useful for commercial web design - an animation that runs all the time usually slows the rest of the site down or quickly becomes boring (and usually both).


• We need to tell the animation code where it needs to end up via a target position. In the simplest case, the target is defined in terms of properties. For a motion animation applied to a movie clip, the target would be defined as _x and _y properties. If the animation was a fade out effect, the target would be defined as an _alpha property value of zero.
  We need to define some code that performs the animation. The code is usually very simple - all it has to do is move a little closer to the target position every frame.

Finally, we need to define when the animation can stop. An animation that ends when it is no longer needed is very important in commercial design, for much the same reasons we discussed in the first point - performance and usefulness.

Let’s see this system graphically before we move on to the code. The crosshair below denotes the target. This crosshair is draggable. If you drag/drop it, you will be invoking the trigger (the drop event) and set the target position (the position where you drop the crosshair).

The ball will then move smoothly to the target position via the animation code. When the ball reaches the target position, it will stop because the halt condition has been met.

There’s a few things to notice about this animation:

Firstly, if you drag-drop, then drag-drop again before the ball reaches the target, the ball will change its course to move to the new target. This is how you generate complex movement - keep changing the target position! It is how you would create the movemenet of graphics that appear to move intelligently, such as enemies in a video game or context sensitive user interfaces. In both cases you change the target position regularly using rules. In a video game, the rules would be based on the skill level and where the player’s graphic (or ‘ship’) is. In the case of a context sensitive user interface, things would move and/or revel options based on the user’s recent actions.

Secondly, it is worth noting that the animation code is simple - it just moves the ball between two points. The complex or clever code is the stuff that changes the target position. Although this may seem like a subtle difference, it is actually a major structural difference in terms of the final ActionScript.

Finally, notice that the target is being set by you the user. You might be thinking ‘uh, that’s because this is a stripped down example, right? In a full implementation, the target would be set by code.’. Well, sort of. In most motion graphics, it is the target setting code that is the most clever. ‘Clever’ usually means ‘technically difficult’. Worse still, it may also mean ‘processor intensive’, something that can turn a smooth animation into a jerky slideshow. A better and somewhat sneaky way around this is to make the user sets the target for all your animations. The trick is to do it in a way that the user doesn’t guess this is happening!

In a space invaders game, the target is the player’s spaceship, and this is of course being set by the player. The aliens are simply reading where the player is, and setting their animation targets (i.e. where they shoot and where they move) based on that position. The game might appear to act with intelligence, but that intelligence is coming from the player!

Play around with the animation and see how fundamentally simple it all really is

Coming up soon, the code to create the motion, and how it can be applied to real world examples...

See also the first part in this series of tutorials/discussion here.

Get the flash 8 source file for the example above here.

Comment by FLaKes