August 30, 2006

• Lovely, absolutely lovely. My heart skipped a beat when i thought I saw the WERZOG... But, alas it turned out to be werkkzeug1 !!
• This sounds very interesting, but I'm afraid I'm very confused as to what is going on. What is procedural generation? How does this work?
• Wikipedia article. My understanding is that the program is essentially creating content dynamically as it executes, rather than having already existing images, sound, etc. stored that it manipulates. This means smaller, leaner code and less storage needed.
• It is also, I would like to stress, pretty damn cool.
• I can't claim any useful knowledge of either stored or dynamic games, but it seems to me that if the program is preparing the next room while you're playing, it would be somewhat slower than the stored games. Maybe not noticeably on a fast machine or to novices at these games, but definitely to an Xbox gamer. Would this be accurate?
• Interesting link Ritz! Now only if it'd work for Linux... =)
• Perhaps the main attraction of this technique is the money saved on artists' salaries? It certainly would mean less grunge work for graphics/animation artists. A 96K executable is pretty cool, but with storage so cheap these days...
• The development effort and storage space required by modern games are almost entirely devoted to static data. Stuff like bitmaps, audio files, character model meshes, etc. I believe those in the business call this stuff "assets." The program itself is often quite small by modern standards. For example, Quake 3 consumed something like 100MB of disk space, but the program itself was only about 500KB, less than one percent of the total package. So the tiny size of .kkrieger isn't surprising. (Quake 3 doesn't really count as "modern" any more, but the situation has only become more skewed toward assets since then, to the point of an organizational, financial and creative "content crisis," in some observer's opinions. Wil Wright talks about this a little bit in his Spore talk.) I would guess that .kkrieger probably creates textures and other data algorithmically when it starts up, then treats them as static assets during game play, rather than really creating assets "on the fly" as needed. In either case, such an approach actually requires more code, not less.
• .kkriegger is made by demo group Farbrausch using their engine called the produkkt. They are very popular in the demo scene category of 64 kb demos, where graphics code and music has to fit within 64kb. The game is amazing but it's basically a 64k demo with some basic AI and control code added. Some other 64k wonders they've done: the Candytron demo features humanoid figures with scripted animation and a vocoder-style voice singing a song, again all in 64k. The demo Poem To A Horse is simply the most beautiful thing you'll ever see rendered on your computer. Also on the main page you can download the produkkt, the engine used to procedurally generate and build all of their demos. It's very, very complicated, but fun to play with.
• I have not the chops to participate in this thread's technical analysis, but I do recall that in 1987 I had a copy of a program called chess.exe that was just under 10,000 bytes that could whip my ass in chess over and again, with an ascii interface that was not exactly hi-res, but good enough to be able to play without hardship. Now that's efficient coding. and that's 10,000 bytes, folks, not 10,000 kbytes. The size of a thumbnail photo.
• Hey... psst.. RalphTheDog...: 4k demos.
• This is the reason I built my new computer. Seriously. Didn't work, though. The hardware I was using didn't meet .kkrieger's minimum standards. 'Course, the new 'puter's made out of a Honda Civic engine and straw, but it was worth a shot. Well, back to the meth.
• .
• I made my latest computer out of sprouted wheat bread and a lovely slice of medium cheddar. not so good for gaming, tho.