$MTBlogName encode_html="1"$

October 02, 2006

Designing motion graphics pt3: Code

The first part in this piece introduced the high level design concepts in motion graphics. The second part introduced a metaphor for code driven motion. In this part, we will look at how to convert the metaphor into code.

All the files used in this entry are available as a zip file here (Flash MX 2004, approx 30k). I have written the code in untyped ActionScript so that Flash MX users can follow it. Flash MX 2004/Flash 8 users should not feel too left out as I will be discussing an AS2.0 class based implementation in the next post.

It is easy to use ActionScript to create movement. You simply attach an onEnterFrame event handler to a movie clip, ensuring that the handler varies one or more property of the movie clip over time. The simplest example of such an onEnterFrame applied to a movie clip, myMC, would be

1  myMC.onEnterFrame = function(){
2    this._x += 5;
3  }

Assuming you have a movie clip called myMC on the first frame of the main timeline, and the above script is attached to frame 1 of the main timeline, you will see myMC move left-right across the stage. Why? Because the onEnterFrame increases the _x property of myMC by 5 per frame, causing myMC to move 5 units to the right every frame. By changing the script to vary a different property, we can change the nature of the animation. For example, changing line 2 to the following will fade out the clip rather than move it:

2   this._alpha -= 2;

The code above explains the concept of scripted motion (i.e changing a movie clip’s property per frame creates animation) but it is not really an example of useful animation for the following reasons:

• There is no way to define when the animation starts or stops
• There is no way to make the movie clip, myMC end up at a particular place.
• The animation is linear, leaving the clip with no sense of mass. A better animation would include acceleration (or 'easing' if you are an animator).

In the previous entry in this piece, I ended by introducing the following 4 points as the basis for useful motion graphics code;

1. We need an animation trigger. The trigger is the animation start event.
2. We need an animation target. The target defines the animation's goal. The target is similar to the end keyframe in a tween; it defines the end point of the animation. It should be noted that a scripted target is very different from a tween keyframe though. A scripted target can change during the course of an animation. Further, by changing the target every time the same animation is run, we can make the animation look different every time.
3. We need to define code that animates the clip moving towards the target. This code defines the animated transition.
4. We need a halt condition. The halt condition simply detects when we are at the target and stops the animation when this occurs.

I call this system target driven motion. The simplest example of target driven motion would be one that moves a movie clip to a position (x, y) on the stage. Let’s see how we would write this code via a worked example. We will make a movie clip move towards a user-selected point.

Create a new Flash document and set the frame rate to 24 fps (Modify > Document or double click the frame rate below the timeline to access the frame rate).

On the stage, draw a small circle and convert it to a movie clip called ball. Give the instance on the stage an instance name of clip.

Add a new layer called actions, placing this above the current layer. For the busy/lazy, the file targetDrivenMotion01.fla includes all steps to this point

The first thing we need to define is the trigger. In the simplest case, the trigger is an event*. We will make the animation start whenever we click on the stage. Select frame 1 of layer actions, press F9 to bring up the actions panel and enter the following code

clip.onMouseDown = setTarget;

Whenever you click, function setTarget() will run.

* In more complex code, the trigger can also be a condition. For example, in a video game, you might want the enemy alien to fire its laser gun at the player’s ship when the condition ‘alien is pointing at the player’ occurs. Thus, this condition is the trigger for the laser. Incidentally, the halt condition for the laser would be ‘I am off the screen or I have hit the player’.

Next, we need to write function setTarget(). Add this function above the current line as shown

 1 function setTarget() {
 2   this.targetX = _xmouse;
 3   this.targetY = _ymouse;
 4 }
 5 //
 6 clip.onMouseDown = setTarget;

The file targetDrivenMotion02.fla contains all steps to this point.

Function setTarget() sets our target. When we test this fla we will not yet see anything change onscreen but if we debug, we can see the target being set in the code. Do this by pressing Control+Shift+Enter (or select Control > Debug Movie), then click the continue icon (green ‘play’ icon at the top right) on the debugger window. In the top left pane of the debugger, select _level0.clip and in the middle left pane select the variables tab. Every time you click on the stage, you will see the values of targetX and targetY change.

NB - if you have never used the debugger before, the middle left pane may be hidden behind the call stack. Drag the call stack pane down to reveal the middle pane.

Okay so now we have a trigger for our animation, and have captured our user-defined target position. The next step is to animate our movie clip to the target.

