Home

JS1k 2012

1. Introduction
2. Terrain generation
3. Time, colours & light
4. Optimization & conclusion

JS1k 2013

1. Introduction
2. Tunnel generation
3. Rendering
4. Conclusion

JS1k 2015

1. Introduction
2. Buggy island

Standalone JS1k demos

1. Mine[love]craft
2. Strange crystals II
3. Buggy island
4. Islands
5. Gliese 581 c

At first, I tried to optimize code while adding functionalities to it. There were all kind of tricks and the code soon became a real mess, responding quasi-chaotically to modifications. I had started exploring "JS crushing", converting sequences of code into strings, then applying entropic compression to them, before expanding and evaluating them at run-time. But many had done this before, and I soon used Aivo Paas' crusher, which happens to be another entry to the 2012 JS1k. I didn't have time to benchmark the crushers, so I stuck to this one, and I'm pretty sure it does a very good job. I realized almost too late that such crushers are not harmless if you apply them directly on your source code: this produced numerous syntax errors 1h before deadline (due to not-so-optional semicolons), and a stressful debugging frenzy.

So JS crushing allowed me to work on readable code, but I still had to work on 3 different kinds of optimization:

• Soul: find the optimal paradigms for your own little universe. This requires imagination, rigorous maths, attention to details, sometimes a sharp sense of humour (a mix which can be so f*ing close to genious), and in my opinion represents the real value of it all.
• Language: exploit javascript specificities (not to say oddities), by using implicit casting, optional arguments, global variables, with statement (nope: it's incredibly slow, it's redundant with entropic optimization, and above all it's bad), bitwise operators, etc.
• Entropy: "please the crusher" in every possible way (and this includes very nasty ways), by refactoring code to induce redundant patterns (rename variables, add unused arguments to duplicate function signature, etc.). This sometimes paradoxically requires you to bloat your code.

I realize there are many things I didn't explain (ephemeris calculation, lightness management, isometric projection specificities, hue optimization, etc.). Let's say we'll keep some mystery here, but if you want to know, just ask. And surely there are also many ways to improve the demo, while staying below the 1K limit. And may be I should start thinking about my entry for next year's JS1k (what about Angry Birds 1K ?).

But for now it's spring in the northern hemisphere, and I must cultivate my garden.