Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
  1. Code
  2. Open Mike

Open Mike: Project Files


Do you use \bin, \lib, \src? This is Open Mike, a series of discussion posts to throw the cat amongst the pigeons. These posts are all about you — we want to hear your opinions, ideas, and thoughts. This post, I suspect, will be polarizing... let’s hear how you organize your project files.

Daniel Apt's Quick Tip showed us how to organize our Flash projects' files into different directories. But there's still the matter of where they should all go.

Which Files Go Where?

A typical Flash project is going to involve most or all of these file types:

  • FLA
  • SWC
  • SWF
  • AS
  • HTML
  • JS
  • JPG, PNG
  • MP3, WAV
  • XML
  • ...and maybe more.

How do you arrange your folder structure to store all of these files?

(Note: sometimes a file's type won't determine its ideal location; a JPG will probably go in different folders depending on whether it's to be embedded in the SWF or dynamically loaded at runtime.)

What About When Building For Different Targets?

How do you set up your folders when you're creating different builds for different purposes?

For example, you might have separate 'debug' and 'deploy' builds, or builds targeting different platforms or browsers.

Where Do You Keep APIs and Libraries?

A lot of the tutorials on this site use TweenMax. Do you have a single folder containing all the APIs and libraries you use often, set as a global classpath in your IDE? Or do you copy each library to your current project's folder?

The latter seems wasteful, but the former has risk: if you overwrite a library with a new version, it may cause old code to stop working.

How Do You Structure Your Classpaths?

Traditionally, AS3 classpaths were structured so that they contained the creator's domain name. For example, if you owned http://yourdomain.com/, you'd structure your classpath like so:


This way, the package definition would look like this:

package com.yourdomain.projectName

...and the import statement would look like this:

import com.yourdomain.projectName.ClassName;

The idea is, since you own your domain name, and you have control over which project names are used, you can stop two different libraries having the same classpaths.

But it's becoming more and more common to see this convention rejected in favour of arbitrary (and often shorter) classpaths. Is it worth sacrificing brevity for the sake of preventing two different classes having the same package?

Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.