Add the following code (lines 4 and 7-13 are new, and targetDrivenMotion03.fla contains all steps to this point):

 1 function setTarget() {
 2   this.targetX = _xmouse;
 3   this.targetY = _ymouse;
 4   this.onEnterFrame = transition;
 5 }
 6 //
 7 function transition() {
 8   var deltaX = this._x-this.targetX;
 9   var deltaY = this._y-this.targetY;
10   trace("delta = ("+deltaX+","+deltaY+")");
11   this._x -= deltaX/3;
12   this._y -= deltaY/3;
13 }
14 //
15 clip.onMouseDown = setTarget;

Function setTarget() now calls function transition() as an onEnterFrame. The new function transition() animates the movie clip towards the target position.

How does transition() do this? Well, it uses the common Flash ‘inertia effect’; every frame, the code looks at how far the target is (deltaX, deltaY) and moves 1/3 of this distance towards the target.

Lines 8 and 9 define deltaX and deltaY. Lines 11 and 12 move the clip 1/3 of the distance towards the target position (targetX, targetY).

If you test the movie, you will see that the clip moves to the last position you click, and then stops. Well, that’s what it seems to do, but the trace at line 10 tells us a different story. The output panel will continiously fill with trace values because the clip is constantly moving, even though the animation seems to stop after a second or so. The clip seems to stop because the distance it travels per frame gets smaller every frame; so small that we no longer see a movement, but the code is still creating animation.

Our animation never stops because we have not put in a halt condition. It’s important to realize that although the animation appears to stop, this doesn’t mean that the code stops executing. If every animation in a site never stopped once started, the Flash player would slow down, resulting in sluggish performance. Many designers complain about the slow speed of the Flash player, when in fact the real problem may be caused by motion graphics code that never stops when it is no longer needed!

The halt condition is almost always an if() condition that checks whether we have reached the target position.

