Archive for June, 2007
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:
- Create a new .fla and the associated Document Class.
- Copy in all of the previously developed modules into the Flash Library or Stage as needed.
- Re-skin these modules where necessary.
- Write an inherited class for any of the modules that do not exactly fit my current needs.
- Import all of the necessary module packages in the Document Class.
- 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:
- The actual .as file for the class (MyModule.as)
- A folder called “resources”
- 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…
I got tired of writing the Bitmap and Sprite Conversion code in AS3 multiple times and finally decided I’d write a small utility that would easily do this for me.
Let’s say you have some some Sprite on the stage called _mcSprite that you want to become a bitmap, then you would do the following:
[as]var tmpBitmap:Bitmap = DisplayConverter.spriteToBitmap(_mcSprite);[/as]
DisplayConverter.bitmapToSprite() is also included. Both functions include an optional second parameter if you wish to enable smoothing.
Get the open source class here.
I just realized that the spriteToBitmap function did not maintain the transparency of the original. This is because the BitmapData constructor defaults the fillColor to opaque white instead of transparent. This can be fixed by setting the alpha byte of the ARGB hex code to “00″ instead of “FF”. For example:
[as]var bitmapData:BitmapData = new BitmapData(sprite.width, sprite.height, true, 0x00FFFFFF);[/as]
The class in the download link above has been updated with this issue resolved.
I just spent the last 30 minutes wanting to pull an Office Space on my computer. It all boiled down to odd behavior related to setting the class path in Flash CS3. Allow me to save you from a similar frustration:
Let’s say I have an .fla located in “com.natejc.display.utils”. Since I’ll be using other classes in different packages, I set my class path to “..\..\” to get me back to the “com.natejc” level.
Now let’s say that this .fla contained a MovieClip in the Library that was linked to a class called “ImageLoader” in the “com\natejc\display\utils\” folder. So, I naturally set the linkage properties of this MC to “com.natejc.display.utils.ImageLoader”. Upon compiling, Flash kicks out the following error message:
5001: The name of package ‘com.natejc.display.utils’ does not reflect the location of this file. Please change the package definition’s name inside this file, or move the file. C:\src\com\natejc\display\utils\ImageLoader.as
What!? Yes it does! They match perfectly!! Well, I finally discovered that if I moved the ImageLoader.as file to any other location and changed the linkage appropriately, everything worked great.
Conclusion: If a class lives in the same location as the .fla file, the linkage is always simply the class name without any package prefix, regardless of what your class path is set to or how deep the file actually exists within this path.
However, this means that the movieclip in my library can never be copied and pasted into a different library without someone remembering to change the linkage. C’mon Adobe, even if it is in the same folder, I should still be able to utilize my class path and specify the full package in my MovieClip Linkage.
On Tuesday (May 22, 2007), Mika Palmu, Philippe Elsass, and Nick Farina made an alpha release of the next installment of my favorite ActionScript editor, FlashDevelop. Somehow, I missed that they released the beta last night!
I tip my hat to the guys that made it. Considering it’s a free editor, it’s pretty darn good. I have a few rants and items on my wish list that I’ll get into in a moment; but all in all, these guys could easily sell this product and yet they offer it for free. I’m surprised Adobe hasn’t hired them to save their horrible IDE in Flash CS3 (yeah, yeah, it’s improved… but for a company of their size and the number of years that Flash has under its belt, it should be significantly better than it is). Anyway, if you like and actively use the product, you should support them. If you are still using the Flash IDE to write your code, please, make your life easier and install FlashDevelop.
There is finally expanded keyboard shortcut support to allow utilization of keys such as ALT and PageDown.
Viewing multiple code files simultaneously in a split screen mode is even easier which can be seen here:
The Find & Replace is much better than it was in v2, but I wish it had a “replace within selection” option…
The code snippets have all been moved to individual external files. The best part is that they are now language specific! This means that I can have two different snippets, with the same name, but with completely different functionality depending on the language that I’m currently working in. There are a few $(EntryPoint) parameter oddities within snippets, but I expect they will fix this before the final release. Unfortunately, my biggest desire for FlashDevelop, more than anything else, still hasn’t been implemented. That is support for custom snippet parameters that can be changed in a popup dialog on the fly with default values. The SE|PY ActionScript IDE (also a great editor done by Alessandro Crugnola) has offered this feature for quite a while. See the screen shot below for how it works:
Configuring many FlashDevelop settings (but not all) or installed plugins is much easier with the new settings GUI:
The code completion is outstanding. The crash recovery seems to work fairly well (but I noticed a couple of oddities). The new integrated browser works okay, but it is in dire need of forward and back buttons (I wouldn’t even use this browser if it weren’t for the one click access it has to the online FlashDevelop documentation wiki).
All in all, FD is still my favorite (free) AS editor, and FD3 is a nice next step. If they add support for custom snippets, I would be as happy as Google was to locate E.T.