Interview: Frugal Fragging with .kkrieger

Big things come in small packages, as the cliché goes. But that's exactly the best way to describe .kkrieger. It's a playable first-person shooter at only 96 kilobytes in file size. The developers of the game managed to achieve a footprint so small by exploiting the Direct3D API and DLLs of the Windows operating system. Thus, .kkrieger can only run on Windows; it is essentially a demo showing how far the capabilities of Direct3D can be pushed with an absolute minimum amount of code.

This impressive program was, in fact, born from the German "demoscene" (a community of coders who write dazzling graphics programs simply for the fun and challenge, and to show off their skills to one another). It was one such team of demoscene coders that took up the challenge to create .kkrieger.

"One of our specialties is the '64KB intro', which requires productions to be at most 64 kilobytes big," says Fabian Giesen, one of the programmers behind .kkrieger . He's a 19-year-old student studying Computer Science from a small town near Bonn, Germany. "We had the idea that it would be cool to make a small game using the techniques we were using for intros."

Development of .kkrieger began in mid-2002, and a beta was released in April 2004. It made its debut at Breakpoint 2004, an annual get-together and competition for the demoscene in Europe. There, .kkrieger handily won in a contest category for a game no larger than 96KB.

Gamasutra: What's the difference between how the code of .kkrieger works verses that of a commercial 3D graphics game engine like Quake or Unreal ?

FG: The biggest technical difference is probably the amount of pre-processing we can employ. As all content is computed when the user starts the program, we can't do anything that requires expensive computation - so, no light maps, very simple collision detection data structures, no mesh optimization, no texture compression. This all negatively impacts either the quality of the resulting graphics or the hardware requirements - un-optimized content leads to higher CPU [and] graphics processor usage.

And we're lacking large-scale extensibility features, like integrated scripting languages. .kkrieger is too small a project to make such things worthwhile.

GS: What's the current status of .kkrieger ?

FG: The current version of .kkrieger is a beta version, with both code and content cut to fit into 96KB. The final version isn't subject to that limit, though we'll try to keep it under 128KB.

As for features, it's quite a generic first-person shooter with state-of-the-art graphics and somewhat lacking gameplay; the gameplay code was finished very late, so we ran out of time concerning placement of items, weapons and smaller puzzles like the typical key card-hunting, and it shows. However, that was an in-between version; the final version will be notably improved.

Concerning the code, we'll focus on performance and bug-fixing. The changes in the graphics should be more obvious, because we'll be including everything we kicked out of the beta version for size reasons, and we'll work hard on making it fun to play.

GS: Besides the obvious first-person shooters, was .kkrieger inspired by any other program?

FG: lcc-win32 (a small, ANSI-compliant C compiler) was the biggest non-game inspiration for us, because it was designed with very similar requirements: by a small team of people - just two - with simplicity as a primary design goal.

Finding simple solutions to complex problems is absolutely essential if you just don't have the resources (both in time and manpower) to do anything more sophisticated, and lcc-win32 is an absolutely shining example of how far you can get with such a design philosophy.

GS: What language was used to write .kkrieger ?

FG: C++, plus some assembly language code where it really matters: mainly texture generation innerloops and the sound synthesizer.

C++ is about the only language fit to our rather special requirements. We have both rather low-level (e.g. memory management, texture generation) and high-level (e.g. scene graph, world management) components, and we need a language that is suitable for both, with adequate compiler support, and at the same time also allows us to write very compact code.

We were able to compile both the editor and the game from the exact same source base (with other compiler switches and editor-only components like GUI code not linked in for the game executable), significantly lowering the amount of maintenance work involved, since everything was in one project. I don't think there are many languages that allow us that high degree of flexibility.

GS: Does .kkrieger use code or libraries which the team did not originally develop?

FG: Apart from Direct3D and DirectSound for graphics and sound, we only use standard Windows DLLs [for] window management, graphics, memory management.

We didn't want to rely on dynamic libraries not present in a standard Windows installation, and our size limitation means static libraries are practically a no-go. Apart from the libraries mentioned above, we really use nothing, not even the standard C library - all the routines we actually used were smaller when in-lined.

