Kkrieger – A 96KB first person shooter | Hacker News Reader

Kkrieger – A 96KB first person shooter

en.wikipedia.org

227 pointszactral75 comments

I wonder how many young people were inspired to take up programming because of the work of Future Crew, Farbrausch and the like. I certainly was, after experiencing what FC did with Second Reality. Props to Farbrausch for publishing so much of their code.

In some sense, getting 1k colors out of a CGA is the contra-movement to node.js :)

Farbrausch definitely inspired me to get into programming, just so I could program something 3D. Learning how to program was the easy part; figuring out how 3D graphics work was harder, because of all the complicated math/algebra involved. I eventually got some lit and textured polys going, and some shadow mapping (even wrote the Wikipedia article on it), then gave up and settled for web programming. (Hey look, WebGL!)

I'm very excited and intimidated by WebGL and other graphics/animation platforms for the web. It's something I've always been very interested in but I don't have any clue on how any of it works. I think it will probably always remain mostly separate from the type of typical web dev work I do, but I still want to learn it.

That's what three.js is for <o/

I always found that matrix algebra and that stuff is so much easier to learn with 3d graphics. You can see what it is doing.

Almost any math is easier when you have a use for it.

Oh man, I haven't thought about Future Crew in a long time. Brings back fond memories.

Here's a nice nostalgia hit to throw on in the background while you're coding: https://archive.org/details/futurecrew-metropolis

Future Crew and their Second Reality got me into demo scene back in 90s! Those were the days when we coded proof of concept demo effects which we later optimized using inline assembly in Borland C++. Shouts go out to Asphyxia for great demo-programming tutorials.

To stay on topic, what is the true news value here?

Oh, you young ones.

Back in the day on the Atari ST it was all assembly because C was just too slow.

https://youtu.be/cpezr7puRFo

None of my stuff was included because it really wasn't good enough.

Also the guy who did most of the music for the Synergy Megademo, Joris de Man, went on to do music and sound effects for Killzone and lately Horizon: Zero Dawn. So proud of him.

Anyone know of some good/great demo-programming tutorials of similar quality for the modern age? I teach kids programming (and math and stuff) at a youth centre, and some of them are wicked smart and would dig this like I digged it when I was their age.

But I can't really expect them to go pixel-bashing in the ancient Turbo Pascal IDE (regardless how great it is), nor do I believe that `mov ax, 13h; int 10h` still even works on modern OSes, without an emulator ;-)

I got one of them coding a cool interference circles effect and a Mandelbrot-zoomer in Processing. It's Java without the boilerplate to get a window and gfx primitives, which is just great. But afaik nobody in the scene uses it. It is used by digital/generative artists, but they often have the hardware power to get away with inefficient Java implementations (nor is their work always as "shiny" as demoscene productions, demoscene always[0] aims to impress, digital art can have diferent motivations).

BTW--just to gloat a bit here--I saw .kkrieger at the big screen on BP04 when it was released whoohoo ahem

[0] yes there are exceptions but no they don't win parties :-p

"In some sense, getting 1k colors out of a CGA is the contra-movement to node.js"

Is it?

I have the feeling node.js development has the same spirit, getting some tech (JS) to do something it was never ment to do.

I give you that, but I would say JS is not great for "Getting more with less", which is certainly a goal of these productions.

I guess, it would be possbile to get more with less, but yes this doesn't seem to be the goal with node.js :)

Superficially yes. But there's no real difficulty to one of those problems, and amazing fascinating difficulty to the other.

Getting JavaScript to work as a server side language is about as challenging as getting a crew cab pickup truck to work as a 2 passenger commuting vehicle. [1]

