Online Flash Games & Software Best Practices

Some thoughts on external assets in flash web games.

I’m getting close to finishing porting the first of many games to Flash and ActionScript 3.0 and I’m rapidly discovering that years of computer science wisdom don’t apply in the flash game development and publishing world.

Dorothy I have a feeling we’re not in Kansas any more.It is a widely accepted principle that one should separate data from logic, and all of my desktop games adhere to this tenet. In this instance I am specifically referring to the separation of the game binary and other assets. The advantages in keeping levels, music and to a lesser extent graphics and logos separate from the game itself are many:

• Levels get loaded on demand rather than the user having to download all the content before starting play.
• Additional levels can be added after initial release: bonus levels, sponsor specific levels, reward levels, user created levels etc.
• Any last minute bugs found in a level’s layout can be fixed without requiring a new binary.
• New sprites/bosses/creatures can be added to the game without recompilation and old ones can be updated right up to the last minute before release (or even after).
• Music can be streamed only as it is required instead of requiring the user to download these files up front.

In short, dynamic asset loading brings added flexibility and reduced download times. But like all George Lucas Movies, there’s a dark side to this ideal world:

• Distributing separate files plays nicely when you have an installer and files are hosted locally on a client’s machine. In the nebulous world of web serving you have a world of pain: A failed load during an asset request can kill your user’s experience mid-game. Not a lot of fun. Unless each publisher hosting your game hosts all the files on their servers, cross domain security policies and external site up time can affect players at a different portal. Ugh.
• Furthermore, juggling many files and ensuring correctness of relative paths is fine on one’s own controlled server, but not so fun for third party publishers.

So flash webgames get compiled (and consequently decompiled) in a single binary swf. The proportions of which are bloated by the requirement to contain every asset, and the whole thing is made easier to rip-off, because the swf is stored in the user’s browser cache to be extracted and decompiled at will. I’ll post further ruminations on security some other time.

In the dynamic webscape of the internet it almost seems quaint or archaic to not have a distributed architecture. Imagine if you had to lock all your website into a single package and every time you wanted to add to it you had to recompile?

Some might argue that we shouldn’t need to be able to update a game after release. I mean it should be fully debugged, compiled and perfect on the day it goes live shouldn’t it? Hmmm. In an ideal world that could be the case. But long experience in the software business tells us this ain’t so. The prevalence of live-updates in just about every non-trivial application out there these days is testimony to this fact. And when offering up a game to publishers, sponsors or distributors for evaluation, it would be nice to not have all the levels fully locked in just yet.

But let’s not forget that online games are ephemeral… Like sparks from a fire, they’re fleetingly hot for a moment and then gone. Building layers of expandability is really an exercise in futility when considered in this context. Some of the most popular games on the web are almost trivial: They have only a single brief soundtrack or no music at all, just a single level layout, and compensate for a lack of depth with an addictive mechanic that keeps us coming back for more.

Experienced Flash designers are able to nimbly dance along the timeline, taking advantage of the fact that it’s built to stream assets on demand -graphics and music on frame 100 won’t download until after content that is placed on the timeline in frame 1 for instance. But if you’re like me and come from other programming environments, this whole idea of placing assets on a timeline to defer downloading seems pretty hokey. And how does one put a “level” on the timeline? Manually laying out the sprites that constitute a level is unthinkable for anything but the most trivial game. I’m using the quintessential one-frame movie, and doing everything in code which doesn’t seem to play as nicely with the Flash streaming model.

So the upshot of all this is that I’m looking at embedding my level xml files into my games rather than having each one served dynamically at the end of each level. On the positive side it guarantees there won’t be a load fail, and it makes distribution easier. I may even leave the dynamic level serving capability in the source code so that door isn’t closed for future “special” levels or user content. The xml is effectively compressed in the swf so the total download size is actually less, but the upfront download is slightly more. Apart from the inconvenience of restructuring my source code, this isn’t a big problem – players will just have to stare at the sponsor logo for a moment longer whilst the game is preloading.

Unfortunately for music assets this is much more of a problem. There is no significant extra compression when they’re embedded in the swf, and the user needs to have downloaded all the music for all the levels before the game begins. One approach to avoid this might be to lay the music along the timeline with only the first song placed on a frame before the first level, to take advantage of the built-in streaming in flash, but I’ve yet to figure out exactly how to manage such