GS: What technology had to be specifically created for .kkrieger ?

FG: There are two tools worth mentioning:

First, there's kkrunchy , our own executable packer. It was developed by me primarily for our demoscene projects, but it saw some improvements during the development of .kkrieger. Aside from offering very good compression, its main feature is that it generates a comprehensive report of how well different code is compressible.

This allows us to focus the little size optimization we actually do on the code on areas where it's worthwhile. This kind of feedback is important, because passages of code that are quite big in uncompressed form typically compress quite well, and size-optimizing such code typically makes it bigger in compressed form, not smaller.

The second tool worth mentioning is lekktor and was created about one week before the competition in which the .kkrieger beta was released, when it became clear that we wouldn't have the time to both get the necessary work for the beta version done and making it fit into the 96k size limit of the competition rules. So we decided to automate the latter part.

lekktor is a small tool that can, very rudimentarily, parse C++ source code and output an instrumented version. We used it to find out which code passages were actually executed, and automatically remove everything that wasn't. This obviously can't work for everything that depends on user input or does error handling, but since a big part of our code is completely non-interactive, we were able to use it to great effect, notably [cutting back] about 4k code after compression.

GS: What have been the biggest challenges your team has encountered in developing .kkrieger ?

FG: Keeping everything "simple" enough to finish it. Many people seem to think that .kkrieger is more or less the result of two years of inspired hacking and size-coding, but that is far from the truth. We are a small team, and .kkrieger was developed in our spare time, so the primary problems were design problems. We had to design a system that [would be] relatively fast to implement, [easy] to maintain, and still be able to power a complete first-person shooter.

Some of the more "esoteric" design decisions, like using the same source tree for [the] editor and game, were direct results of this - being able to tweak level data while the game is running, and being able to directly use code originally written for the editor in the game, and vice versa, made our work much easier.

Our artists had similar problems - everything is generated procedurally, so the actual game data is, in a sense, also a software system of considerable size. One of the things we forgot at first (but were able to correct step-by-step later) was that the artists also had considerable complexity to cope with. So we needed to give them better ways of organizing their work inside the editor.

GS: What features can we expect in the next version of .kkrieger ?

FG: When it comes to technical stuff, there are a lot of things on our wish list, but nothing has been decided.

As far as gameplay goes, the .kkrieger beta has only very basic gameplay, and we'll certainly work hard on improving that. So expect somewhat more intelligent monsters, [the addition of] puzzles, better game balance, and some new ideas in upcoming releases.

GS: What would you like others to pay special notice to the most about your work in .kkrieger ?

FG: The fact that it's only a first experiment of what you can do with procedural content generation for game and multimedia development. That is perhaps the most exciting aspect. This is not something we've explored end-to-end yet; we've only just started uncovering its real potential, and I think the results so far are already very exciting.

GS: What advice do you have for those who are developing their own 3D graphics programs?

FG: The most important thing is probably knowing where you want to end up. Especially for small teams, it is absolutely impossible to do something that can "beat" the big software houses if you try to do everything the way they do.

Try weird things no one else is doing. Concern yourself with problems not yet fully understood. Try unconventional approaches. That is what the big houses are bad at, because they have to adhere to strict deadlines and customer expectations. That is where you can achieve something truly new and exciting: by having one good idea and taking it as far as you can.

GS: Do you play any of the commercially produced first-person shooters yourself?

FG: Yes, of course I do. My favorite, though it's not really a "first-person shooter," is Deus Ex. It has the kind of depth most action games lack, and great re-playability. Most first-person shooters are more slanted towards arcade-style gameplay. There's nothing wrong with that, but I've always been attracted by story-driven game design.

I am somewhat bothered by the trend to make games pure gorefests, though. I have nothing against violence in games per se, but there really should be better ways of rewarding the player than just displaying huge fountains of blood whenever an enemy is killed.

GS: So which way will .kkrieger go? Will it become a gorefest or be more story driven?

FG: Neither - the upcoming final of Chapter 1 and the other two chapters will be arcade-style. For about half an hour of gameplay there's not much you can do in the story-driven department. However, we really don't want to resort to cheap splatter effects. We got some ideas we want to try out, but nothing is set yet.