Jump to content
  • Advertisement
Sign in to follow this  

[web] Easy way to convert Flash scripts into external .as file?

This topic is 3742 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm modifying a flash game for someone right now, and I usually don't work in Flash, but unfortunately I have no choice. Right now I'm about done if I can figure out exactly how to convert 8 layers of scripts into a single external .as file for the Flash project. I don't know why this needs to be done besides clients orders, and what the use of doing this besides giving me a headache, but if anyone could direct me to a link that has a tutorial on this, or could recommend a book that has a chapter or 2 on convertering script layers that has many scripts in them and converting it to a single external .as file in the Flash Project I would be very thankful. Thanks,

Share this post

Link to post
Share on other sites
I don't think you'll find a tutorial or a book on this.

It's an unusual thing to do and entirely pointless from a performance perspective.

Firstly, I would highly recommend pushing back on the client on this matter.

Having all the script in one place would be the best way keep the file easily updatable, but if they've lumped this unwieldy task on you and are not offering [extra] compensation for your time (of which a significant amount will probably be taken up), then you need to figure out whether it's worth the trouble.

Failing that, and you are stuck with this task, I'll offer this advice:

Eight layers of scripts are most likely comprising a complex scope network within the Flash project. If you're unfamiliar with 'scope' inside Flash, prepare to be annoyed beyond your wildest dreams.

If that is the case (scope issues at play), I would highly recommend moving each layer of code once at a time and testing the functionality extensively at each step. You will also have to re-write large portions of the code to adjust the scope as well.

You also need to decide what kind of external .as file you want, or what it is they need. There are two.

1. Frame script can be stored in a .as file and brought into a MovieClip via:
include x.as;

The code then functions exactly like a frame script, only it lives in an external file and is imported during the compile.

Using .as files this way means identical syntax, but since it's still technically frame-script, the only purpose it serves is the ability to reuse code, since you can call it as include wherever you like. You might have two different enemy MovieClips for example that both call [include Enemy.as;] inside their respective timelines.

2. The most common use for external .as files is classes. If you have to move eight layers of code into a class file, it'll be even more headache, and there will be a large number of syntax adjustments to contend with. Classes are attached to Symbols in the library, and their constructors fire immediately when the symbol becomes an instance on the stage. In AS2.0 there are race condition issues (which are now fixed in AS3.0) that make it necessary to run initialization methods based on the onLoad() event rather than the constructor. Fun times.

Seriously though, unless there is only a tiny amount of code and the game is very simple, this is going to be a horrible horrible task. If they have eight layers of code it's most likely that every layer refers to itself as 'this' and other objects/layers via relative instance paths. scripts on MovieClips that contain code specific to themselves will just make no sense in a global location. Lumping all the code in one place will almost definitely mean rewriting a lot of it and maybe also lumping every MovieClip and object on the same layer, etc. Just annoying horrible work.

And for what?

[Edited by - onfu on August 20, 2008 1:55:16 AM]

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!