How I fit this game into 3 kilobytes

The story as to how I got this game down to 3081 bytes is a long story, featuring MANY tools, as well as a ton of decisions made.

The game started life in 2015 when I was 13 (I am 21 now) as a 30,000 byte HTML file without minification. 30,000 may be small, but at one point in my first year of High School, someone challenged me to make it 2K.

One optimization done was to use multiple rounds of HTML, CSS, and JavaScript minification tools. This got me down significantly.

I also had found 3 unneeded space-hogging double-encoding parts (relating to the bottom two layers and their CSS and JavaScript) that I coalesced into something far more efficient, namely putting the CSS and JS inline, and making those layers stack under the top one more directly. All of the relevant stuff was minified too.

To embed the bottom two layers in a cleaner way, I did a modification to a percent encoder tool whose purpose is to only encode characters that are unsafe, and that’s all it encodes. I ended up making it percent encode a certain character that it normally wouldn’t, to make it compatible with the biggest minification exercise.

To get it smaller, I decided to use SVGZ. To embed HTML in SVG, you need to use something known as foreignObject, and your HTML must be XHTML. Since HTML5 integrated that, as long as we don’t use unsafe-in-XML characters, we are fine. I used SVG minifiers too. The foreignObject is specifically done in a way where it uses the top level html tag rather than the head or body only method I see often. This isn’t a problem.

So, we have SVGZ (gzipped SVG), and it gets us down REALLY small. Can we do better?

Of course.

I originally tried Zopfli, and it worked wonders over GZip Level 9, getting me under 4 kilobytes. Here’s where things get crazy. I used Zopfli-Krzymod, which is a fork of Zopfli with more optimizations, including one ported over from Brotli (Zopfli and Brotli are by Google, Brotli is not DEFLATE but is better). This still remains compatible. By this point (3rd year of high school) the size was 3099 bytes (one byte under 3.1 kilobytes, so 3 kilobytes). But we can do better.

Via running the 3099 byte SVGZ through ECT (something that improves compression without recompressing it), in 2022 I shaved off an extra byte to get 3098 bytes. I had thought for a few months that this was the limit.

But then I heard about Leanify, which ALSO can do this. So I ran the 3098-byte version through Leanify, which shaved off some more bytes.

On encode.su (A site about compression algorithms), people had gotten success by running something through ECT, then Leanify, then ECT again. So I did that, and the size dropped significantly to the 3081 bytes it is now. It’s DEFINITELY under 3.1 kilobytes. So via endless stacking of multiple optimizations via countless tools, I had gotten something that started life as 30 kilobytes down to just three. 3081 bytes is extremely tiny. It is smaller than a modern hard drive sector. It is smaller than a browser cookie. It is smaller than many Atari 2600 games. It is smaller than the amount of RAM on a Commodore VIC-20. It will fit in a Han Xin (China’s answer to a QR Code) or iQR Code (an elusive successor to the QR Code made by the same makers), as well as a JAB Code (a color take on the idea of a QR Code). There are RSA keys (albeit ones that are presently overkill) out there that are larger in size than this.

As for decisions, a lot of them were inspired by the demoscene. I spent years on this project, trying to get it down as small as possible, sometimes in ways I didn’t think were possible. Yet I tried them anyways, and here we are. 3081 bytes.