Add the following code (lines 13-17) to the function transition() to add out halt condition (or look at targetDrivenMotion04.fla:

 7 function transition() {
 8   var deltaX = this._x-this.targetX;
 9   var deltaY = this._y-this.targetY;
10   trace("delta = ("+deltaX+","+deltaY+")");
11   this._x -= deltaX/3;
12   this._y -= deltaY/3;
13   if ((Math.abs(deltaX)<1) && (Math.abs(deltaY)<1)) {
14     this._x = targetX;
15     this._y = targetY;
16     delete this.onEnterFrame;
17   }
18 }

The if() checks for the clip being within one pixel of the target position (in both x and y). When this occurs, the code moves the clip to the target position (lines 14, 15) and stops the animation (line 16). When line 16 executes, we delete the onEnterFrame, and no code is running.

The trace at line 10 is starting to get a little intrusive, so delete it.

Our full listing now contains the basic code for usable and efficient motion graphics. Here it is in its entirety:

 1 function setTarget() {
 2   this.targetX = _xmouse;
 3   this.targetY = _ymouse;
 4   this.onEnterFrame = transition;
 5 }
 6 //
 7 function transition() {
 8   var deltaX = this._x-this.targetX;
 9   var deltaY = this._y-this.targetY;
10   this._x -= deltaX/3;
11   this._y -= deltaY/3;
12   if ((Math.abs(deltaX)<1) && (Math.abs(deltaY)<1)) {
13     this._x = targetX;
14     this._y = targetY;
15     delete this.onEnterFrame;
16   }
17 }
18 //
19 clip.onMouseDown = setTarget;

The following version of the code has liberally added trace() actions to show what is actually happening (lines 2, 5, 10, 16). See also targetDrivenMotion05.fla.

 1 function setTarget() {
 2   trace("\n\nSetting target...");
 3   this.targetX = _xmouse;
 4   this.targetY = _ymouse;
 5   trace("Starting animation towards target...");
 6   this.onEnterFrame = transition;
 7 }
 8 //
 9 function transition() {
10   trace("Animating.");
11   var deltaX = this._x-this.targetX;
12   var deltaY = this._y-this.targetY;
13   this._x -= deltaX/3;
14   this._y -= deltaY/3;
15   if ((Math.abs(deltaX)<1) && (Math.abs(deltaY)<1)) {
16     trace("Reached target.")
17     this._x = targetX;
18     this._y = targetY;
19     trace("Stopping animation.");
20     delete this.onEnterFrame;
21   }
22 }
23 //
24 clip.onMouseDown = setTarget;

If you test this version of the code, you will see the different stages of the animation listed in realtime via the output panel:

The first trace, Setting target... shows the code setting the target position, and this occurs as soon as you click. The code then sets the onEnterFrame that will control the motion to the target (Starting animation towards target...). The animation runs over a number of frames (the exact number is shown by the number of times you see Animating.). Finally, the halt condition detects that the target has been reached (Reached target.) and the animation is halted (Stopping animation).

The animation has a definite start and stop point, and the code only runs for as long as the animation occurs. More importantly, we can easily change this code to create different transitions:

• If we want a different type of motion instead of the intertia effect, we change function transition()


• If we want to change the trigger event, we simply change line 19


• If we want to change the conditional at line 12

So are there any good examples of this sort of code? Well, a better way of looking at the question would be to try to find ActionScript based Flash sites that don't use something like this code! Try deconstructing a few cutting edge sites and see all the places where target driven code is used.

Whilst writing this entry, it occurred to me that the code is a good candidate to be converted to classes, and I'll be looking at how to do this in the next post.

The content in this article is futher expanded in chapter 7 of the Book Flash 8 Savvy (Sybex), chapter 7, and a forthcoming Flash 9 book I am writing with Adam Phillips (O'Reilly).

Posted by motiongraphics at 02:28 PM | Comments (1)

June 07, 2006

Designing motion graphics pt2: Scripting

Most Flash designers pick up tweening quickly because it is analogous to traditional animation. Scripted animation is harder for many designers to grasp, possibly because there is no longer an easy analogy.

If you are one of the many designers who needs that all important analogy, you need to read this...

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.

Posted by motiongraphics at 08:06 PM | Comments (1)

May 22, 2006

Designing motion graphics part1: Inspiration

One of the most common questions I get asked from readers of my Flash books is ‘How do you start creating motion graphics?’. We’re not talking here about the actual mechanics of implementation. We're talking about the inspiration behind some of the more creative Flash user interfaces...

It's common for traditional web designers and print based graphic designers to think in terms of pages and page based sites. In such sites new information appears when you click something. This is similar to how new content appears when you turn a page in a book.

Motion graphics is more about simulating things other than page based content. The best way to explain it is like this:

• Think of something that is tied to your site's subject.


• Build a concept for the site user interface around it.


• Use how that thing moves and works in real life as the basis for your transition animations and navigation oncepts.

For example, at the moment I am involved in something for the BBC here in the UK. They want online educational content for children. One of my early ideas was to simulate a school desk, as viewed from directly above. The user can pick up a pencil and write on stuff. If they write directly onto the table, a piece of lined paper floats onto the desk, and the text 'I will no write on school property' appears 100 times. They can also do stuff with the pencil sharpener, pencil eraser, ruler (they can bend the ruler off the edge of the desk so that it makes that flub-flub-flub noise). There's a cellular phone sat on the desk that they can play around with (it is used as a video clip player), and content appears via various objects on the desk.

So the idea is all about emulating a school desk rather than use a print based mindset (i.e pages in a book), and that’s the starting point for moving away from static stuff towards motion graphics. As soon as you start thinking in terms of real things that move, the motion graphic elements start to suggest themselves.

Another thing I was asked to do once was to think up an online advertising microsite for a big chewing gum brand. What I thought of was:

• Lots of people se chewing gum to stop themselves grinding their teeth away after they take dance drugs.


• If you have a good night out, you often forget exactly what you did


• After a night out clubbing, you tend to have lots of stuff in your pocket (well, men do), including small change, club flyers, notes... and chewing gum wrappers.


• The contents of your pocket can tell the story of what happened if you look at them in a particular way

So the idea was for the site to be based around someone emptying the contents of their pockets onto a table the day after a good night out, and trying to piece what happened. You can interact with these contents to build up a narrative, and that chewing gum wrapper would be the pivotal thing - the thing that makes you remember how good the night out was. We thus have a navigation based around sifting through the contents of your pockets. Bit edgy via the drugs connection, and lots of opportunity for animation and video (oh... and humor!). Certainly not page based either.

If I had to write a couple of rules about the process of creating motion graphics, they would look something like this:

It’s best to stop thinking of pages and start thinking about other things when designing motion graphics - school desks, steam engines, a film set, the way the contents of your pocket after a night out can form a narrative, the way leaves fall from trees in autumn, the way sketches develop into paintings, whatever - and then try to emulate how that thing moves (or changes over time) as part of the navigation.

What you should avoid is take the subject and think 'how can I turn that into something that is page based'. Instead, think about how something related to the subject content of the site works (or changes over time to form a transition or narrative) in real life and think about turning it into a navigation.

Coming soon - thoughts on how to code up scripted motion graphics.

Posted by motiongraphics at 09:06 PM | Comments (9)