In AS3 projects, you often need to load external assets like images and other SWFs. While loading these assets you have to keep track of several events for successful execution of your application. You might have been using some of these events like ProgressEvent, COMPLETE event. This tutorial shows you how to get info about the assets you’re loading with Loader.load(), using its associated events, all in one place. So if you’re having difficulty loading such assets, or you have less time in hand to debug, take a look at this.
(Preview image courtesy of VisualPharm.)
Final Result Preview
Let’s take a look at the final result we will be working towards:
This SWF loads an image, showing details about the loading process (progress, whether it’s complete, and more).
It won’t work embedded in this page (which shows you the responses in case of error) but it will work if you load the SWF directly.
Step 1:The need to load assets
Hey, if you are in a hurry, you can skip this step. But, if you are relaxed, with a cup of coffee in hand, have a read.
In the early days when I started learning Flash 5 and AS1, I used to have all objects on the stage at once, and made them visible/invisible as required. Eventually as I started developing apps, I became more familiar with Flash’s system. Wow, now I was able to use “linkage identifier” to load objects from library. Getting more advanced, I soon realised the need for external assets. But unfortunately, there was no such powerful architecture. Meanwhile, Flash was going through drastic changes. Now “AS2″ was capable of loading external assets. Finally, when it lined up in Adobe’s family, the new event-based architecture “Action Script 3.0″ was introduced. In AS3, the need for loading external assets is much better addressed than in AS2.
So, when working with Flash we have three ways to manage our assets:
- Put all required assets (MovieClips with instance names) on the stage and manipulate them as required.
- Put all required assets in the Library and access them using “Identifier” in library panel.
- Put all or some required assets outside Flash and load them dynamically.
The first method is not versatile. As the number of objects increases, the size of the SWF also increases (especially when there are lots of images). Imagine how much time it can take to load on user’s machine? Also, the performance of your application might degrade. But, still it can be handy enough for creating lightweight apps. (E.g. developing a simple game, in which player needs to find out key objects from the given image).
The second method is very much similar to the first one. Instead of having objects on the stage, now they are residing only in the library. Again, if there are lots of objects, then the issues with the SWF’s size and performance remain. But with this approach, you can easily create multiple instances of objects. Plus, the objects are much easier to handle than the first method. (E.g. games like “Tic Tac Toe”, “Tetris”, and “Snake” can be developed as they require fewer objects).
The third method (loading assets externally) is much more flexible than the first two. The power of this method is, without having a single object in the library you can still develop big games (e.g. “RPG” style games). As objects are loaded externally, they are loosely tied to your main SWF, so you do not have to go back to Flash every time you want to replace or edit your assets. One more advantage of this method is, it allows you to load and display objects on an “On Demand” basis. Meaning, you can load your objects only when they are required and unload them when you are completely done. (E.g. if your game has 10 levels, then you do not need to load all assets needed for all 10 levels. Instead, load and unload them level by level.) Thus, the overall performance of the application is improved.
Note: The above “On Demand” method may not be suitable in case where assets are loaded and unloaded frequently (e.g. in an image viewer app).
Okay, so now we can conclude that, of the three methods, the third one is more flexible. But, as the system gets more advanced, it becomes more complicated to manage. Similarly, if you decide to go with third method, you will need to handle assets as one separate operation. You may call it “Asset Management” which can be divided into two parts:
- Handling assets manually (involves folder structures and operations like cut-copy-paste)
- Handling assets programmatically (involves loading, displaying, and unloading in a program)
This tutorial covers the second part, so let’s look at that now.
As our program loads assets externally, it is now dependent on those assets. If any of our assets fail to load for some reason, then our entire application will be hampered. To avoid such failures, we really have to provide “Decision Making” power to our program.
Here’s one example. You have a coin-flipping game, where the coin is an externally loaded image. Now, if this image fails to load, then what next? This is the perfect point where your program will take some decision(s). It might load another image for the coin, stored as a proxy. It might load the stand-by coin if you have placed it in the Flash library. This can be a lightweight coin made up of vector graphics and strokes converted to fill to keep the size of the main SWF as small as possible. If you do not plan to have stand-by coin, then your program could warn the user about failure.
Of course, this was just one case. For a complete game, you will need to use a mature “Asset Management” system.
Read more: Monitoring the Loading Process in Flash With the Loader Class
No comments:
Post a Comment