.kkrieger - The FPS Game in 96KB (Full Gameplay) on HackerTube: recommended by 3 Hacker News commenters across 4 separate months, 2013–2026.
demo · evergreen
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.
“I suggest that you look at the result in awe”
9 Hacker News comments link this video. Each one links back to its thread.
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.
in “Metaprogramming for Madmen (2012)” · View on HN
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
in “Source code for 4kb demoscene production “Elevated” released” · View on HN
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] )
in “Metaprogramming for madmen” · View on HN
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.
in “Show HN: My Isometric Voxel Engine 6 Months Later” · View on HN
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
in “A Tiny Yellow Handheld Changed How Duke University Teaches Game Design” · View on HN
Are you referring to procedurally generated content? [link] .kkrieger got a lot of attention for using this method and only being 96KB. ▶ this video
in “Nvidia tool generates full 3D models from a single still image” · View on HN
A group of devs from the demo scene legends Farbrausch made a 3D FPS game in 96KB years ago that was seriously impressive. 3D games with procedural textures and shaders can compress very well indeed. [link] (gameplay video ▶ this video )
in “Top games from the JS13K 2020 competition” · View on HN
My favorite example is the FPS .kkrieger ( ▶ this video ) which is entirely contained in a 96 KB EXE. Recently I learned the source for that (and other projects) was released a couple years ago, even if in a pretty messy state: [link] Skimming around I found this snippet at the end of chapter six. Are the authors even aware of .kkrieger? As we can see, all existing work on generating graphical game has targeted games in the style of classic arcade games and home console games from the early 80’s, or simple arcade games. There is still considerable work to be done here, and nobody has yet constructed a system that could generate novel graphical games of high quality, comparable to the novel high-quality board games produced by Cameron Browne’s Ludi system. However, there is also considerable opportunities in devel- oping game description languages that can effectively and economically describe other types of games, and game generators that take into account the specific game design affordances and challenges that come with such games. For example, what would it take to generate playable, interesting and original FPS games?
in “Procedural Content Generation in Games” · View on HN
I still remember how I was blown away when seeing .kkrieger[1][2] for the first time, introducing me to the potential of procedural assets in games. [1] [link] [2] ▶ this video
in “Simple Minecraft Clone in 580 lines of Python” · View on HN