Optimising for size has been part of the demoscene for as long as anyone can remember. It probably started off driven by the desire to fit something interesting into a boot loader or something like that. 64k intros involve fitting a whole production – music and graphics and code included – in one self-contained executable of 65536 bytes. That’s not much bigger than an empty word document; it’s likely that one screenshot from the production in JPEG form would be larger than the 64k taken by the production. The nice thing about 64ks is that it’s enough space to do something worthwhile in terms of design, sound and graphics – but it’s small enough to still amaze people with the file size aspect. 64k is enough space to work in a “usual” fashion. To be able to work on graphics and music in a proper environment, and to be able to code without having to think about every byte – something that makes smaller productions (e.g. 4k or less) painful to produce.
The category evolved through the 90s, pushed forward by groups like TBL who managed to fit decent visuals and soundtracks that sounded like “proper music”. It reached a head with the release of fr-08: .the .product in 2000, which contained an amazing amount of graphics which actually looked something like you might see in a typical PC videogame of the time – but in a tiny fraction of the space. It set the world alight and immortalised the creators, and everyone wondered – how was it done?
The answer was: they generated it. The textures, models, soundtrack – all generated, based on metadata about how to create the elements supplied by the artist using their custom-produced graphical tool set. In simple terms, they dont store the pixels for the texture in a compressed form; they store the steps to tell the engine how to regenerate the texture, from a combination of simple generators like noise, and blending operations. Of course, this kind of thing had been around for years, but this was the best implementation so far. The clever thing about these guys was that not only did they make such a great production, they also told the world how they did it. Numerous presentations and articles were followed up by releases of most, if not all, the tools they used in the making of the production for the world to see.
Something about it all caught the imagination of many of the young coders around in the demoscene at the time, myself included. Maybe it was the idea that the coder was back in charge and taking centre stage after years of being edged out by the artists and musicians; maybe it was the challenge of doing something bigger and better than these guys had done; or maybe it was about wanting a piece of the substantial fame they had achieved in the community and beyond. It’s worth noting that most good demos get a few thousand downloads; some of the stuff these guys made got hundreds of thousands. It went way beyond “the demoscene”.
So, like so many other coders, I started working on 64ks myself. The road was long. With 64ks nothing comes easy. You are expected to make content that would look decent in a 64mb demo, but there are no shortcuts. In a demo you can get graphics from anywhere – a 3d tool, your camera, the internet; and you can make the soundtrack however you want as long as it ends up as an MP3. In a 64k you wouldn’t get very far like that – you have to have a hand in the whole creation process yourself. If you want tools to make graphics and music, you have to go and make them. It massively increases the time taken to make anything.
From 2001 to 2006 I made quite a lot of 64ks. They started out pretty awful – badly made hardcoded affairs – but grew into some quite hefty productions, winning Assembly and Breakpoint 64k competitions and gaining a scene.org award for best 64k intro and numerous nominations. I developed my own modelling, texturing, animation and scene editing tools, and my own soft synth (VST). It was an exciting time to be involved. There was an arms race between several groups – at first Farbrausch and Conspiracy, later Conspiracy and us (Fairlight). Every year we’d all be sat in the party hall at Breakpoint or Assembly trying to hammer out our production, each wondering what new tricks the other group had managed to pull off and whether it was better than the new tricks we had managed to pull off.
My final 64k was “dead ringer”, released at Assembly 2006, where it took first place. Dead ringer was a breakthrough in that it was the first 64k intro to move away from large and impressive but static scenes with simple animation – and featured a fully animated character performing a series of breakdancing moves that started life as several mb of motion capture data but managed to get squeezed into around 6k. Assembly 2006 had the most amazing 64k competition ever seen – the three big players in 64k (us, Conspiracy and Farbrausch) and Kewlers all competing, the bar getting pushed higher each time. It seemed that after that competition, the 64k scene was never the same again. Perhaps the bar had been pushed too high, and the amount of work needed to move it on was just too much for anyone to contemplate.
After Dead Ringer we were pretty much spent, so we quit. That was the plan, anyway. As it happens we came back in 2008 and made another 64k, “panic room”, which won the 64k intro competition at Assembly 2008, but that’s another story.
It took me a long time to realise the real secret of the farbrausch 64k intros all those years ago: all the talk is about the technology, but really it’s all about the artist. That’s the difference between a few numbers plugged into a generator routine, and those wonderful scenes that looked “almost as good as a video game but in 64k”. Sadly it’s the thing so many coders forget. It doesn’t matter what routines you code or what tools you build – in the end what matters is how they get used.