After I wrote Block Dominoes game I decided to look into optimization of the assets, compress whatever could be done and make the game as lightweight as it could be.
I had designed and made the assets at a resolution of 1920×1080. The first logical step was to go search what other developers were doing and surprisingly 1920×1080 seemed quite a big resolution to choose for a game.
There was an older discussion on HTML5GameDevs.com which suggested using a lower resolution such as 320×480 which many devs have been using successfully. I decided to go for half of what I initially designed so I reduced all game assets to half of the original size which was 960×540. The size of all graphical assets were reduced by 40% which was a very good saving. Interestingly there was no visible difference on look and feel of the game when I tested it on iPhone6, Nexus 5 and Lenovo Tablet in addition to the desktop. This is the most important step in a game development. Choose the most appropriate resolution for a particular game. Going for higher resolution does not make any noticeable difference to look and feel of the game on mobile devices so if the game is primarily being targeted for mobile, we may just get away with going for a lower resolution. Sometimes a certain texture would look exactly same on most resolutions so its something to ponder over when the game is still at design phase.
Another hint while deciding on game size is to look at viewport meta tag in your game HTML. If you are not using this meta tag then on mobile you will get the actual pixel size and in that scenario devicePixelRatio has no impact on how the game looks on mobile. If viewport meta tag width is set to device-width, then you get CSS size in your responsive game which means you are scaling down all assets to a much smaller size. In that scenario it makes sense to design game for smaller resolutions such as 320×480 or may be slightly higher resolutions for latest devices. Another option is to load different assets for desktop and mobile. There is no need to necessarily differentiate between desktop or mobile, it actually comes down to what width and height do you see in your responsive game and can accordingly load different set of assets (in my case assets optimized for lower size such as 480×320).
Once we have fixed the resolution, next few important things to optimize would be
- Compress images – This saves a lot of space and again with very little visible difference. I use tinypng.com but there are many good compressors available online.
- Compress audio files – A lot of times we just ignore optimizing audio files, or probably are not even aware that such a thing can be done. I would advise to go through this tutorial. This explains a lot of things game devs should know about optimizing audio assets.
- Compress JS files – A lot of times we just obfuscate the code and forget to minify. A lot of obfuscators would also minify the code. I was able to reduce size of my game code by almost 30% by compressing the obfuscated code on https://jscompress.com so we need to remember obfuscation and compression are two different things and its always a good idea to compress an already obfuscated code which might just save some more bytes.
Now I am going to throw some numbers on what exactly did I achieve by doing all this.
Original size of all images I used for 1920×1080 version of the game was 739 KB. After I compressed the images on tinypng.com, it came down to 289 KB. Quite a lot of saving without much visible difference. After I reduced the resolution to 960×540 and reduced the size of the images, the final size of all images came down to 125 KB so quite a lot of bandwidth saved here.
Audio assets were compressed from initial size of 190 KB to 100KB.
JScompress brought down size of the code from 118KB to 83KB.
Final game size was 1.06 MB for 960×540 resolution and it seems like phase.min.js is taking almost 70% of everything else I have. Off course there is an option to go for modular build in Phaser where I could remove a few modules which are not used in the game but that will come later when I have a thorough understanding of all modules in Phaser. Until then I am happy with the space saved which is almost 50%.
I shall update this blog further if I ended up using custom built Phaser lib after removing certain modules (I am thinking may be one of the physics engines not used in the game).