The kinds of things done in demoscene (such as kkrieger) are more like finding a way to use a motorcycle to haul several tons of cargo. (Is that even possible? I don't know, but "Is that even possible?" is PRECISELY the feeling demoscene stuff evokes in the user. It is art.)

[1]: I'm gonna get in trouble here so I have to say: I don't mean this as an insult to nodejs, since difficulty has nothing to do with utility. But way before nodejs, any novice programmer could have put together such a thing in a weekend by gluing libraries together (e.g., Java had a JavaScript engine for a long time, and that's probably how I would have done it). What nodejs accomplishes is creating a way for people who only have learned JavaScript, of which there are many due to the web, to immediately add server-side coding to their abilities without having to learn a whole new language. I wouldn't use nodejs for my own work, but making programming more accessible is always good.

>>getting some tech (JS) to do something it was never ment to do

That's pretty much my reaction to the entire modern WWW. What started as a way to serve some simple static text has evolved into something that is truly amazing. Using a modern "webapp" like Fusion 360 (3D CAD) is a miracle of technology.

I absolutely started programming because of Future Crew's Second Reality (and MajorMUD).

Fabian Giesen aka ryg, one of the developers behind .kkrieger wrote up a post about how they crunched out the last bytes to get it down to 96k. https://fgiesen.wordpress.com/2012/04/08/metaprogramming-for...

This is definitely the interesting part. My favorite bit is the features that were coded in, but are missing from the build because they weren't part of a test.

Speaking of Fabian Giesen, his whole blog is worth a read:

https://fgiesen.wordpress.com/

This is one of the very few blogs where I enjoyed reading every single article.

A few years ago, Farbrausch released a lot of the code for their demos on GitHub : https://github.com/farbrausch/fr_public

I think it contains .kkrieger but I didn't try it.

It may be of interest to note that this includes their tools as well as the actual produced demos.

Yep. At one point they were trying to make their procedural modeling tool .werkkzeug into a commercial product targeting mobile game dev. But, I guess they didn't find an audience.

If you find that interesting, you really should check out http://tooll.io It's pretty much a more modern take on .werkkzeug with a focus on usability rather than compression.

I had seen a few things from the demoscene where I nodded saying, "Impressive coding," to just move on to next interesting thing in a feed. Kkrieger was the first one I saw that blew me away to the point I played it a bit extra just impressed by what it was doing. I also sent it to a bunch of people. Awesome project. :)

I remember playing this on a fantastic 12 fps, but still being blown away. I was heavy into demoscene at the time so it just added to the wonder of it all. Inspiring stuff.

My graphics card at the time was too shitty to even try to run this (Rage 128). One of the first things I ran after getting a much better card a few months later was play kkrieger.

My friends and I used this for benchmarking new PCs. Hardly anyone got over 20fps consistently back then.

Video: https://www.youtube.com/watch?v=_qrsHqDF4BA

It's amazing how many things the guy in the video gets wrong. ;)

Hah, this poor guy is reviewing a demo as if it's a game, and sounds hilariously clueless in the process.

"I'm amazed they didn't finish this game, this plays really well."

To be fair, a legitimate review would have just been "Holy shit, this is 96k. Holy shit. Just 96k. Jesus. That's less than the space taken than a single screenshot. Wow."

EDIT: Oh, I see what happened. He thought "demo" referred to a game demo, as in a limited edition of a full game.

The archived site emphasizes that "this is a beta version, and there are a lot of known bugs." It's not unreasonable to assume they intended to do more with it.

True, but I like how impressed he is by certain parts of the graphics/meshes :) The procedural generation technique, apart from saving tons of space, also allows for some pretty good+realistic tree trunk and rock objects (or "effects" as they'd be called if this had been a regular demo instead of a game).

I do agree with him about the lack of gore. It doesn't necessarily have to be bloody per se, but there's a great short gamedev presentation called "Juice it or lose it"[0] with loads of basic little tricks to make a game "juicier". They already hit a bunch of them, but there could have been some monster bits flying from the explosion.

[0] https://www.youtube.com/watch?v=Fy0aCDmgnxg (15 mins)

https://youtube.com/watch?v=2NBG-sKFaB0

For those who can't stand that endless stream of bs.

Can a mod maybe edit the title to ".kkrieger — (...)"? :)

I'm fairly certain that Farbrausch made it a point to have many of their releases begin with a lowercase 'k' (for no other reason than style, afaik). You can choose to omit the dot if you really don't like it, but it's just not spelled with an uppercase 'k'.

And these people are German, where nouns are always capitalized. So when they do not, it's very much on purpose.

Has anyone yet succeeded in running it on a modern computer? Last time I tried it I had no luck.

It's runs fine on Wine, albeit in the top left corner of the screen. You could probably get it to run full screen with the right wine startup parameters.

edit: wine-stable on ubuntu17.04

I don't remember having any trouble. I just tested again and my Win10 laptop ran it just fine.

