Viewing Category: Flash
Colin Moock, patron saint of Actionscript programmers, has given Flash 8 an A+ rating...wow! By comparison, he felt MX 2004 merited 2004 a mere B+. Anyway, he's written up his impressions on what's changed and why it's good. Some highlights that struck me:
9-slice bitmap scaling...great for implementing skinnable windows without all that tedious cutting and pasting. Kick ass!
the ability to define custom acceleration curves for tweening...sweet! This will be a welcome addition to animators who want to impart a more subtle signature to their motion work.
Of course, the new bitmap filters, for cool real-time compositing effects, with video streams even.
And bitmap caching features that should speed up performance in certain applications. One big framerate sucker is animating big fields of text, because they redraw slowly. Caching that could mean FAST animated chunks of text.
ExternalInterface, a new class that enables ActionScript to call JavaScript and vice versa. Right now, this is hard to support across multiple browsers without resorting to underhanded techniques like the Gateway Movie Trick and the getURL() Javascript Trick.
A native Flash File Upload interface! COOL!
Lower memory consumption and improved garbage collection! That info I got from this post.
Buddy Alen turned me on to the Leo Burnett Agency Website, a fantastic bit of Flash website wizardry. Move the pencil around and click: the entire space zooms in and rotates into place. It has really great transition work too, just enough to be unexpected without being distracting. It really 'moves well'...nice work.
What makes something move well? There are some good techniques at work here:
Multi-plane Layered Movement -- Notice how the letters are not moving at all the same speed? They are divided into groups, not all adjacent to each other, and move at different calculated speeds to create an illusion of depth. When you look outside a car passenger window at a big flat piece of land, and notice how the mountains in the distance move slower than the cows standing in the pasture, which themselves move slower than the trees by the guardrail at the side of the road...that's the same idea. Traditional 2d cel animation uses this technique all the time...it's at its most majestic in early Disney, and at its most shameful in 70s Japanese animation. It's particularly mind-blowing in cartoons like Samurai Jack. Amazing action and art direction...these digital animation systems have really opened things up. It warms my heart to see multi-plane done well in a Flash piece...it's not as easy as it looks to get it feeling right.
Ease-In, Ease-Out -- In the real world, things have weight and mass. When something starts moving, it first has to overcome inertia, so it starts slow and speeds up. In animation, simiulating this is called easing, and it makes the difference between something looking horrible and mechanical versus sophisticated and cool. You see it here as the zooming process begins and ends. It feels...luxurious. If you want to make your animation look cheap and crappy, just linearly interpolate your motion. Blah. Note that even South Park uses ease-in and ease-out...the motion is actually really good.
Overlapping Action -- Things are pretty dull when you know exactly what's going to happen, especially if they are happening one after the other. By having two or more things happen at the same time, you can break some of that boredom. You can see this when the zooming is just about to come to an end, and other activity starts flowing across the screen. It's a subtle, but lively touch. It's a fine line, though; there's a big difference between overlapping and competing action. Competing action splits the viewer's attention--that's great when you are doing magic tricks and don't want the audience to see what you're doing, but in motion design it means you're just wasting money. The one time it's useful is when you have something to hide, like swapping a complex vector image with a static bitmap just before you begin an alpha fade. You'd do this for realtime performance reasons--vectors are slow to refresh, especially lots of text, which means your fade will be choppy and ugly. It may no longer be an issue with Flash Player 8's bitmap-backed vector cache scheme, but I'm starting to ramble...
If I have any critique at all, it's that the slick interface steals attention from their portfolio. Because it's more fun to zoom around, you're unlikely to see the nifty content three or four levels deep. I didn't even become aware of the other content until I accidentally clicked on one. Yeah, I wasn't really paying that much attention, as I was thinking about how I'd code this up...
Be sure to click on the apples, which reveal more information about the agency's founder and namesake, Leo Burnett. There was a cool tidbit about the use of the pencil icon: Leo liked big black pencils because big ideas came out of them. That makes sense to me...don't ask me why.
Whoa, this looks very cool: a Massively Multiplayer Online Role Playing Game (MMORPG) with a Flash front-end client! Not only does it look great, but the underlying system for managing hundreds of world assets must be really nifty. My palms sweat with excitement just thinking about how this thing must be engineered.
And who put together this latest player in the MMORPG market? From what I can tell, Ankama Studio is the game development wing of Ankama Web Agency, a French company near the Belgian border specializing in e-commerce and web marketing. According to this interview, the three founders use their web agency profits to fund development of (I assume) something they've always wanted to do. Very very cool.
I haven't played the game, but the business model behind this is very interesting, as is the reason to use Flash in the first place. The reasons should sound familiar; from the raw babelfish translation:
- development costs, much more reduced than with hard development out of C.
- costs of distribution. Here, not need for editor, all is done by the Net.
- portability: with only one development, one touches Windows, Mac and Linux. It is not beautiful, that!
- One knew flash well.
Uh, yep! Cheaper development, cheaper distribution, cross-platform deployment for free, and heck, if you know Flash well, use it!
Via XD.
Making the rounds on various Flash sites is this link to Tinic Uro's Blog. He's the principal engineer for Flash Player 8, and he's writing about all kinds of interesting tidbits about the challenges of developing various features of the new player, provides historical context for the reason why certain features didn't make it into old players, and so on. Good stuff...highly-technical and informative.
Poking around into his past, it looks like Tinic was one of those developers who liked to dabble in lots of cool projects: starting an N64 Emulator for BeOS has got to be one of the best credentials for geek-graphic-ubercoolness I've seen; Zodius is a fast vector graphics library also for BeOS; in 1997 he wrote a audio player for BeOS. Anyone who developed on BeOS is probably an interesting developer to begin with. He writes an interesting opinion piece on MacOS Development compared to Windows. Very cool.
Today Jason got his Actionscript 2.0 class hierarchy working, which was very exciting for the both of us. It was interesting to see how he would approach the AS2.0 environment for the first time; I gave him very minimal guidance on how to architect it. He came up with some interesting ideas regarding his multi-screen application skeleton.
Jason came up with several neat concepts by himself:
- Scenes: a collection of MovieClips, created by a SceneConstructor
- Schemes: an event manager that is associated with a particular Scene. A global EventManager class manages a set of Schemes associated with a Scene.
- Actions: a generalized set of actions, like "Go to Scene" or "Scale MovieClip", that are invoked by a Scheme. Sort of like a command language.
Progress was going a little slow this week, so we did a code review last night. While the concepts were pretty cool, we did find a few things that were holding things up:
Ambiguity of Terminology: Scenes / Screens / Schemes, EventManager, SceneConstructor, and Actions created a rather unwieldy mass of concepts. We were constantly forgetting the difference between a Scene and a Scheme. Obfuscating the issue even more was the relationship between classes: EventManager managed Schemes. SceneConstructor was what actually set up Events, except they were called Actions, and Actions weren't quite working yet. Sometimes the variables would be named slightly differently...does a stageIndex refer to a Scene, a Screen, or a Scheme? Or is it something else? It could be simpler, and more consistent.
Object References, Everywhere: Confronted with object oriented programming for the first time, the first instinct seems to be to pass object references all over creation. A lot of code was written to propagate these object references down chains of objects...quite unwieldy.
Lack of Common Symbol Definitions: This was more of a defensive programming thing. Scenes (the collection of movieclips) used a string literal to identify what particular Scene was currently being shown. Think of this as the Active Scene. Now, event management is handled by Schemes (the collection of Handler methods that receive events fired by our GUI components). There is also the notion of an Active Scheme. Both of these active schemes and scenes (I know, it's confusing) used a string literal to set which one was active. And they were both different. And they had to be replicated in two or three other places in case statements.
Circular Creation Dependencies: Inside the Application object are two high level objects, the Event Manager (EventManager and Scheme/Scheme subclasses) and the Scene Manager (SceneConstructor). The constructors for EventManager and SceneConstructor, dependent on each other, tried to save handles to the other which were of course invalid because they hadn't finished constructing.
All awesome stuff to talk about, so we took the morning to deconstruct and rebuild Jason's object hierarchy into something that worked. It took about 2 and half hours to do...the bones were in place, just needed a little simplification to make it easier to work with. I figured having a working foundation would be more useful now; Jason can always re-engineer his advanced features in later.
We got rid of Actions. They were a cool idea to create a meta-language for encapsulating event handling into their own little code objects. But given that Jason had to walk before he could run, we got rid of them and put the event handlers in their own Scheme. Before, Schemes would pass the event objects down to an appropriate Action, after receiving them from EventManager (which was really more of a dispatcher or sorter than a manager). This made implementation much more straightforward
We got rid of the object references carried everywhere. This was something I struggled with when I was new to this stuff also, as I wasn't that clear on how you addressed what are essentially global variables in OOP without being, well, egregiously global about it. The solution we took here was to define a static method for the Application class that returned access to the SceneConstructor (the object that manages both movieclips and our custom GUI components).
We simplified the constructors of objects that were co-dependent, letting themselves create themselves first before setting the links.
We combined Scheme and Scene into one thing, each identified by a common SCID. An SCID is basically the "screen name" for a particular screen in the interactive flow. This reduces the flexibility of a "current scene" and "current scheme handler", but it simplified things conceptually, and I didn't even grasp that there WAS a "current scheme" until just a couple minutes ago.
We renamed key objects so they were obviously managers, and implemented global constants for things like the SCIDs. We got rid of all those evil string literals. Evil! We renamed other objects that seemed to have ambigious names. That's also evil.
We pressed the Debugger class back into service. This is a class I like to use for capturing trace statements. They can be redirected to a debug window text area when running in a browser, which is handy. I also insisted on including the name of the class and method invoking Debugger.Out(), so it was easier to tell where the heck errors were coming from.
After we got it all working, I put the project into Subversion and introduced Jason to the wonderful world of source control. So now, when he goes back to CA, I can continue to review his project, and he gets a way of keeping track of what he's doing.
So now, Jason has a functioning application object hierarchy that allows him to create named scenes with various GUI and MovieClip resources in them. He can add / remove scenes programmatically by making new subclasses of the Scheme base class. That's pretty darn cool...I'm pleased with his progress since we first started looking at this stuff just three weeks ago. Good job, dude!
We have yet to talk about simulation and animation techniques, but I'm pretty pleased that Jason has gotten the "nuts and bolts" part of making a Flash application from scratch. This foundation should serve him well as he started exploring more development of this kind.
There were a couple of nasty Flash gotchyas that we did have to deal with:
The Actionscript compiler timestamp bugs. Especially when you rename a class or miss it to somewhere else in the hierarchy, and the compiler is confused and never compiles your class again until you clear out the hidden aso directory. Every project IDE I've ever seen has a "Rebuild Project" or "Make Clean", or at least is smart enough to give you a touch command.
The Actionscript compile problems with circular import. Oh, come on. Had to show Jason the workaround for making a silly intermediate class that links both the circularly-referenced classes.
The sub-1.0 Project Window IDE. This thing is just so primitive. I hope the Flash 8 Pro project IDE improves this. Maybe I need to be looking into Flex instead.
The terrible and unreliable Flash debugger. I applied that "breakpoint in framescript" trick, which allowed me to set arbitrary breakpoints programmatically in AS 2.0 code. But the debugger doesn't seem to execute statements in-order for some reason...it acts really weird. Too bad. A debugger is a nice tool to have when it works. Must not have been ready for prime time...its interfacing with AS2.0 is very kludgy.
