.kkrieger - The FPS Game in 96KB (Full Gameplay)

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] )

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?

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