Game Design
stories, tips, follies,
...and making some $$$ along the way!

AS3 Loaders - Update

Posted by: Sam Horton on Dec 2, 2008 at 3:43 PM

In a previous post, I described a method for making a self-contained loader in AS3. In older versions of Flash it seemed to work great, but after installing Flash Player 10, I noticed some caching issues in IE.

It appears that when using the loadProgress, and loadComplete events on an swf file that has been cached by the browser, the events will never fire because the file is technically 100% loaded. I found this out right after I released my new game Flubber Rise, and had to scramble to find a solution! The game was just sitting there on the loading frame, waiting patiently for some progress to occur.

Luckily it's an easy fix, and it makes the loader code even more similar to the way we used to do things in AS2. Instead of using the loadProgress event to update the loader bar, and instead of using loadComplete to detect when the file is fully loaded, just use an enterFrame event with some really basic code to check the bytesLoaded vs bytesTotal.

This code can be placed on frame 1 along with your loader bar/percent text/whatever you are using:

function loaderUpdate(e:Event):void{
this.removeEventListener(Event.ENTER_FRAME, loaderUpdate);

Again, this issue seems to only affect IE, and not Firefox. I'm not sure about other browsers so feel free to let me know.

Labels: , ,

By: Sam Horton | Dec 2, 2008 at 3:43 PM | | Leave a comment

How to Create a Self-Contained AS3 Loader

Posted by: Sam Horton on Apr 11, 2008 at 12:02 PM

Ever since making the switch to AS3, like many others, I have had to re-learn several routine tasks such as making pre-loaders for my games. After hunting through the Flash CS3 docs and coming to the realization that all of the examples were focused on loading external files, I turned to the mighty Google in an attempt to shed some light on creating a self-contained loader. Most examples just parrot the help files, but after a long search, I've got something that seems to be working exactly like the good old days of sloppy AS2!

If you can get away with loading external swf files, then I have to admit, it is a much more straight forward process, but in the Flash Games Business, it is very important to have everything packaged in one tidy swf file. Many portals will not accept games with multiple files, since they may not work within their existing infrastructure. We don't want to do anything that will prevent our games from spreading virally, so a single swf is best!

First I'll toss the code out there for the folks who want to get right to it. This script goes on frame one of the main timeline, which normally contains some type of loader bar and text display to show the loader's progress.

"myloader" is a movieclip on the timeline
that contains the loader-bar and a text field
import flash.display.*;
loaderInfo.addEventListener(ProgressEvent.PROGRESS, loadProgress);
loaderInfo.addEventListener(Event.COMPLETE, loadComplete);

function loadProgress(e:ProgressEvent):void {
var pct:Number = loaderInfo.bytesLoaded/loaderInfo.bytesTotal;
function loadComplete(e:Event):void {

Nice and simple, but just like a free vacation, there are a few catches. When you want to dynamically create an instance of a Sprite or MovieClip in AS3, you need to give it a linkage identifier just like in AS2. The difference now is that Flash automatically associates a class with this asset; which you can either provide or choose to not worry about, depending on what capabilities you want for that particular asset. You also have the option to export this asset in the first frame, which will cause it to load before our preloader.

In the image above, I have an asset called "Eye" which has "Export for Actionscript" checked, as well as "Export in first frame". If I wanted to create an instance of the Eye, I would just write something like this:

var myEye:Eye = new Eye();

...which is much nicer than the old attachMovie() from the AS2 days!

In many cases choosing "Export in first frame" is fine, but do this with enough assets, especially if they are large, and you will wind up staring at a blank screen while these assets load (before your preloader). To remedy this, I always try to un-check "Export in first frame", and never associate classes directly with my library assets from the linkage menu. Instead, I write custom classes that instantiate any Sprites or MovieClips I need; and in all reality, this allows for more flexible coding. I like to think of these as wrapper classes. For instance, say you are writing a particle engine class that needs to utilize many different Sprites. It wouldn't make sense to have the class directly associated with only one particular Sprite. It's best to think of these display objects as just a visual representation on screen, and not as the object that is containing and managing the code.

If you un-check "Export in first frame" then you will need to manually place these assets somewhere on screen, otherwise they will not be included along with your published swf file. The work around for this is the same as what we have already been doing for years. Just create a MovieClip with these assets inside it, and place it off screen. For sounds, make sure to create an extra frame that the playback head will never reach,(unless you enjoy hearing all of your sounds play simultaneously) then use the property window to add them to the timeline with start as the sync setting. See the image below for details:

So far this has worked like a charm, and I've done quite a bit of testing during the development of my new AS3 titles.

And just because we need something fun in this post, here is the source for the movie below, which demonstrates everything we've talked about. If you want to use the explosion animation in your games, then by all means, have at it. It was created in Lightwave, and I've been using it for years!

download source

Labels: , , ,

By: Sam Horton | Apr 11, 2008 at 12:02 PM | | Leave a comment