Hacker News Reader

Comment by lifthrasiir | Hacker News Reader

For the record, this year's js13kGames [1] has just started days ago and will continue to run until September 13. :-)

I love the idea of tiny games as a constraint to keep scope sensible. But I worry this is actually a code golf competition. I wonder how many entries are just auto-minified.

Still a challenge.

In some way, it is; better minification does give you some additional margin. But it would then be a terrible code golf competition because 13 KiB here is the size after zip archiving so the actual limit is anywhere from 30--40 KiB for typical entries and would be very generous. The introduction of better compression tools may have lifted the upper limit a bit but not too much. (Disclaimer: I'm the author of one of such tools that got popular later.)

It should be noted that most assets are still too large in this limit, so almost everything should be made from a code and many stuffs have to be consciously chosen to be included. For this reason, I feel that the limit is rather a very interesting threshold that allows for ordinary developers without much size optimization experience to start with, but should be plenty enough for experienced people to make difference.

Awesome, thanks. So while I might need to think about clever ways to generate/handle assets, I can generally not worry about "all the clever JavaScript hacks" and just write thoughtful TypeScript that I elide and minify.

Yeah, most microscopic JS hacks would be too cumbersome to use in this scale. But some conscious decisions to structure your code may make a big difference.

Kind of tangental since it doesn't apply here but I love the compression hack used in JS competitions where HTTP wire compression or zipping the files don't count towards the size limit, so the HTML has to decompress itself. The canonical way to do it is to craft a file which browsers will parse as either a PNG or HTML, with the HTML part carrying a stub of Javascript which reads the page as a PNG, draws it into a canvas, extracts the pixel data, reinterprets it as a string containing the main JS payload and evals() it.

AFAIK js13kGames is intentionally using ZIP as a compressed container in order to avoid requiring such relatively obscure hacks to be competitive (up to some degree). Also the hack itself is now being less relevant due to the introduction of DecompressionStream and non-DEFLATE compression algorithms.

That’s horrifying; thanks, I love it.

The entire 8 bit era was full of games of this size. The game code and sprite data for Lode Runner is less than 16 KB. Machines with 48 or 64 KB of RAM don’t give mic( to work with but we still got Rescue Raiders, Bolo, Bilestoad, and so on.

Even if minified, the file size is so constrained that it basically excludes the use of assets like images and audio files.

13kb of 44khz 16bit MONO audio is 150ms, even with compression sampled audio is more or less out of the question.

With pixel art images however you can get a fair bit in if you're comfortable with low resolutions in 8bpp or lower.

You can still do some impressive stuff:

https://js13kgames.com/games/q1k3/index.html

I've done 64kb intros since the 90s so I'm pretty familiar with sizecoding, my point was rather that non-generated audio is usually pretty much out of the picture whilst images in pixelart form is still feasible to a degree.

Actually noticed the compo in time this time (no idea good ideas for the theme though), got 2 or 3 interesting failed attempts to scrounge code from (but not sure of the approach to take yet).

Reply on news.ycombinator.com