Question

I’m building an Adobe AIR application (2d platformer adventure game), utilizing the Flash Builder 4 IDE, which will be packaged on a CD for installation. I’ve embed the majority of the game assets into a static class to keep it simple and organized. This way I can reuse assets and swap them without much digging.

example:
[Embed(source = “../data/gfx/spritesheets/boyHero.png”)] public static var boyHero:Class;

In the early days of the projects, everything went to plan. However as the project has grown to be over 28MB, I’ve started to run into Out Of Memory errors. These occur when I add new assets, refactor for a while, or add new classes. Once I get this error, I can restart FB and then work for another 15-20 minutes.

I’ve modified my .ini file bump up Flash Builder 4’s memory allocation. It’s currently set at:

-Xms512m
-Xmx1024m

While I’m at it, here are the specs/plug-ins that I’ve got installed:

Flash Builder v 4.0 (build 272416)
JNA Library 3.2.7
subclipse plugin 1.6.17
subversion client adapter 1.6.12
subversion JavaHL Native Lib 1.6.15
SVNKit lib 1.3.5.7406

Mac OSx v 10.6.7
2.53 GHz Intel Core 2 Duo
4GB DDR

My Questions:

1) Is the issue with the path that I’ve chosen for the way I’m handling in-game assets? I am streaming in some assets such as tutorial swfs which are loaded via the SWFLoader. I could go this route for all assets… but, should I? Is this the right way to handle a disk game? (The game runs without a hitch when installed on QA machines…)

2) Provided the embeding of static assets isn’t an issue, Is this a FB4 bug? Where should I head for more information?

Thanks very very much in advance!
-J.

Answer 1

it sounds to me like it’s time to break up your assets into separate files and load them at runtime from the disk. That should free up some space while you’re editing code so that FB4 doesn’t freak out. I just finished a Facebook game that had a ton of assets, and I ended up putting all of the sounds in their own SWF, all of the heavy graphics in their own SWF, and then loading them up at runtime. Here’s a breakdown of the key points :

For me, I was using Flash CS5 to generate the assets, and exporting the symbols for actionscript in the first frame. I’d just export the movie, Flash would hand me my assets SWF, and I was good to go. Alternatively, you could have simple AS file with a ton of embed tags and compile that to it’s own SWF using ant or FB4. It’s really the same thing at the end of the day as long as you get your assets into a SWF.

This way, instead of having a file full of Embed tags living with the rest of your game logic, you have a file full of symbol names, so that you can get them when you need them:

//GraphicalAssets.as

//the linkage for this asset in your asset swf would need to match 'hero_guy_graphic'
public static var HERO_GUY_GRAPHIC:String = "hero_guy_graphic";

And somewhere you also hold onto the asset file names:

//AssetFiles.as

public static var CHARACTER_ASSETS:String = "thePathToTheCharacterAssetsFile.swf";

Before I continue, it would be a good idea to put the functionality I’m about to describe into some sort of AssetManager class. You don’t want to load a file every time your game needs an asset, so an AssetManager class gives you a place to hang onto assets until you’re sure you’re done with them. (you probably already knew that)

Anyway, when you decide you need those assets in your game, you load them up using an instance of Loader (presumably, somewhere in the AssetManager class) :

var loader:Loader = new Loader();
var loader.contentLoaderInfo.addEventListener(Event.COMPLETE, handleAssetsLoaded);
//add some error event listeners here too...

var request:URLRequest = new URLRequest(pathToMyAssetsFile);
loader.load(request);

In the handleAssetsLoaded function, you hang on to the applicationDomain object of the loaded SWF. The applicationDomain is your access point to all of the symbol definitions in the SWF.

private function handleAssetsLoaded(evt:Event):void {

    //hang on to this for later         
    var appDomain:ApplicationDomain = (evt.target as LoaderInfo).applicationDomain;

    //a good way to do that would be have a private array where you hang on to them
    //_appDomains["TheNameOfMyAssetFile.swf"] = appDomain;

}

Then when you want to get a particular asset, you would use some sort of getAsset() method:

public function getAsset(assetName:String, fileName:String):* {

    var assetFileAppDomain:ApplicationDomain = _appDomains[fileName] as ApplicationDomain;
    var assetClassDefinition:Class = assetFileAppDomain.getDefinition(assetName) as Class;
    return new assetClassDefinition();

}

And finally, when you want to get HeroGuy in your game, you have some call that looks like this:

//assuming AssetManager is a singleton that we can get with AssetManager.instance ...
var heroGuyGraphic:MovieClip = AssetManager.instance.getAsset( GraphicalAssets.HERO_GUY_GRAPHIC, AssetFiles.CHARACTER_ASSETS ) as MovieClip;

Hopefully that’s enough to get you on the right track. Most of the time when I’m loading an asset file at runtime it’s over the web, but I don’t see why it shouldn’t work to apply the same technique to getting assets from the disk. Let me know if you have questions – I’m sorry if I wasn’t terribly clear, I assume you know enough to fill in the gaps 🙂

Good luck with it!