5 ms·

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

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

Waterluvian 2y ago
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.
- actionfromafar 2y ago
  Still a challenge.
- lifthrasiir 2y ago
  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.
  - Waterluvian 2y ago
    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.
    - lifthrasiir 2y ago
      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.
  - jsheard 2y ago
    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.
    - lifthrasiir 2y ago
      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.
    - sgarland 2y ago
      That’s horrifying; thanks, I love it.
  - wang_li 2y ago
    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.
- Cthulhu_ 2y ago
  Even if minified, the file size is so constrained that it basically excludes the use of assets like images and audio files.
  - whizzter 2y ago
    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.
    - criddell 2y ago
      You can still do some impressive stuff: https://js13kgames.com/games/q1k3/index.html https://js13kgames.com/games/q1k3/index.html
      - whizzter 2y ago
        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.
deleted 2y ago
[deleted]
whizzter 2y ago
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).

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

Waterluvian 2y ago

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.

actionfromafar 2y ago
Still a challenge.
lifthrasiir 2y ago
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.
- Waterluvian 2y ago
  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.
  - lifthrasiir 2y ago
    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.
- jsheard 2y ago
  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.
  - lifthrasiir 2y ago
    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.
  - sgarland 2y ago
    That’s horrifying; thanks, I love it.
- wang_li 2y ago
  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.
Cthulhu_ 2y ago
Even if minified, the file size is so constrained that it basically excludes the use of assets like images and audio files.
- whizzter 2y ago
  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.
  - criddell 2y ago
    You can still do some impressive stuff: https://js13kgames.com/games/q1k3/index.html https://js13kgames.com/games/q1k3/index.html
    - whizzter 2y ago
      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.

deleted 2y ago

[deleted]

whizzter 2y ago

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).