Many years ago Apple had a size limit for iOS applications. That limit was 50 megabytes. (Applications could download more data on their own after installation, but the size of the application itself was limited to 50MB.) This sometimes posed interesting challenges.
One game which I was developing had, by necessity, so many graphics that its spritesheets for the iPad took almost 150 megabytes as PNG files, even after running aggressive PNG size optimizers on them. Of course this was way over the limit because of the graphics alone (not to talk about the approximately 10-15 megabytes of sounds, plus whatever the executable binary and other data files took.)
As mentioned above, one possible solution would have been to have the game download graphics from a server after installation. But I decided to go another route: How about using a more efficient image format than PNG?
Lossy compression was not out of the question, but the image format needed to support an alpha channel, which eg. JPEG does not support (besides being just horrible in terms of quality per size ratio). After much research I ended up using the WEBP format. It had everything I needed: Support for alpha channel, superb quality-per-file-size ratio, and a free decompression library.
After implementing WEBP support into the game, and compressing all the spritesheets to that format, aiming for a good file size, I was able to get all the spritesheets fit into a bit over 30 megabytes (down from the original 150 megabytes of PNG files), with no visible loss of quality. After this the entire game fit comfortably within the 50-megabyte limit.
(If you compared some of the resulting images side-by-side with the originals, you could see slight degradation of colors at some places, especially in gradients of red, but the differences were so subtle that you really had to compare side-by-side to notice. Also, decompressing WEBP files is significantly slower than PNG files, which actually required me to implement a "loading" screen when going into a level, as on the slowest iPad of the time it would take several seconds, but that was just a minor nuisance.)
The iPhone spritesheets were already of acceptable size as PNG (ah, those were the times, when iPhones did not have full-HD resolutions...), but since WEBP supports a lossless mode as well, and I had converted the graphics loading to use that format anyway, I converted them to lossless WEBP. Even in lossless mode it still compresses much better than PNG, and I was able to shave off something like 20-30% of their size just like that, with zero loss of quality.
Some time later Apple increased the maximum size of applications, which in principle made those optimizations unnecessary, but I'm still happy and proud of them. After all, isn't it nicer to download a game over three times faster, and have it take less than a third of storage space? Those extra 100+ MB are then free to be used for something else.
Optimizing the size of games is a form of art that was, and is, prevalent whenever the hardware imposed a size restriction. Especially on the 8-bit and 16-bit console era, when cartridge and RAM sizes imposed severe limits, size optimization was a skill, sometimes taken to absolutely brilliant extremes in some cases.
Nowadays, however, this is an almost completely lost form of art and skill. Nowadays a video game taking 50 gigabytes is considered normal. Many games take even more than that (eg. the 2016 Doom takes over 60 gigabytes).
While I don't know much about the internal implementations of those games, I'm convinced that their sizes could be reduced significantly if the developers cared for size optimization, eg. by using more efficient compression formats and other such tricks.
However, nowadays there's little incentive to do that. In most cases games simply use a ready-made game engine (like Unreal or Unity), and the developers simply shove all the graphics into them and have the engine do whatever it likes to those graphics. The graphics engine, and its IDE, is just a black box into which game resources and thrown into, and let do whatever the engine does, without any consideration. (Most likely engines will use lossless compression of eg. textures by default, and not even necessarily using the highest-quality lossless compression algorithms in existence. PNG, for instance, is on this day and age a really poor compressor of images, and much better algorithms exist.)
Size can become somewhat of a limiting factor even on this day and age. Consoles typically have a relatively small hard disk. Even on the PC side gamers are more and more often purchasing SSD drives that are much faster than old hard disks, and they are still relatively expensive, and many people will purchase smaller and thus cheaper drives (such as 128 gigabytes). When you can barely fit two games into your SSD, it can become a nuisance.
One game which I was developing had, by necessity, so many graphics that its spritesheets for the iPad took almost 150 megabytes as PNG files, even after running aggressive PNG size optimizers on them. Of course this was way over the limit because of the graphics alone (not to talk about the approximately 10-15 megabytes of sounds, plus whatever the executable binary and other data files took.)
As mentioned above, one possible solution would have been to have the game download graphics from a server after installation. But I decided to go another route: How about using a more efficient image format than PNG?
Lossy compression was not out of the question, but the image format needed to support an alpha channel, which eg. JPEG does not support (besides being just horrible in terms of quality per size ratio). After much research I ended up using the WEBP format. It had everything I needed: Support for alpha channel, superb quality-per-file-size ratio, and a free decompression library.
After implementing WEBP support into the game, and compressing all the spritesheets to that format, aiming for a good file size, I was able to get all the spritesheets fit into a bit over 30 megabytes (down from the original 150 megabytes of PNG files), with no visible loss of quality. After this the entire game fit comfortably within the 50-megabyte limit.
(If you compared some of the resulting images side-by-side with the originals, you could see slight degradation of colors at some places, especially in gradients of red, but the differences were so subtle that you really had to compare side-by-side to notice. Also, decompressing WEBP files is significantly slower than PNG files, which actually required me to implement a "loading" screen when going into a level, as on the slowest iPad of the time it would take several seconds, but that was just a minor nuisance.)
The iPhone spritesheets were already of acceptable size as PNG (ah, those were the times, when iPhones did not have full-HD resolutions...), but since WEBP supports a lossless mode as well, and I had converted the graphics loading to use that format anyway, I converted them to lossless WEBP. Even in lossless mode it still compresses much better than PNG, and I was able to shave off something like 20-30% of their size just like that, with zero loss of quality.
Some time later Apple increased the maximum size of applications, which in principle made those optimizations unnecessary, but I'm still happy and proud of them. After all, isn't it nicer to download a game over three times faster, and have it take less than a third of storage space? Those extra 100+ MB are then free to be used for something else.
Optimizing the size of games is a form of art that was, and is, prevalent whenever the hardware imposed a size restriction. Especially on the 8-bit and 16-bit console era, when cartridge and RAM sizes imposed severe limits, size optimization was a skill, sometimes taken to absolutely brilliant extremes in some cases.
Nowadays, however, this is an almost completely lost form of art and skill. Nowadays a video game taking 50 gigabytes is considered normal. Many games take even more than that (eg. the 2016 Doom takes over 60 gigabytes).
While I don't know much about the internal implementations of those games, I'm convinced that their sizes could be reduced significantly if the developers cared for size optimization, eg. by using more efficient compression formats and other such tricks.
However, nowadays there's little incentive to do that. In most cases games simply use a ready-made game engine (like Unreal or Unity), and the developers simply shove all the graphics into them and have the engine do whatever it likes to those graphics. The graphics engine, and its IDE, is just a black box into which game resources and thrown into, and let do whatever the engine does, without any consideration. (Most likely engines will use lossless compression of eg. textures by default, and not even necessarily using the highest-quality lossless compression algorithms in existence. PNG, for instance, is on this day and age a really poor compressor of images, and much better algorithms exist.)
Size can become somewhat of a limiting factor even on this day and age. Consoles typically have a relatively small hard disk. Even on the PC side gamers are more and more often purchasing SSD drives that are much faster than old hard disks, and they are still relatively expensive, and many people will purchase smaller and thus cheaper drives (such as 128 gigabytes). When you can barely fit two games into your SSD, it can become a nuisance.
Comments
Post a Comment