Edit: Just make sure it actually closes when you close it. I checked my task manager and it was still running!

Just ran it on win10, works fine :) A friend of mine needed to tick winXP compat mode to get it running but it ran out of the box for me.

Doom is 4196KB.

That's pretty crazy

That's still only roughly the size of a single mp3 file or one digital camera picture! :)

And of course, the biggest trick in .kkrieger is that everything is procedural. A choice made because of the goal they set out with. There's assets in Doom that just couldn't have been done with tiny procedural texture descriptions and still represent quite the same thing. For .kkrieger such assets were simply not an option and the game was designed around it.

Also, I always liken the graphics in .kkrieger to Halflife 1, not Doom, which is quite a bit different. Objects in Doom were all billboarded sprites, afaicr.

So where can I actually download this? Wikipedia links to an archive of the original page, and the download wasn't archived.

~96 KB on disk, but how much in RAM?

From the wikipedia article:

The entire game uses only 97,280 bytes of disk space. In contrast, most contemporary first-person shooters fill one or more CDs or DVDs. According to the developers, .kkrieger itself would take up around 200–300 MB of space if it had been stored the conventional way [0]

[0] https://en.wikipedia.org/wiki/.kkrieger#Procedural_content

So after it generates all the assets in RAM, the game takes up 200-300 MB?

Right.

Yes.

I just tested it with Wine. The process seemed to consume about 320MiB of RAM.

those are real gamedevs

No, those are real demodevs.

Games are not about technical superiority - they're about having fun and projecting stories and emotions, just like any other art form.

Tell that to the AAA market.

AAA games often project emotions too - just a different _kind_ of emotions. Just because Modern Warfare is a different experience than Inside or Fez doesn't mean you don't feel anything when playing it. There's plenty of place in the world for all kinds of games.

I don't get the hate for CoD. I played all but last Modern Warfare installments and really liked the single-player campaign!

I know the spin-offs catch a lot of shit—and the first Black Ops was awful—but Black Ops II, for all its problems, does more interesting stuff in both its single- and multi-player than I've seen in another console FPS since Perfect Dark.

[EDIT] though, to be clear, still far less than Perfect Dark did.

>just like any other art form

That implies that making something technically impressive, like .kkrieger, isn't an art form.

Technical quality and artistic quality are orthogonal, though the former can have an influence on the latter.

I'm not sure I'd agree there. Both programming and traditional art are creative disciplines. I'd argue that any creative discipline can be treated as an art.

I may have misread the comment that you originally replied to; my reading of golergka's original comment was simply to put .kkrieger in the correct context.

We expect certain things from games, and .kkrieger doesn't deliver on that front. In the context of the demoscene, it delivers in spades.

I thought you were originally objecting to the reclassification of the .kkreiger developers, gamedev -> demodev. A second reading suggests that maybe they don't consider .kkrieger to be art, in which case I disagree.

No, they're real gamedevs. Much like Richard Garriott, they built their own tools, unlike every AAA company out there using someone elses engine.

These guys did the ALL of the work from the ground up. That's REAL development.

I don't want to start a philosophical argument here about what a "real dev" is, but I do want to provide a counterpoint to any potential gamedevs who may be reading this:

While writing your own engine from scratch can sound tempting, and absolutely is a rewarding excercise, if your goal is to publish a game, it's probably wise to not do this. Pick up gamemaker or godot or unity and start prototyping right away.

I might have a bit of a bias here, but I spend a not-insignificant amount of time on an online gamedev community, and the only people who ever finish anything are the guys using gamemaker and unity. Everyone else gets stuck at the "should I use regular inheritance or components/what's the best way to z-order sprites/Delta time coefficients cause random bugs in physics" stage and cannot proceed because their engine becomes unstable.

If you have the skills and time, and feel like it is necessary to write your own engine for your game, then by all means, but I think that for most people, these prerequisites don't exist.

"Real dev" or not, once you shipped your game, you've done more than most devs.

I 1000% agree with this. At the same time, I think developing your own engine is immensely empowering and helps you "level up" in some fashion. I'd recommend doing both. But, of course, just use an existing engine and make a game first. The engine is a long haul endeavor. It starts very slowly, but eventually, you'll be able to roll your own games with it. And there's something about that that's very cool. But don't write an entire engine for your first or even second game.

