Flash portals and version control

Hello and welcome back to my blog!

This article is about version control when releasing a game onto the various Flash portals.

Portals

A portal is a web-site which concentrates on hosting a large quantity of Flash games.

The prolific nature of the Flash portals is one of the major reasons to chose Flash as a platform for your next web-game. There are a lot of very popular portals on the internet. The top three alone in this list in mochigames has a daily page-view count of over 17M views, and there are well over 100 portals in that particular list.

Page-views for miniclip.com

Alexa rank was converted into page-view estimates by this Wolfram-alpha widget.

If your game is good, it can organically spread to many more portals across the world (as new portal owners effectively and fortuitously ‘steal’ the game and host it themselves on their own sites), garnering the sort of exposure that would cost an absolute fortune if you had to pay for the equivalent through advertising.

Version control

All this exposure is great, but it does pose a significant problem especially if your game is multi-player – that problem is version control.

Once you’ve released your game into the world, it may not actually be really finished. This can happen for a number of reasons:

• The game is in alpha/beta
• Bug testing was not thorough enough
• Your game is a service, not a product and is continually evolving (i.e. long form multi-player games, like MMOs) and needs to stay synchronised with server-side code

The problem arises when you consider the shear number of portals that you would manually have to update when a new version of your game is released. Even if you could manage that you would never know all the portals which host your game due to organic distribution.

Boot-loaders

The answer to this problem lies in the way you distribute your game. The likelihood is that your game will require some kind of boot-loader anyway – after all, who wants to look at a black screen while your game’s main .swf loads up?

The Wildbunny boot-loader

A boot-loader is a tiny .swf which displays your game’s (or sponsor’s) logo along with a progress bar as the actual main .swf is downloaded.

The smart reader will have realised the potential here – if you have access to your own server, you can simply point your boot-loader at the latest version of your game (on your server) and only upload the boot-loader itself onto the portals.

However there is a problem.

Browser caching

Rather intelligently, web-browsers are designed to cache files locally which they have already previously downloaded, so that subsequent visits are fast. This is great, and save’s a massive amount of bandwidth, but it also presents a problem.

Even with a boot-loader, the main .swf which is being downloaded from your server will be cached locally in the browser and so when you update your game, it will not get downloaded again.

The solution lies in HTTP headers.

Cache control and HTTP headers

If you google this problem you will find literally pages of people describing how to ‘solve’ this issue by having your server return special HTTP headers along with the response for the .swf which instruct the browser not to cache the result. However, this solution is quite ham-fisted because it will massively increase the amount of band-width taken by your game, which will cost you money in hosting charges.

A better way is to issue the Last-Modified and Cache-control headers along with the response.

Last-Modified allows the client to store the time you send them for later comparison on the server. The client will send an If-Modified-Since header to the server which contains the time they received on the first request.

The server can then compare that time against the time-stamp on the file and either issue a HTTP 304 Not modified response if the time-stamps match, which will instruct the client to use the cached version, or the server can send the new version of the file along with the new time-stamp if the times don’t match.

Cache-control and HTTP headers.

Here is the relevant server-side code, for apache in php, modified from this stack-overflow answer:

<?php
// Swf under version control.
$fn = 'Lobby.swf';
 
// Getting headers sent by the client.
$headers = apache_request_headers();
 
// Checking if the client is validating his cache and if it is current.
if (isset($headers['If-Modified-Since']) && (strtotime($headers['If-Modified-Since']) == filemtime($fn))) 
{
	// Client's cache IS current, so we just respond '304 Not Modified'.
	header('Last-Modified: '.gmdate('D, d M Y H:i:s', filemtime($fn)).' GMT', true, 304);
} 
else 
{
	// File not cached or cache outdated, we respond '200 OK' and output the image.
	header('Last-Modified: '.gmdate('D, d M Y H:i:s', filemtime($fn)).' GMT', true, 200);
	header('Content-Length: '.filesize($fn));
	header('Content-type: application/x-shockwave-flash');
	header('Cache-control: must-revalidate');
	print file_get_contents($fn);
}
?>

Note: there may well be a cleaner way to do this using http_cache_last_modified() in php, points to anyone who can confirm this!

One caveat is that the header Cache-control: must-revalidate has to be set in order for Flash to obey the Last-Modified tag. I found that the browser would obey it without this, but Flash will not.

Obviously using this technique will require more server-side processing than a straight file download, but the benefits will outweigh the downsides.

Alternatives

For those who don’t have access to their own server, some companies provide a similar service with their own file hosting, such as player.io, although you have to pay for the band-width you use.

That’s it for now, until next time: have fun!

Cheers, Paul.