Design Patterns

I lead an ever-growing team of Flash developers at a company called DigiDeal. We create electronic poker tables that go in casinos. Our goal is to pump out new games as often as possible. Since most casino games are just a variation of some “base level” game (such as Poker, Blackjack, Baccarat, etc), inheritance and code re-use is extremely important to us. Whenever possible, everything we create is broken into modular components with a good API. The “modules” can be as simple as a playing card or bet chip. But they can also be fairly complex such as a chip compilation linker, which takes care of creating multiple chip groups (one for your personal bank and [n] others depending on the number of distinct bet types in the given game), and allows them to interact with each other, send chips flying across the screen, color up the chips, balance the chips, and do various other animations. These “modules,” as I’m calling them, consist of a MovieClip/Sprite stored in the Flash Library and a linked AS class file.

Let’s say I get a spec for some new variation of a Blackjack game that I’m supposed to develop. My ideal goal for development would be as follows:

1. Create a new .fla and the associated Document Class.
2. Copy in all of the previously developed modules into the Flash Library or Stage as needed.
3. Re-skin these modules where necessary.
4. Write an inherited class for any of the modules that do not exactly fit my current needs.
5. Import all of the necessary module packages in the Document Class.
6. Utilize their API’s (properties, methods, and events) to get the game running as desired.

This, of course, is nothing new or exciting in the normal development world. But there is a unique organization problem in Flash. You have to organize, not just your .as files (package tree) and any associated images, sounds, and/or videos, but you also have to organize your Flash Library MoveClips. There are a couple of ways that this could be done.

You could create a single “modules.fla” which kept every component that you might ever need in a single file. Then, whenever you started a new project, you would just get everything that you need all from one place. This might be a great solution if you don’t have many modules. But what if you have over 200 modules and the .fla gets over 300 MB? Try opening and saving a 300 MB file in Flash. Personally, I’m not a fan of my mouse cursor turning into an hour glass for an extended period of time. Not to mention the repository ramifications if you only wanted to modify a single one of these modules or if multiple developers wanted to work on multiple modules simultaneously.

So, naturally, a better solution is to save each module in its own .fla. The question just becomes, how do you organize these .fla’s?

You could save them all at the root of the package tree. The benefits? You never have to set a class path and you’re guaranteed that the module you are looking for is somewhere located in a single folder. The downfalls? The module you are looking for is somewhere in a single folder. But good luck finding it quickly or efficiently if you have a ton of .fla’s.

So, it seems a better solution is to have these modularized .fla’s in their own folder tree. But how should this be organized? You could come up with some arbitrary folder organization structure that makes sense to you. But then let’s say that you just hired Joe Developer and he found the .as file for a module that he wants to use in a new game. Now although the folder tree that you created for your .fla files seems brilliant in your own eyes, Joe Developer might happen to have trouble understanding it. Now you have to spend extra time training Joe, when a more intuitive solution could take care of this for you.

A better idea would be to have some sort of organizational congruency between your .as files, .fla files, image files, sound files, and video files. For me, and ideal situation would be to navigate to a single folder and it would have everything that I need or is used by the module all in one location. Trust me, you will save yourself tons of time training the new people or remembering ‘where the heck you put that’ down the road if everything is in one place.

So, this is the approach that I went with:

Each level of the major inheritance tree has a folder called “modules.” Within it, there may be a few sub folders, but eventually there is a leaf node folder with the same name as the class that it contains. For illustration purposes, let’s say we had a module called “MyModule.” Inside the MyModule folder, there will be three things:

1. The actual .as file for the class (MyModule.as)
2. A folder called “resources”
3. A folder called “sample”

Any images, sounds, or videos used by MyModule will be stored in the “resources” folder. Easy to find, easy to update.

The “sample” folder will contain MyModuleSample.fla and MyModuleSample.as. This will be the .fla and corresponding Document Class needed to quickly test/alter the module. MyModuleSample.fla will have a folder within its Flash Library called MyModule. The goal is that this folder can be copied out of the Library of the sample and pasted into any other desired .fla as a single, self-contained module.

I’m sure some people might scrutinize me for having .fla’s intermixed with my .as files, but this organization has proven very intuitive for new hires and has made it very easy for them to copy the packaged up Flash Library stuff into a new project. It has also saved me from having multiple folder trees open in my OS or having to move up and down the folder trees more frequently.

As a side benefit, this has made repository management much easier as well. Let’s say I modified multiple modules in various locations, but I only want to commit one of them. I can commit just the MyModule folder and it will grab exactly the files that I want committed along with it–no more, no less.

Hope this helps. Let me know your thoughts…