| « Adobe and HTML5 | "The World is Moving to HTML 5" and Other Flights of Fancy » |
This post discusses the various workflows for producing SWFs with the standalone compiler that use graphical assets and animations created in Flash Professional ("Flash Pro"). At time of writing the latest version of Flash Pro is CS4, with CS5 briefly out in beta for a short while. Specifically we look at the methods that involve exporting SWCs and using the [Embed] metatag within class files.
Recently I posted a bug report regarding the [Embed] metatag, which led me to write this post in order to find out whether people are happy with their current workflows and how well others receive projects when it comes to handovers and maintenance.
Background
So you’re building an application, a game, or a website. Immediately you have two options when it comes to setting up your Flash project. You can create an FLA file, assign a document class and get coding, or you can fire up Flash(/Flex) Builder/FDT/Flash Develop et al, create a new Flex or AS3 project and compile it using the Flex SDK compiler. Pretty much every time I’ll opt for the latter because of the increased reliability of the application, and faster compile times.
Even if you use the first option, compiling in Flash Pro itself, you may be actually editing your code in Flash Builder or some other IDE, but the point is the compiler being used in the former is Flash Pro, and in the latter mxmlc/compc the Flex SDK compilers. For the purpose of this post we’ll be looking at Flex or AS3 projects using the Flex SDK compiler, and how to get assets from a FLA, into your project.
I’ve written the following to the best of my knowledge, but there are always tips and tricks that I may be missing, perhaps an entire workflow. If you spot any inaccuracies or flaws please let me know in the comments and I’ll change it ASAP.
Why an FLA at all?
You probably already know you can embed PNGs, SVG and other file types in your classes and never go near an FLA to get graphics into a SWF. When it comes to animations, you may use TweenLite or GTween to perform transitions, but when it comes to frame-based animation, character animation, or simply buttons and panels with hand-made flourishes you may want to use an FLA to create and animate these using the powerful timeline, graphics and animation tools within Flash Pro.
It’s at this point you ask yourself, how do I get these assets from a FLA into my project if I’m not compiling my project in Flash Pro?
The Workflows
Here are 5 methods for getting assets from an FLA, into a Flex or “pure AS3″ project. I’ve excluded those which are MXML-only as this post is not about Flex specifically.
1. Publish SWC from FLA
This method involves linking library symbols to classes, so instead of “MySymbol” in the class field, you have “com.package.MyClass” which refers to a class file in one of the FLAs classpaths. You must then turn on SWC export in the FLA Publish Settings panel, and most likely turn off “Automatically declare stage instances” in the ActionScript 3 settings panel to avoid errors where your class has defined properties for items on stage. Finally add all of the required classpaths that the linked classes will be using (that could include 3rd party libraries) to avoid any compile-time errors.
When you publish the SWF it’ll also publish a SWC in the same folder. You add that SWC to your AS3 project and the classes/symbols compiled into it become available for use in your code.
Pros:
This method keeps any timeline ActionScript, great for complex, nested or multi-state animations.
Cons:
You have to compile the FLA every time you change a class linked to a symbol, in reality that can mean toggling to Flash, exporting the SWC, toggling back to Flash Builder, refreshing the project to re-build the SWC indexes and then recompiling the project here also.
You have to make sure the classes your symbols are linked to are not in the main project source directory (or any directory the project is set to reference as source code). If you don’t do this you will likely not see your graphics/animations appear because the Flex linker will find the class definition first, not the definition that is inside the SWC due to the compilation order.
You have to add all required classpaths to the FLA, possibly every classpath your project is using.
Flash Builder will not report errors in the code used and you lose the ability to Ctrl/Cmd+Click to go to source.
You don’t have access to items on stage immediately, the workaround is pretty painful (link).
Summary:
Whilst this is really the only sensible method for keeping timeline code, the cons make it a really un-intuitive and frustrating process. If anyone can suggest a way to improve this I’ll owe you quite a few beers.
2. [Embed] tag above a class declaration
Example:
Code:
package my.package { | |
[Embed(source="assets/some.swf", symbol="SymbolName")] | |
public class MyClass { | |
// code | |
} | |
} |
Here we’re simply using the SWF produced by an FLA to store our symbols. The FLA does not link any symbols to any classes itself, the library is simply full of vanilla MovieClips. In our class files we add the [Embed] tag and that binds the symbol from the SWF to the class, so that when we create a new instance of that class, we will also get the graphics from the library symbol.
Pros:
You don’t have to re-compile the FLA unless your graphics actually change.
You can spend more time in your coding environment and not toggle back and forth between it and Flash Pro.
You get real-time compilation errors in the Problems panel of Eclipse because the code is not coming from a SWC.
Cons:
It strips ActionScript from the timeline of your symbols. If your symbol is an animation, and you had a few stop frames in there, perhaps one per labelled segment of animation, you’ll lose these and the animation will just run through on loop. What you see coders do to circumvent this is use addFrameScript(5, stop); for every stop frame, or even using lots of frame labels to act as meta-tags for code replacement (link).
Any children of the symbol lose any typing, so if you’ve added a couple of MyButton’s or a MyCustomWidget to your symbol on it’s timeline, those become plain MovieClips. This is a huge problem which relegates this method to animations only.
3. [Embed] tag above a class property declaration
This method involves using the [Embed] tag above a class property, for example:
Code:
[Embed(source="assets/some.swf", symbol="MySymbol")] | |
private var MySymbol:Class; | |
| |
// later on in a function... | |
| |
var myInstance:Sprite = new MySymbol(); |
So you can probably guess this is more of a composition-based approach, which works well for simple graphics, for multi-frame MovieClips you’d type myInstance as MovieClip, and tell it to stop().
With this method you’re instance will either be a SpriteAsset (extends Sprite) or a MovieClipAsset (extends MovieClip), you cannot cast it to a custom class, so for a symbol that is meant to represent a contact form, with an instance of MyButtonClass or even just some TextFields in it, this will fail.
4. Embed metatag to embed a whole SWF
There’s also another attribute available to the Embed metatag, that’s mimeType. If you remove the symbol attribute and replace it with mimeType="application/octet-stream” it will embed the entire SWF and preserve the class associations set up in the library, i.e. you won’t have to have the instances typed to Sprite(/Asset) or MovieClip(/Asset).
When you embed a symbol from a SWF in this way, you can then use Loader to get at the classes within:
Code:
[Embed(source="assets/some.swf", mimeType="application/octet-stream")] | |
private var MySWF:Class; | |
| |
// within a method | |
var bytes:ByteArray = (new MySWF() as ByteArray); | |
var loader:Loader = new Loader(); | |
loader.loadBytes(bytes, new LoaderContext(false, ApplicationDomain.currentDomain)); | |
| |
// wait for loader to dispatch Event.COMPLETE and... | |
var myClass:Class = loader.contentLoaderInfo.applicationDomain.getDefinition("com.package.MyClass"); | |
var myInstance:DisplayObject = new myClass(); | |
// myInstance is now an instance of the class linked to it |
Pros:
Great way to provide a library symbol a class/some behaviour without having to constantly re-compile the FLA.
Cons:
I think you’ll agree that’s not a great option if you have a lot of symbols or symbols which have others nested within. There are libraries to help with this, but…
No strict typing.
5. Runtime loading a SWF
Perhaps the oldest option here, loading a SWF at runtime allows you to pull out symbols/classes using the applicationDomain.getDefinition() function as described in method 3. If you’re already familiar with the getDefinitionByName() utility this works pretty much the same, but you are targeting a specific SWF’s classes.
Pros:
Great for loading content that rarely changes, such as fonts.
Cons:
Magic strings. Making a string a constant does not make it any less hacky, if you change the string in your FLA, your constant is meaningless, and you’ll only find out about it at runtime if that piece of code executes.
You’ll have to export your SWF from an FLA or using one of the other techniques which means you’ll also have some of the problems associated with those.
Feedback
So what route do you take? Please also state the type of project: application, game, website; it’s quite possible that people building applications simply never encounter these issues due to the primarily scripted animation and simple non-hierarchical graphical assets.
You may also want to consider how easy it will be to start compiling in Flash Professional in order to take advantage of CS5’s export to iPhone, this can impact your decision on which method you use.
Overall I feel that whilst choice is great, each method seems to have pretty serious downsides, and I’m yet to find one that doesn’t make for a less than pleasant rinse-and-repeat workflow. It would be nice to be able use Flash Pro to speed up the process of preparing game assets, laying stuff out on stage, animating on the timeline… but there are too many down-sides associated with this, and too many idiosyncrasies to learn just to get things working, I hope in future the two tools can be brought closer together perhaps through the new file format.
As usual, all comments welcome, unless you’re the bargain-dishwasher spammer.
Further reading
http://www.bit-101.com/blog/?p=853
http://www.bit-101.com/blog/?p=864
http://gskinner.com/blog/archives/2007/03/using_flash_sym.html
http://www.airtightinteractive.com/news/?p=327
Also the Flex Livedocs, which certainly don’t explain all of these methods in nearly enough detail or context, which makes using the Flex SDK a darker art than it could be.
Comment feed for this post
Follow me on Twitter
As for the swc method, I think the idea is to leave auto declare stage instances on, set a non-existant class in the library and let flash pro generate classes with this hierarchy tree generated for you. Then you use composition to access this different parts.
Overall it's a mess caused by the flash/flex schism. I don't think any other technology handles this better, but they don't have to deal with the awesome richness of the flash animation tool.
There's one more work flow that I've used that I really love. I picked it up from the workflow docs over at flashdevelop.org.
You can export your FLA as a SWC as in step 1. This allows all the keeping of nested timeline actions. I usually don't like to tolerate much more than stop actions, but the artists I work with have their own opinions on things and I try to meet them half way.
Unlike workflow 1 you do NOT link the symbol to a custom class. Instead you keep the default base class and have Flash autogenerate a class for the symbol, e.g. (I'm not describing it well, but I think you know what I mean.)
Then, create a custom class in FlashDevelop that extends (or composes) the autogenerated class. I.e. MovieClip FooClip in Flash library has a linkage name of FooView. In FlashDevelop You create your.package.Foo which extends FooView.
your.package.Foo is a first class member of your MXML compiled application, but the artist doesn't need to know anything about it, cannot screw up the class path publish settings, etc.
There are a couple of downsides, but this comment is getting long in the tooth. Maybe I'll do a write up over at my site makerofgames.com.
Overall, I'm quite pleased with this workflow and I encourgage you to try it out. If I can find the link to flashdevelop's docs I'll let you know.
When you diverge into experimental ways of building projects you'll actually waste more time for anyone who is receiving the project. And chances are the person who's receiving the project will open up the fla's and start publishing.
And now that you've handed over a project that isn't documented, the person who opens up the fla won't be able to build it.
In my experience it's easier to stick with fla's. When you hand over a project to someone else it's almost guaranteed that their machine won't be able to build the project without you showing them how.
My favorite process is to stick with run-time loading. It's easier to partition the site, application, or whatever into modules.
When you try some of these experimental ways of building, a lot of times code for non-related modules will get included in every swf.
In the end I'd say stick with runtime. It's easier down the road to change when swfs are loaded, or when classes become available through swf libraries.
The other solution that is missed: runtime loading plus the Flash 8 exclude classes. But Adobe can't seem to figure out that this workflow was useful. Come on ADOBE! Get exclude classes in Flash!
@Iain - I think you hit the nail on the head in your last sentence. After spending a year in Flex and recently working with the Android SDK, I was left feeling like this whole process is broken with Flash, but it's more the case that it's only with Flash that you have this unique code/timeline combination that's awesomely flexible, but at the same time incredibly hard to integrate into a more traditional, strict code environment.
The closest parallels are probably Unity 3D, which doesn't suffer half as much because in general, 3D assets are more self-contained, and Microsoft's Expression Suite for Silverlight/WPF. The coding tool is Visual Studio, the "Flash Pro"-like application is Expression Blend, which has a timeline for animations, behaviours, actions etc. The timeline however is not frame-based, it's more like After Effects (or the newer animation methods in CS4).
The key thing with Expression is both tools open the same project files, and that the project files are all XML/code. This both fixes the one problem and introduces a new one; the capabilities of the animation tool simply does not allow for the kind of per-frame-based hand cranked animation you see in Flash without producing reams of XML, and it doesn't do shape tweens.
As you say I'm hoping uncompressed XFL will provide a better way of working between the tools in the same way as XML/XAML/CS does for Silverlight, even if there have to binary blobs in the XML or referenced by it.
@MakerOfGames - I like your suggestion. The only thing is I think we'd still be losing the ability to nest items in a symbol (e.g. "MyForm" contains an instance of another library symbol, a "MyButton", which needs a class of its own to control its state). Perhaps you know if this is possible.
@Aaron - Absolutely, in the first part of the post I mentioned handovers and maintenance exactly for this reason. I believe that if you can't checkout a project from SVN (or just copy it from disk), open it in 1 tool and hit compile, you've overcomplicated things; file paths should all be relative for example.. in my Flex projects I end up manually editing the "hidden" files to change any absolute paths because although I work on a Mac, many people I work with are on PCs, or are using a different application/SDK path. SWCs should also always be included with the project and not referenced on c:\libs or something crazy like that.
A small readme.txt which says they need to publish an FLA when graphics are changed is kind of acceptable, but clearly if you're using FLA and AS3 projects, things are still going to require some explanation given how many techniques we have here.
Runtime loading works OK for me for some things (fonts for example) but it still suffers from most of the problems outlined and you lose many of the nice features of Flash/Flex Builder like jumping to the definition of a class, particularly if you're using loose typing to access the stuff within the SWF.
I've always avoided using methods that involve excluding classes, sometimes just taking the hit on file size to avoid having to write a tool with ANT/ruby etc to do the job, you're right, it's a little bit of a problem. Thanks for your comments.
I most often use option 1 for production. I do embed assets in classes in Flash Builder for demos or exploration.
Since I am a one man operation, I make sure my designer side doesn't code in Flash CS4 and let my developer side do it all in Flash builder :)
I also like having all my compile time assets in one FLA file.
E.g. var timeline : TimelineAnimation = new TimelineAnimation()
If TimelineAnimation has a button or something in it that needs managing by a class, I'll create another custom class in FDT and just pass it a reference to that button within the animation.
E.g:
var timeline : TimelineAnimation = new TimelineAnimation()
var button_manager : ButtonManager = new ButtonManager( timeline.button );
Then the ButtonManager class can handle anything to do with the button.
This workflow works really well for us, letting us nest whatever we want within our Flash IDE MovieClips and it all works fine.
with what @MakerOfGames describe
in short, name your exported symbols and use only builtin classes
(MovieClip, Sprite, etc.)
for ex: com.test.MailUI
then in your pure AS3 code you just reuse the gfx assets
class Mail extends MailUI
and there your code editor will have code completion on all the different elements defined in the UI
some people may consider it "bad" that they will have to do
the wiring (events, interaction etc.) of the UI in pure code
but to me it's better ;)
I am mainly working on Flash games and many of the graphical assets are bitmaps and sequences of bitmaps. If I can, I like to use something along these lines for the bitmap sequences:
http://blog.hexagonstar.com/animatedbitmapclass/
A pro you missed for #1 is that FlashBuilder will do code completion on all the nested MCs in your FLA symbols and throw errors for missing MCs.
If you keep your FLA code to an absolute minimum (typically just a few stop()s) then some of your cons go away.
I give a little more detail on this method here: http://www.airtightinteractive.com/news/?p=327
once the visual representation of the assets is ready and compiled in the swf i have to work only on the model side of the concrete component.
lately i've been sticking to the "separate model from view" practice, which is great as it kind of forces you to eventually write more reusable code, and on the other hand freeing you from the chore to recompile your library fla, everytime the code concering the assets changes.
http://www.bit-101.com/blog/?p=2173
Interesting post.
Just wondered if you'd found a workaround for the 'nested instances' issue when using SWF or SWC linking?
I often use the composition method described by Kyle for nested items, but sometimes a quick and dirty way to preserve class associations would be preferable. Any suggestions?
Yeah the whole nested thing quickly gets complicated so I ended up just publishing in Flash (via ANT->JSFL so I can pretend I'm still in the same IDE!).
1) Isolated compiling.
2) Simple visual layout placement.
3) Code/Graphics isolation making it easier for more people to work on the code and graphics.
4) Code is often small enough to be used as preloader
5) Code can be a AS3 or haXe structure, I have similar structures for both, and could swap out all the AS3 for a haXe code swf without any change to the graphics swf.
6) Easy typedef or -remap when using haXe, so you start to code with an eye to targeting other platforms.
7) decoupling of visual structures from logic, allows you to order your depths and masks differently from how you wire up button state logic.
8) View granularity can be how you want, ie you don't have to have a class for each MovieClip button. You can sometimes create a view to handle a set of buttons.
9) If you place all you main linkage MovieClips in a layout MovieClip, and loop through the layout's children then you can easily check assets exist. If you use a Static class to access them off you can treat it the same as the library, I tend to wrap the xml into an abstraction of getters and access them off a Static too... I know its like using root, but saves passing application wide aspects around classes, although this part is new approach.
10) It seems to work well for me :) I am a fan of KISS that is also why I don't use flex or normal components, although I would like a an alternative.
var myClass:Class = loader.contentLoaderInfo.applicationDomain.getDefinition("com.package.MyClass");
You can if you want to, but the way this is loaded in, and assuming you aren't messing with the applicationDomain when it's loaded... if you have a library symbol that has a class linkage or a base path to a class that is in your flash builder project, when you do new MyClass() it will actually use the assets from the loaded swf without using getDefintion(). Now if you have a class that is exported in the library that isn't related to a class in flash builder you will have to use getDefinition.
The biggest down fall i have seen with this workflow is that timeline animations in objects that are exported for AS seem to lose their timeline scripts. 99% of the time this isn't an issue for me. The way around it is to make the timeline animation a child of the exported movieclip. The other thing to keep in mind is that you should always have "auto declare stage instances" disabled in the fla.
One other really cool thing about this is that if you aren't using base classes for any exported objects your fla doesn't even have to have a class path pointed to the code. When the swf is loaded all matching class paths just work together.