Flash portals and version control

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.

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.

<?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');printfile_get_contents($fn);}?>

About Paul Firth

A games industry veteran of ten years, seven of which spent at Sony Computer Entertainment Europe, he has had key technical roles on triple-A titles like the Bafta Award Winning Little Big Planet (PSP), 24: The Game (PS2), special effects work on Heavenly Sword (PS3), some in-show graphics on the BBC’s version of Robot Wars, the TV show, as well as a few more obscure projects.
Now joint CEO of Wildbunny, he is able to give himself hiccups simply by coughing.
1NobNQ88UoYePFi5QbibuRJP3TtLhh65Jp

Search

Search for:

Choose a category

About the author

A games industry veteran of ten years, seven of which spent at Sony Computer Entertainment Europe, he has had key technical roles on triple-A titles like the Bafta Award Winning Little Big Planet (PSP), 24: The Game (PS2), special effects work on Heavenly Sword (PS3), some in-show graphics on the BBC’s version of Robot Wars, the TV show, as well as a few more obscure projects.
Now joint CEO of Wildbunny, he is able to give himself hiccups simply by coughing.
1NobNQ88UoYePFi5QbibuRJP3TtLhh65Jp