the ".werkkzeug3", our procedural content creation and management tool, is, so to say, the magic behind .kkrieger. it was used to create all visual aspects of .kkrieger - be it textures, materials, levels, characters, or animations.
the underlying principle of the .werkkzeug3 is very simple - similar to modular synthesizers: the functionality of the texture and mesh generators is seperated into simple, indepedent parts ("operators" in our terminology) that each have their own set of parameters and can be connected to other operators, which are in turn connected to other operators. this combination of relatively simple operations is able to produce complex and detailed results. however, there is one problem: keeping track of the connections between individual operators. the "traditional" solution employed in other programs which use a similar system is to display the operators as boxes and the connections as "cables" or arrows, with the user connecting them manually. However, this is tedious and can easily lead to a chaos of overlapping arrows on the screen. So we went for a different approach: "operator stacking".
the idea is very simple: instead of explicitly listing the connections, two operators are connected by stacking one over the other. This has a number of advantages: it is a lot faster to work with, conserves screen space, and it enforces suggestive layout of individual operators (this may sound like a restriction, but is a very helpful in practice). together with "loads" and "stores" (which allow you to tag individual working steps and reuse them later in other places), this makes for a both fluid and effective workflow: nothing gets done twice. and as the complete "history" of operations leading to a given texture or mesh is retained, it's no problem if you find out you made an error right at the beginning - adjustments can be made anytime to any operator, and are automatically propagated to all its "derivative works", instantly!
which is another important aspect: everything is completely realtime - all necessary processing of textures, meshes, materials and levels happens as you edit them, and is previewed using our regular 3D engine that is also used for the game itself - so there are no individual export steps and bad surprises: what you see in the editor is exactly that way in the actual game too. and the tight integration of everything in one tool makes for features you normally just don't get, like changing a texture while simultaneously previewing it in its "final" form, mapped on a mesh.
and what does that have to do with making a 96k game? Well, instead of storing the results, we store the operators and their connections, allowing the game to produce everything itself - all it needs is the code for the operators, which is tiny in comparision to the size of most images and meshes, even in a tightly compressing format like JPEG.
