5. Minification and size constraints
- Genesis. From the idea to the design
- Architecture and framework
- Critter tasks and animation
- Level design and display
- Minification and size constraints
Constraining everything below 13k is definitely the biggest difficulty in the contest. One needs to organize the development process as to focus on this goal at all times. Aiming for 13k, and checking on a regular basis that you will be within target, is easier and less frustrating than having to cut features at the very end, not to mention the panic involved in the latter case.
I usually organize my work around a feature list, that doubles as a to-do list. Features are sorted by decreasing priority, and roughly sorted into 4 categories. Completed features get a pen stroke but stay on the list, as being able to see the progress achieved is a morale booster.
- "done" : feature already coded.
- "must have" : features that I will never ever cut, unless really coaxed to do so
- "nice to have" : features that I really want to include, but that could be left out when running out of space
- "could have" : features that I have imagined along with the game, but that are definitely not mandatory for the game experience
On a side note : polished graphics, even simple ones, are definitely on the "must have" list. A game with plain or crude graphics is unlikely to make it to the top 10. Sound effects also belong to the same category, only a bit lower.
I draw a line between features that will be in and those that will be left out. It starts right between the "nice to have" and the "could have", and moves up or down every time I reevaluate the size of the project.
Many experienced coders have automated the grunt work to produce the final zip with a single command, and usually do so at every commit. I don't - I still create the zip manually, although I should definitely consider automating the process before the next edition begins. Because of the amount of manual work involved, I only check the zip size every now and then - every week at the beginning, daily near the end. However I have a rule of thumb that helps me assess the final size : 10kb of commented code = 1kb of zipped, minified code
I thus know that I can ramp up the code up to 100 kb then add music afterwards and still be within bounds. If you have images, they are already compressed and zip will not do much to shrink them further, so to be on the safe side, you should count them for their actual size, although some tricks apply (see below). Here is the memory split for Pest Control : Weasels :
Remember, js13kgames is not js1k, you cannot optimize every byte. The code style I fancy for this type of contest is a mix of clean design and minimal implementation :
- design classes, but drop abstract interfaces. There is no point in leaving extension points for later.
- code what you need now, not what you may need in the future, especially for features that may get abandoned.
- refactor for clarity, to optimize speed or size. Not to improve the design, unless the code really starts looking like spaghetti (but you usually do not get things that tangled in 13kb)
- code for the packer. js1k contestants using jscrush or RegPack are familiar with that : leave redundant code instead of trying to refactor it into a function. Yes this is a dirty coding practice, but it helps getting a smaller zip archive.
Even with paying a constant attention to the final size, you may go slightly overboard. I had stopped adding features at around 75kb, hoping for 8kb after compression. There was supposedly enough room left to add the sprite sheet and music but, once they were in, the archive clocked at 14.3kb. Whoops. This was annoying, but still manageable. There are a few tricks I used to get back below the threshold.
Code minification : Google Closure Compiler with Advanced settings does an awesome job at cutting bytes, renaming variables and reorganizing code as needed. I have experienced a few issues with it though, such as having it incorrectly rename methods from AudioContext. It also sometimes ignores some obvious optimizations. To address the lastest point I fed the output to Javascript-minifier, which for PC:W gained an extra kilobyte out of a total of 27.
Images : first, try to reduce the color space as much as possible. You probably do not need the full RGB space, 256 colors should be enough. Or even less if you have opted for a retro look. The spritesheet in PC:W uses only 16 colors. Then, use one of the image minification tools around. There are a few online that will yield a smaller image with no apparent losses (they strip headers, remove optional fields, reduce the color space as needed, and probably other magic tricks that I do not imagine now). I got the best result with compresspng.com, but your mileage may vary. Here is a summary of the compression tests on the sprite sheet.
Zip archive : before you get to the final compression stage, try to inline as much as possible. Ideally all your css and Javascript should be contained in the index.html file. Only the images can have their own files (and if possible, only one image). The reason is that files must be included from the main index (cost to call the include), and incur an extra header in the zip archive (cost for the header). Among the different zip tools, Ken Silverman's Kzip stands out, consistenly creating a smaller archive than the other options :
If after all these steps you are still below 13kb with some time left, create a tag or baseline in your version control tool (you ARE using one, aren't you ? If not, install git, you have to submit on github anyway) so you can revert to that point if something goes bad. Then you can resume adding features as you like.
120 revisions after the first prototype nicknamed "Evil Lemmings", Pest Control : Weasels was ready to be submitted. Of course, it was far from perfect, and there were a few issues I was (and still am) unhappy with, but the upcoming deadline did not give me much opportunities for improvements. The feedback I got is that the levels are of uneven difficulty, too simple on the whole, and that the game is too short.
Stay tuned. There will be - at least - a second release with extra levels, that will not be constrained by the 13k limit, although it should still be lightweight. And diggers will be back. Hope you will like it even more than the original.
- Genesis. From the idea to the design
- Architecture and framework
- Critter tasks and animation
- Level design and display
- Minification and size constraints