Search the Community

Our company has developed, and is continuing to modify, a container console for wrapping around html5 games for mobile and desktop distribution, and one of the concerns we face, is to minimise the amount of time and traffic it takes for an end user to download the latest version of games, especially when it comes to bug-fixing of games. We are already working with a number of development houses to write exclusive content before we start opening this out to the wider audience (i.e. we're ironing out the bugs before we let others break it :-) ). As part of this, we are looking at asset-revving. We find that between incremental fixes of games, the majority of the spritesheets, background images, and audio doesn't change, just the game logic in the JS files themselves. Some of these games can stretch to 10s of megabytes in size (especially when delivering for high definition devices like Retina's or Desktop machines), and having a user download all of these assets again, for a bug fix is not in their best interest, or ours as a distributor. Where filenames are being explicitly declared in javascript files, this is a relatively trivial task to conduct a replacement in the code prior to deployment onto webservers, but in the case of game engines like Phaser, this code is currently squirrelled away deep in the guts. Where this becomes even more of a problem for us, is when the javascript does device detection, and dynamically generates the assets path based upon the device support (i.e. ogg vs m4a, or high definition images instead of low definition images). At this point, it becomes incumbent upon the developer to consciously to have to handle asset revving, by applying a mapping of their desired file name and path, to the actual file, if indeed that file has been revved (or if the revving has been conducted). I would like to get to the point where the game developers do not have to concern themselves directly with this, except for some preparation at the start of their game, to pass in any externally defined rev map to the game engine, and have the game engine itself conduct mapping of the content under the hood. For example: myGame.load.audio('default-background-music', 'audio/music/Default.mp3'); myGame.load.atlasJSONArray('texts', 'img/' + resolution +'/dialogues/texts.png', 'img/' + resolution + '/dialogues/texts.json'); myGame.load.atlasJSONArray('hint', 'img/' + resolution +'/animations/hints/tile-hint.png', 'img/' + resolution +'/animations/hints/tile-hint.json'); The first asset here is easy enough to rev out as it is explicitly defined, but the second and third assets are dynamically chosen by the variable resolution, and the files contained within each will have very different revved filenames, because their content will be different (for example texts.png for a hd resolution will be bigger and therefore have a different MD5 to texts.png for an sd resolution). I could resolve this with a call to a rev mapping function, but this would be for every single line in the code where assets are obtained.myGame.load.audio('default-background-music', getRevMapping('audio/music/Default.mp3')); myGame.load.atlasJSONArray('texts', getRevMapping('img/' + resolution +'/dialogues/texts.png'), getRevMapping('img/' + resolution + '/dialogues/texts.json')); myGame.load.atlasJSONArray('hint', getRevMapping('img/' + resolution +'/animations/hints/tile-hint.png'), 'img/' + resolution +'/animations/hints/tile-hint.json'); But this requires a lot more to be concerned with by the game developer, and is prone to error (note how in the third example I have accidentally not added the getRevMapping to the json file). Further, as a developer, I would have to write a rev mapping function, repeatedly for each game I develop. What would be better is if the game developer could continue to request the names of the files they are expecting, and have a small initial configuration prior to loading assets for each distributor as is required. We have looked at this, and one method of approaching this is inside our library we expose to the developer, we can dynamically alter the low level Phaser.Loader.load function, so that we can re-map the files on the fly: phaserRevMapReplace:function(game){ var loader = game.load; var originalLoadFile = loader.loadFile; loader.loadFile = function() { var file = loader._fileList[loader._fileIndex]; if (file) { file.url = map(file.url); } originalLoadFile.call(this); }},map:function(url){ if (ourLibrary.revMap) { return ourLibrary.revMap; } else { return url; }}... phaserRevMapReplace(myGame); myGame.load.audio('default-background-music', 'audio/music/Default.mp3'); myGame.load.atlasJSONArray('texts', 'img/' + resolution +'/dialogues/texts.png', 'img/' + resolution + '/dialogues/texts.json'); myGame.load.atlasJSONArray('hint', 'img/' + resolution +'/animations/hints/tile-hint.png', 'img/' + resolution +'/animations/hints/tile-hint.json'); But the problem this makes, is that we end up tying our library code to a very specific set of versions of phaser, and any changes to phaser's loading mechanism will likely break our code. Instead, I am going to fork Phaser, and suggest to merge changes back in to Phaser if approved, whereby the game developer will only need to pass any rev mapping object (a map object like revmap['audio/music/Default.mp3']='revved/audio/music/Default.abc123ef.mp3';) to the Phaser.Loader, and this will be used by the load method internally if defined, or silently work if not.