So real real game developers should ship their own operating system to run the game on. As well as their own hardware. Because all the others are just using someone else's and are lazy.

Sorry, but doing more work just for the sake of doing more work is not something that's impressive. It's merely a waste of time. For .kkrieger the technical achievement of fitting that much in so little space is definitely impressive, but dismissing developers that were using a licensed engine is pointless. Most games are built with finite time and money. If you can build a better game by allocating money somewhere you'd otherwise have spent time at the expense of part of the game, then that's a net win in my eyes, and doesn't diminish the result in the slightest.

"So real real game developers should ship their own operating system to run the game on. As well as their own hardware. Because all the others are just using someone else's and are lazy."

I believe there's rules on HN regarding unwarranted snark. You very obviously missed the entire point of what I said so there's no point in trying to explain.

I'd like to point out that I work at one of the largest(if not the largest) gamedev company in the world and 100% of our projects use our own engines.

Unless you believe that every single game should write its own engine from scratch, then I don't know what to say about that, it's just extremely obvious that it's not feasible for every project regardless of whether you have 100 or 10000 people working at your company.

I have enormous respect for these guys for everything they do, but condemning someone for using a third-party engine that works fine instead of reinventing the wheel is silly. Some people love and excel at making engines; some people love and excel at making content. We need both.

> No, those are real demodevs.

You say that as if it is a pejorative. In many ways, the demo scene is more demanding of excellence than game development.

Yes, there are differences in priorities between demos and games, but by creating a technically excellent demo that is also a game that "plays really well", they've shown that they are "demodevs" who are also "gamedevs".

And art comes in many forms. Besides the obvious visual/animation/audio artistic aspects of demos, the awe felt at the technical superiority of a great software demo is very similar to the inspirational effects of great physical architecture, but not everyone feels that emotion.

The Taj Mahal is a physical "demo" that demonstrates great "technical superiority", but even people who don't care for architecture tend to recognize it as art.

"Demodev" is not a pejorative? I didn't read that into it. Although the proper term would be "democoder"! :)

On the other hand, yes of course demos are also about "technical superiority", as well as "having fun and projecting stories and emotions". Just in a different sense than games are, which is the part that's "just like any other art form" ;-)

Weird that so many demoscene programmers work in games...

At the time this was released, the game performed terribly (as in, incredibly slowly) on all but most advanced PCs. The "real gamedevs" (such as Carmack) were trying to optimize for performance and working on the most possible hardware configurations. Stuff like Quake was impressive not just because of good gameplay, but also how smooth it ran even on really shit machines.

> At the time this was released, the game performed terribly (as in, incredibly slowly) on all but most advanced PCs.

So it is a Crytek engine? That joke held itself for ages.

> The "real gamedevs" (such as Carmack) were trying to optimize for performance and working on the most possible hardware configurations.

There are many different kinds of gamedevs and many games never made it past their one target platform or sucked on anything else, in addition third party console ports often end up horrible.

Not to forget that the true heroes are often the driver developers that have to add game specific hacks to make the bundle of undefined behavior that the gamedevs call a game both run and look like it didn't come from the uncanny valley.

I played it on a 250$ (and years old) desktop when .kkreiger came out and it worked great.

hahaha it's funny cuz it's still in beta

96KB?

A guy I know wrote a Minecraft clone, a left 4 dead clone and a populus clone in 4KB each.

(he also wrote the real Minecraft)

Wasn't aware of that. Reddit thread (2011):

https://www.reddit.com/r/Minecraft/comments/fhdlp/minecraft_...

Rather unfair comparison IMO. All of the '4k' demos you mention rely on the Java runtime and lean on the big JRE stdlib. That's not to their detriment, just that they've had some rather large hurdles overcome for them compared to the starting point of produkkt/Farbrausch.

> (he also wrote the real Minecraft) So what you're /actually/ trying to do is namedrop, and say "I know notch". Good for you. I find it funny that you felt the need to add this footnote, given anyone who is wise to these prods (or just googles them) will be aware of the author.

IIRC, the "Left 4 Dead clone" was a single-player top-down shooter with sub-Atari 2600 graphics, and the "Minecraft clone" was basically a screen saver, zooming non-interactively through endless raycast cubes. Much respect for doing that in 4K, but it's not directly comparable to a fully textured and lit FPS.

Reply on news.ycombinator.com