Blue Mammoth Games Games Dev Blog About Us Contact Homepage

Sunday, October 17, 2010

Runtime Shared Libraries, Preloading, and Dynamic URL Versioning

The idea behind Runtime Shared Libraries (RSLs) for Flash is great. Multiple swfs sharing library art are now much smaller because the shared library only has to be loaded once. Unfortunately, in practice they have been a headache for us to work with.

Problem One: Application Domains
The first part of the problem is that we need to load each game level into it's own application domain to prevent namespace problems. It turns out when you load something that loads an RSL into it's own application domain, the RSL seems to be loaded into that application domain. Unfortunately, when it is time to load the next level, Flash thinks that you have already loaded the RSLs, and does not reload them, and your level cannot load because it cannot find the definitions of anything in the library.

Solution: Preloading
We solved this problem by preloading the RSL into the global application domain before the level ever gets loaded. It takes away a bit of the magic of RSLs because you have to manage the preloading by hand, but it was the only solution we could come up with because of the way application domains work.

Problem Two: Dynamic URLs
To prevent the browser from caching our files, we use the get parameter trick to make the browser think the file is completely different (Ex: Library.swf => Library.swf?v=21). This works great, except for the way that RSLs get preloaded. The import statement inside the flash file says the symbol is coming from Library.swf, but we loaded Library.swf?v=21 during our preload. The game still runs fine, but the server ends up getting two requests for Library.swf, and neither is cached. One from when we are preloading, and the other from when the level is loading and automatically requests the library. Unfortunately, you have no control over how the automatic request is done, and updating the fla every time you change versions isn't a viable solution.

Solution: Madness
Our solution for this problem is crazy, and it works because of what seems to be going on under the hood during RSL loading. The RSLs get loaded to make sure all the definitions are in place before the actual file you are loading gets loaded, but it doesn't seem to care where they came from. Before we upload, we renamed Library.swf to Library_vX.swf and replace Library.swf with an empty swf. We preload Library_vX.swf so that all definitions are in the application domain when it is time to load the level. The level automatically requests to load Library.swf, which is now replaced by our dummy swf, and everything ends up working just fine. We then manually rename Library_vX.swf as we version it.

Our only hope is that Adobe gives us more control over the RSL process in the future, but for now our problems seem to be solved.

1 comments:

  1. Good read.

    Fundamentally rsls are little more than definition containers-if you load a normal swf into a particular application domain, any classes compiled into that external swf are now available-unless there is a name conflict with an already loaded definition.

    ReplyDelete

 
© 2010 - Blue Mammoth Games, Inc.
Footer