Daniel Hands
3 HN recommenders · recommended in 9 months, 2013–2026
7:16 · 528K views · Nov 14, 2009
Full gameplay of .kkrieger, a first-person shooter by Farbrausch that fits into a 96KB executable by generating its textures, models and sounds procedurally.
HN points to it as the standard example of procedural content generation and extreme size optimization in games.
9 comments from Hacker News
Before you read the story, I suggest that you look at the result in awe: this video That whole game is 96k. Meaning it's roughly 0.07% of the size of an empty Electron app.
This is an amazing insight into how demos are written. Farbrausch stuff has always been inspirational to me. It's very interesting is the sort of extreme version of the idea that data model and code are inherently tied: Especially in functional programming circles it's a maxim that you design your data models first, specifically for your task, and then the rest of the code is pretty much pattern-matching around that. This takes that coupling and makes it even tighter, to serve a higher purpose. I almost feel like given enough time, this could be a JIT: an executable that adaptively strips code and self-minifies over time as you run it. :) Also check out: - kkrieger (windows only 96kb 3D FPS, video here: this video ) - the previous post ( [LINK] )
Wow, great work, this reminds me of a lot of demoscene stuff where, when faced with space limitations, programmers aggressively used procedural generation combined with prerendering and caching. The most iconic example I can think of is .kkrieger, the 96kb first person shooter that has (relatively) amazing graphics: [LINK] Video here: this video There might be valuable lessons to be had in that domain that might save you some time.
Although they generally didn't compete in the 4kb genre, Farbrausch open-sourced many of their demos and demo-making tools a few years ago [1]. fr-041: Debris [2], and kkrieger [3] (the 96kb FPS) are particularly worth checking out for the uninitiated. [1] [LINK] [2] [LINK] [3] this video
That's the intention, sure, and as long as prospective Masters students know that's what they're getting into and paying for, and are looking forward to it, then it's fine or whatever. But it still strikes me as a silly constraint, just as it would be to require an in-house engine that sucks, or requiring students to develop for some old Nintendo hardware, or requiring students to fit everything in under 96k.[0] Anyone can add arbitrary constraints to anything, and lots of interesting questions will arise from figuring out how to deal with (or work around) such constraints. But is the constraint to develop for this specific device (and all the sub constraints that implies) actually a good one vs. any other set of constraints, especially for the purposes of game design? I doubt it. Especially how some of the constraints like only using black-and-white graphics are easily enforced without also requiring such a specific niche device. [0] .kkrieger ( this video ) is my favorite of this genre of constraints, but it's mainly impressive for being possible at all (and you can read up on some of the developer notes for how much effort was put into satisfying this constraint). It didn't actually advance the design of FPSes or anything, and FPS design ideas could be better learned by making and iterating on an FPS without the tiny size constraint. If students want to impose extra constraints on themselves, like developing for the Playdate and making use of its crank for game control, go fo