Introducing SwfCreator3000

Posted on Tuesday, May 13, 2008 @ 11:55 CET

Update: This version is no longer in use. Check out the new version here.

A friend of mine had a problem where he had a whole bunch of SWFs that were quite similar - the only difference being certain variables and assets, though the library linkage IDs were identical (this is Flash 8 mind you). Now having used MTASC and swfmill before via FlashDevelop, we knew we could place the assets in external SWFs that get compiled in and do some code injection. Since these two are command line tools it also means its scriptable.

So I started hacking together a Perl script that does just that. It had been a while since I'd messed around with Perl but a few hours later I had something that was working but then a long, lazy weekend delayed this post :)

What does it do?

Basically the script loops over a list of SWFs you define in an XML file and compiles them with MTASC, adding in the SWFs that contain your assets and then injecting the variables you've defined. All you need to do is specify the path to the SWF and your classes and the name of your main class that starts up the app. That's it.

Variable injection?

Before each SWF is compiled, SwfCreator modifies your main class a little by adding the variables you've defined to the _global scope. If this sounds dirty to you, I agree and you're right, BUT, to avoid polluting _global we create a single Object - you decide its name - and add all the variables as its properties.

So basically, if the global object name is Cheese, and you have a variable called clickUrl, then you can access it in your code at runtime by calling _global.Cheese.clickUrl.

Having them on _global also makes it easier to test things before you do this for multiple SWFs and then simply commenting out the block.

How do I use it?

First you define your project properties in a file called project.xml (you can always call it something else). This file includes the following:

1. a list SWFs that are going to be compiled. You have to define the properties of the file to be created such as the filename, width, height, framerate and Flash version (upto and including 8)
2. the path to the SWF containing the assets exported in the library using a linkage ID
3. the path to where your classes are located (aka classpath)
4. the name of the main class that contains the MTASC entry path that starts up your SWF. If this is new to you, don't worry its simple - check this example over on the MTASC site
5. the variables that are to be included

Finally you have to define the name of the object to be created on the _global scope for variable injection, and whether or not to use MTASC in strict mode (on by default).

The sample project.xml file looks like this:

A quick example

Now that you know how it all is put together, you can download the ZIP archive from here. Then:

1. extract it somewhere (say the desktop)
2. launch Terminal.app (/Applications/Utilities/Terminal.app)
3. in the Terminal, change directory to where you extracted it. So for the desktop: cd Desktop
4. now we run the script with the example project.xml file like so:

./SwfCreator3000.pl -x example/project.xml

This will build two SWFs and put them in the example/bin folder.

Notes!

This is an alpha version so things might break, if so just let me know. Also this has only been tested on OS X 10.5 (Leopard) with the version of Perl that ships with it (5.8.8, to check run perl -v from the Terminal). Also:

1. for some reason the width/height/framerate seem to be ignored by MTASC when you compile in an asset SWF, but the output SWF inherits these from the asset SWF. Using Stage.scaleMode = "noScale"; and Stage.align = "TL"; can help with this too, and calling adding the dimensions to the SWF name for later reference such as "MySwf_400x200.swf";.
2. and finally, due to my lack of 1337 regular expression skillz, the main() MTASC entry point must have the opening brace on the same line and NOT be typed. So static function main() { is fine, static function main():Void (and the opening brace on the next line) is not

Future features

There are a few changes that I can see, for example allowing multiple classpaths, multiple libraries and maybe using swfmill to compile these which might help in letting the width/height/framerate settings stick. In any case, let me know if this helps you out :)

- paulo

Permanent link