I'd like to put in my advice, but my relevance only really extends to CS3 (might check out CS5 sometime); so I am uncertain of the amount of help I can provide that will be compatible.
Motion scenes work better with 5 moving layers for the scene (2BG-MG-2FG), than 3 (BG-MG-FG), I guess; 7 if you want to be really fancy. Repetition isn't all bad for scenes like that, provided a slight alteration to elements here and there (color filters and such really help here). If you're good with javascript, you can always use code to work that out as well. A proc-gen moving scenery tossing script could work, provided a starting anchor point and a delete point. This can also easily be done if you're ahead of class and are bored. Stock up on your own material while you wait.
Make as many elements (especially if they're going to be commonplace) beforehand and in a separate document. For example, I have a weapons and scenery cache, all pre-built, animations and animation variations (with sounds already included and pre-synched) and etc.; all I need to do is copy-paste them into a scene from the arsenal document into the project document. It would also provide security you won't lose an awesome element if the program crashes. It also helps since the noises should already be linked (provided they haven't moved since last time accessed) to the animations. An example of my arsenal is a rifle. I have a semi-auto animation (essentially just 2-4 frames (depending on FPS chosen); 1=☼, 2=Base), burst fire animation (helps to have pre-made sets depending on FPSs that might be chosen (24 or 32 FPS varieties), and automatic animations (same as semi-, except on a constant loop until I choose the right frame to switch it back to the base frame; burst is like this, except with a 3-6 frame delay as the base frame for the ending frames, but not too different from the effect this set gives off at the beginning (only for the total of 6-12 frames at the start)). All that needs to be done is change the variation for via the replace options, and choose the appropriate frame. Any other time it's not used, just leave it the base-frame graphic.
You can also do similar with special effects as well. Pre-render and compose and synchronize special effects in a separate document as well, or have a good idea of what you're doing with them.
If doing explosions, to retain quality, you can go simple, but space the timings with only 3 keyframes and 1 sound effect and a small group of layers, and even abuse some of the time spacings along the sound track for the one effect. 1 explosion, and maybe 7 yellow-to-red gradient circles (from center outward, with a transparent fade on the outermost end of the gradient), 3 layers, 12 frames (good for a half-second explosion noise); render it like you see an enemy explode in an early console/arcade game.
123456789012R Explosion Pattern
1 ☼====►◄====►R OO
2 ◄=======►◄=►R O o
3 ◄==►◄==►◄==►R o o o
Legend:
☼- Noise start (.5 seconds, or 12 frames length), also the start of a gradient circle frame.
◄==► Frame length of gradient circles that make up the explosion (larger = more frames)
R- Repeat point
Note:
Order of explosion pattern don't matter, as long as it looks like it makes sense structurally. Just remember to place the end points while the explosions are small scaled, and choose wisely where, and how big, the explosion point will be. 3 keyframes minimum. 5 or more if you want some variety added to the explosive motion. Speaking of motion, make them move as well to add dynamic effect as well (better if more explosion pods are used however). They don't need to be gradient pops however, they can be any other effect. You can even use this structure for, I dunno, even a fire or torch effect. You can even time a few random noises in separate points of the effect to make a more convincing effect (place noises as you would the graphics for the frames; take advantage of those layers). Fire crackling could be 3 different variations of a breaking branch noise at separate pitches or tempos placed strategically to make a seamless burning noise and match with the scene's tone.
For reliability, it would be a better idea to have a separate layer for the sound(s).
The beauty of these is that they stack up very well (literally; you can stack one atop the other halfway or 1/3 through, and it would blend it beautifully, and just 2 layers with 1/3 it's frames delays between make for plenty of variety in a scene; especially relevant if were a fire effect. allow enough frames total to hide any gaps, or manually fill it in with an edited start (latter half or 1/3rd, let's say) mixed in.) and can prolong an effect if synched well enough. Even single rounds with a noise (like a simple pop, or a loud bang) with just a single gradient circle can work well. I used something like that when I animated a mech exploding. Oh yeah, don't forget to add more looped frame cycles (at least enough to square off again) to make it seamless if you're applying an offset layer of a premake like that.
A good rule of thumb with animating: Math does wonders for timing. In this case, frames work almost as well as metric; especially if FPS is the scale you base off of. Just keep it simple that divides well. (1-2-4-8-16-32-64-128-256-512-1024... works best). 32fps is preferred for ease of timing and smoothest animation. However, this quality difference may make a larger file, pre- and post-processing.
For looping frames, I'm sure it's common knowledge, but might as well say anyway, make the keyframes and everything as you would normally, and trim off the last frame, but not before converting the second-to-last frame of the animation frames into keyframes. In case you want to do some editing or want clean angles (0,45,90,135,180...) if animating a wheel or prop, then this may take a bit of trial and error to get it right, but I'm sure this method works best and quickest. Just preset 1 or 2 frames beforehand before apply that trim method to ensure it holds together post-trim.
The only problem with the -1 frame looping method is that if you stack one loop with another kind you may end up with something like this:
12-frame full cycle loop
◄==========►◄==========►◄==========►
◄=========>◄=========>◄=========>'''
11-frame clean cycle loop (1 and 12 = same frame)
''' = 3-Frame gap, compared to above.
> = Converted Keyframe from (motion or graphic) tween frame
This is caused by a 12-frame loop and a 11-frame clean loop being alongside each other. It's subtle, but to a keen eye, it's noticeable. At that rate, it'll take 12 loops for them to meet up and synchronize again, only to repeat again for another 12 loops. Kinda a reason this is a bit of a trial and error kind of deal with animating loops. And going -1 with 13 frames may knock the clean balance of the animation (0,45,90...), if used, off; Then again, starting with an odd number of frames (start x+1 and then trim the excess off), will make placing the center and additional support frames (1/4 and 3/4, for example) much easier. Again, this depends on the use of the looping animation, and if you intend to make more use out of it (breaking it apart or something in the future). My advice, with loops, 32fps is most user-friendly, and -1 at a clean factor amount of frames for the loop (x-1, x=4,8,16,32...) for all the looping elements. Everything should remain consistent throughout.
Actually, in hindsight, the x+1, place keyframes, convert to keyframe on x, then trim off the last frame should yield the best results most consistently. Disregard most of the previous statement then. Overshoot by 1 frame, convert, subtract. That should work even as low as 2 frames (though it would be trivial then, going that low; 3 or 4 is more appropriate for aiming low, and are the most flexible to use).
Let's see:
Start with this: ◄====cc====►
Overshoot by 1: ◄=====c=====►
Convert to KF: ◄=====c====>►
Subtract last frame: ◄=====c====>
c = Center 2nd (usually) keyframe
12-frame full cycle loop
◄==========►◄==========►◄==========►
◄==========>◄==========>◄==========>
12-frame clean cycle loop (1 and 13 (non-existant now) = same frame)
Yeah... Looks much better now.
EDIT:
In case you already knew of these, then anyone else that comes across this might learn a new Flash trick or 2 by reading that. And remember to make the last keyframe look like the first, but different enough to complete a cycle (actually rotate the last keyframe by 90 degrees or something if it's spinning, but make sure it looks exactly like the first keyframe before trimming down the animation.
EDIT EDIT:
Cleaned up some of it. A good idea to associate the keyframe looping lesson is by animating a wheel spinning. If you can get a clean looping animation done (which can be done in fewer frames even, just animate as much that would actually be noticed. like a wheel with 4 circles symmetrically visible, just animate a quarter of it, and save some time and space to animate it. 3 or 4 frames of a spin for 90 degrees of rotation repeating is more efficient than 12 frames for a full 360 rotation, and nobody would notice. Symmetry = efficient animation if you can cut down the total frames, but not lose the quality.
EDIT EDIT EDIT:
Did some lurking, and found an old HAPPY post that is relevant to my lesson. The animations are about 4 frames long of loops for just about each moving element visible. Click on the link inside the quote to watch:
Seeing those Flash animations/games kinda got me wanting to show a little something I made in Flash as part of my old class project. I might toss in the project when I have the time to find it. Here's a sample of something I made at least.
I guess the best way to describe it is "What if Lamborghini designed tanks?":
Lambo-Tank
Caution: Right click plenty of times. Rewind and forward are your friend, as well and especially pause.
Basically it goes: treads, tank, tank moving, tank falls apart.
Note: The tank falling apart is supposed to showcase all the layers used, and how the tank has a sort of damage model to it's design.
Sorta half-assed, but it was part of a greater project (was also a resource file), so detail wasn't absolutely required (since it was mostly shrunken throughout). I think I made that a good year ago; took maybe a half-hour to produce. I know my skills are better than that, I just haven't gotten around to doing many Flash projects (even a weapons closet to use for other flash projects hasn't had an update in ages). I'm open to all sorts of ideas. Maybe something DF related, like replicating someone's interesting adventure (especially the combat). But I would need a good enough story to work with. At least it would keep me busy and doing something artistic (so at least my household doesn't think I spend every breathing moment playing games until my eyes bleed).
And I just realized watching it again, that the treads are moving in the wrong direction on the top-down view; according to the direction they're moving, it should be moving backwards. Just pause the animation; it'll keep animating, but not move, you'll see what I mean.
Author
Topic: Blarg has to make a Flash Animation! (Read 3688 times)