Comments on: Embed Assets in Flash Project

By: Markavian

Markavian — Thu, 27 Aug 2009 16:42:08 +0000

I’ve been a flash develop for some 8 years now, and I’m constantly reviewing the way I work between the Flash IDE and pure AS3 to simplifying and separate layouts from code without causing myself too much work.

On the whole, its a hassle, with me ending up with named definitions in Flash IDE, the Flash Library and duplicate references in my code. As much as I’d like to create purely code based apps, some layouts are just impossible to reason about.

I like the look of above solution because it faithfully reproduces a flash layout in a purely AS3 program independent of the Flash IDE compiler. I shall investigate and see if it works for my current project.

At the moment I’m struggling because I don’t think the Flash IDE Compiler understands:
[Embed(source="GameAssets.swf", symbol="character_john")]
public static var John:Class;
And so, this is a bit useless to me at the moment.

By: Sev

Sev — Tue, 02 Jun 2009 08:39:01 +0000

Just to clarify, this really isn’t some kind of standard method “how you should do it” or “how I usually do it”. It’s just a technique, and like most techniques, this one can be useful too for specific needs (in my case it was for an easy conversion of an older fla-project into flex, without having to redesign too much).

Also I want to mention that, no, you don’t need a class for each one of the loaded assets (for each button, graphic, movieclip etc.) That’s the whole point: you instead embed the library, and then you’re able to access any asset within that embedded library, as if you’d loaded it dynamically into your Application Domain.

By: Kirill

Kirill — Sat, 30 May 2009 12:06:23 +0000

One thing I don’t like about this is that the code is tightly-bound to the graphics, which makes dynamic skinning somewhat of a pain. Imagine having several kinds of buttons in your application. Using this approach you have to create a class for each of them (at least to embed the swf, the main button logic can be put into the superclass). In terms of code having to create a subclass just to embed a different swf? Ehhh…

What we ended up doing is having a pretty good asset loading engine take care of loading the required swfs at run time and then in the application logic pulling out the needed graphics from its ApplicationDomain. That way you only need one class for a button. The button skin is loaded dynamically at run time as opposed to be hardwired into it at compile time. This also allows for on the fly skinning of the button while the application is running. Another advantage of this is that we didn’t make our framework+applications dependent on one kind of compiler. If somebody in the future makes a better compiler than mxmlc (and that’s easily possibly with lack of some important compiler functionality on part of mxmlc) and decides to change the syntax of all those compiler directives or not implement them at all, then using your and Grant’s approach you’re out of luck and have to continue to use the crappy, old mxmlc compiler. As opposed to our approach with which the better compiler can be used instead and the application will still function like it did.