kkrieger: Making an Impossible FPS | Nostalgia Nerd

it's 2004 the dvd is overtaking vhs for home viewing pleasure the cd-rom is reigning king as the gaming storage medium of choice and usb sticks are becoming affordable for moving data from place to place the average game now consumes hundreds of megabytes in storage but despite this squarespace have sponsored this video oh and somewhere in europe a team of developers have created a first person shooter that will fit in under 100 kilobytes 96 kilobytes to be precise or if you'd prefer 96 000 characters how in the holy land of smeg does a shooter like this fit not just once on a floppy but 14 times to put this into perspective the original 1993 doom shareware consumed around four megabytes of disk space the original duke nukem took up about one megabyte this pdf document that contains the script of this video consumes 104 kilobytes this literal screenshot of krieger well that consumes 96.1 kilobytes seriously there it is in the file system what gives to answer this we have to go back to the year 2000 and visit the demo scene [Music] of course the demo scene had been around for many years before this but we're interested in a german group known as farbrouse the members of which had been involved in the demo community for many years already but on the 29th of december 2000 at an event in denmark known as the party 2000 a meet-up where demo teams got together to show off their latest and greatest real-time productions they pushed out a demo they called fr08 the product and it was mighty impressive [Music] the product was not only fluid incredible looking and filled to the brim with shading effects transparencies lighting eye arousing textures and a thumping soundtrack to boot it's also compacted into just 63.5 kilobytes think about that this demo could technically fit into the memory of a commodore 64. that's staggering of course it wouldn't run on the commodore 64 in fact it needed a pretty beefy pc at the time to run it smoothly and that indicates a bit about the trickery going on because despite its diminutive initial size the full 11 minute demo produces the equivalent of 159 megabytes of waveform data 170 megabytes of textures 80 000 colored and textured triangles in 5.7 megabytes of static vertex buffers and a crap ton of animated geometry all in totaling 1.9 gigabytes of data or from a file just under 64 kilobytes in size that would equate to a compression ratio of thirty thousand to one if all this data were literally compressed but of course it's not that simple and that would be one hell of a compression algorithm if it was so the demo label farbrouse who also masqueraded under the company name the product spelt with 2ks consisted of several members gizmo chaos 502 kb dodge rig wayfinder and yoda it was fiverr two who first realized that only a few primitives and filters were required to create realistic looking textures and so created a set of building operations based around these from this a couple of basic patterns could be used to generate hundreds of seemingly different and realistic looking surroundings from what was essentially just a macro procedural generation and if you look throughout the demo you'll see names applied to textures which indicate the type of operations applied these parts of the code were created in assembly language to aid with speed and code size whilst the remainder was created in c plus due to its useful combination of low and high level componentry the music created by kb is just a compressed down midi format which just tells the sound card what instruments to play and when essentially this is music already in macro form far browse demos would increase in complexity during 2002 and 2003 including fr19 poem to a horse and fr 30 candytron which included character animation and vocals again all in 64k but the seed for a fully playable fps had been in the team's minds since 2001 and in fact fr30 candytron incorporated the same codebase that would be used for that project by january 2004 in the words of rig we had been working on it for a long time and badly needed a break but we also didn't want to go to break point with empty hands so we had to release breakpoint 2004 is a huge demo scene event in europe and was set for april the 9th to the 12th it happened to include a 96 kilobyte game competition it was this competition that their 3d modeled fps krieger would be entered into and triumphantly win quickly going on to become an internet sensation and let's be honest going viral on the internet in 2004 was no easy task krieger by the way is german for warrior and it certainly won this battle [Music] so how was this heroic feat pulled off well krieger relies on some of the tools and tricks of far browser's earlier demos but there's a huge difference between a non-interactive demo and something that you can not only interact with but actually play and advance through an interactive experience has to be ready for you to look in any direction at any time to be able to walk close to objects to walk away to activate doors and obviously to provide weapons and foes to beat down but just like demos it's the textures which traditionally take up the most space fr-8 of a product used an in-house developed tool called the vergsike to create these textures krieger used an updated version vergazig 3 and it's incredibly clever here are three patterns pay close attention because these three simple patterns which are created from scratch using an algorithm every time the game is run were the basis for every single texture in krieger but how do you get from this to this well you create routines which replicates some of the well-known photoshop filters and deformations such as blur twist bump map and distort add some color correction change the tint contrast and hue and already you're getting somewhere close the clever bits come in the form of say applying a blur filter then subtracting the original image and modifying the brightness now you've got an outline that can be multiplied and rotated with other outlines and soon you get some pretty complex looking textures all without anything pre-rendered at all this wood texture was created using those exact methods a combination of noise filters blur twirl and colour distortions same with concrete and stone starting from different base patterns importantly because these are all rendered in real time it doesn't matter what resolution or how far you zoom in the game engine will automatically accommodate for the difference and show these real-time textures in distinct clarity in fact there's often so much detail in these textures that your mind glosses over them and this is actually noted as a fault by fiverr two and gizmo discussed in a 2004 assembly presentation but before that the same is true in designing a lot of things including websites that's why squarespace has a multitude of clean and clear templates for you to choose from if you've got an idea that you want to grab people then you don't want it to get lost because of poor design choices just look at all these templates you can choose from just pick the one you like and then effortlessly make it your own squarespace allows you to turn your site into a blog a shop a showcase whatever you want you can even use it to set up email campaigns you could get started as soon as this video is over and then grab 10 of your first website or custom domain using the link below and another thing is the textures simply have too much contrast every single texture is so full of details that in the end it's uh yeah there's so much different detail that it looks like no detail another clever trick is to employ standard windows libraries and even fonts this texture well it's just the letter g in the aerial font with a twirl noise and bump map applied to get more complex and structured textures you can just combine some of these simpler tiles use multiplication routines and make use of alpha channels to create the defined objects that you need to replicate a sewer for example this on the fly creation means that the game actually expands to occupy about 300 megabytes of memory when running which is more typical of an actual fps game from this era with pre-fabricated graphics and that's because once the graphics are actually created and posed to us as images well they consume the same amount of memory as the image would in addition to the lack of large assets clever use of the standard windows dynamic link library set for window management graphics and memory allows a lot of code to be farmed out or outsourced saving space that might usually be taken up with custom code naturally this includes the use of microsoft directx which was utilized extensively including its lighting model and pixel shading abilities in fact these could be combined with texture bump maps to create accurate lighting effects with minimal further work it's for that reason but you'll find bump maps employed throughout the game even when they're not strictly necessary such as on weapons as it just creates a more pleasing level of light reflection but what do all these textures wrap around well that's the job of mesh generation using 3d objects such as cubes spheres and cylinders textures can be applied and then similar deformation procedures can be applied to these models one of these is a simple bend it just creates a much more realistic environment and that's why you'll see long winding environments in this very linear game map the use of a linear level again a space-saving necessity but the winding and bending of it creates the illusion of a more diversive playfield all these elements are applied in versailles using operators some operators will create meshes some will create textures others will apply effects like blur and bump others will apply distortions or add bends everything is an operator and by stacking these operators on top of one another and forming connections in the operator stacking environment created by chaos it provided a visual way of creating the world which could be seen in real time through a preview window this is actually version 1.2 i'm using and you can see how i can add particle operators with transform operators a material operator and finally some camera and time operators to make the views spin around and get this output tools like this sped up the development process massively producing lightweight efficient code without creating it from scratch the beauty is this tool can be used for almost everything in the game engine including characters the character models draw from fr30 candytron and again employ the use of primitive shapes stuck onto one another the operator stacking system could also be used to manipulate shapes combined with movement operators to create fully animated models the only problem being the movement was mostly based on linear ramps such as pivoting a leg forward pivoting the next leg forward and so on but it looked janky and dated or in their words like n64 character models this is just like a n64 style what basic primitives together and um we are we are far far away from that nowadays but i mean come on it's 2004. we're way past that the solution to this was to introduce trigger operators for example if you move a leg forward an arm movement would then follow this allowed for slightly better looking characters and it's also why the foes have massive arms or multiple legs by drawing more attention to these reactive elements these creatures look more natural and flowing than if you witnessed just singular leg movements now although all the textures are created in the initial loading sequence which saves some processing time there's still a lot of real-time processing going on so we've got character-based animation and the complexity of the world and this meant you'd need something pretty beefy to run it like an intel pentium 3 clocked at 1.5 gigahertz half a gig of ram and an nvidia geforce 4 ti we're talking high specs for 2004 but boy was it worth it well kinda we can explore the gameplay a bit later okay so that's most of the space saving taken care of but we're talking compressing all this into 96 kilobytes this means that even with the textures done away with the coding itself needs to be ridiculously small and compact and for a team of developers and designers working part time this fact alone meant the game almost didn't make it into the competition at all in a post entitled meta programming for madman the rig block details the endeavour from fabian gizen's perspective and you can feel the intensity of those last few weeks bursting through the pages while being a nice technical challenge it was a complete failure as far as the game side was concerned we very nearly missed the 96k limit too our most serious 64k demos were somewhere around 70 to 80k a few weeks before they were supposed to be released the last two weeks usually ended up turning into a frenetic rush to simultaneously get the thing actually finished and make it fit within the size limit there's three different steps to making sure you get small code architecture design the code in a way that enables it to be small evicting ballast there are going to be whole paths of code that are just not getting used detail work it basically boils down to figuring out which functions are larger than they should be and what you can do to make them smaller i actually had a chance to speak to fabian about implementing the architecture and specifically the 3d engine the code of which is available on github and although the coding was a crucial element to get right here he downplayed its significance in terms of game engine compared to the graphical work ultimately it boils down to having some arrays in memory the gpu can access and then periodically giving the gpu a command to draw from these arrays due to the limitations of the pixel shader 1 hardware it was imperative to have a robust system for sorting draw commands and efficiencies could be made through the level design because levels are just a series of connected rooms and corridors anything not in the player's room can only be seen through a doorway meaning a lot of the world didn't have to be redrawn really the main bulk of the 3d engine is memory resource and lifetime management and getting these as trim and efficient as possible this is almost all standard c plus plus code compiled in optimize for size mode and making use of visual c plus pluses function level linking which puts each function in its own section and only links and compiles functions that actually get referenced which we'll get to in a bit chunks of inline code are written in assembly along with the inclusion of assembly source files mainly for speeding up and to reduce dependencies negating the need for chunkier c plus plus libraries interestingly most of the development time was actually developing the tools such as worksite for artists fiverr ii and gizmo to use it's also interesting to note that krieger was made on the cusp of systems moving to 64 bit and one of the biggest constraints faced by the team was the 2 gigabyte limit of 32-bit systems at the time given that the tools and content editing would consume 1.5 gigabytes of ram alone with another 400 megabytes for the game to run on top of that these guys were really up against the limits of conventional desktop pcs at the time this might be a 96 kilobyte game but it chunks out hugely when written into memory so the architecture itself could be developed fairly normally but the next part evicting ballast and the detail work would be crucial in getting under size the first playable versions of krieger were 120 kilobytes so it was down to these steps to shave off those extra few precious kb and a lot of this had to be done pretty close to the wire again by developing tools to do the heavy lifting so in the final days with time rapidly running out chaos created a passer named lector to go through the c-plus plus code and essentially find anything that was redundant and broadly speaking here's how that worked okay so here's an if statement now you'll have to forgive me this is pulled from riggs blog but it's been a while since i was knee-deep in any form of c coding thankfully but the parser would run through each statement numbering as it went leaving a trail of breadcrumbs this would highlight any parts of code that weren't being executed in this if statement it was determined that msm sub and msm set not only get called if the variable state is true therefore the if statements nested here are redundant that code would then be replaced with if 0 if the path is never taken or if one if it's always taken which essentially renders each if redundant so simplifying this find and replace operation would work through the entire code and then upon compiling into an executable the compiler itself would recognize these issues and strip out the logic queries completely because they were redundant therefore saving precious bites things like this were done with a fine comb throughout the entire code to shave those extra few kilobytes off as you might imagine the upshot of this was that actually it forced a few bugs into the game because to determine the paths which weren't executed the game had to be tested and during that testing if no one decided for example to try pressing the up arrow on the menu screen that pathway to trigger the action would be stripped out meaning you could no longer press up on the menu screen it also meant that some collision detection was removed as it was never triggered during test runs these issues did actually creep into the first compacted versions and some remained in the released beta basically this was code stripping at its most desperate and also dangerous the final step was to use an executable packer to compress the file down as much as possible in this case an in-house utility called crunchy which utilized a similar compression standard to zip files but had extra functionality like being able to tell you how well certain coded functions would compress allowing final tweaks to be made beforehand okay look this is dramatically over simplifying it because crunching down or packing an executable has been one of the most important and intensively developed parts of the demo community for years how do you think crack has got so many games on a single floppy disk in crunchy's case the magic is performed by a number of factors but there's a package created by rig called this filter which disassembles the binary x86 code and compacts the lzma compression by an extra 20 percent on average but compression is an entire subject in itself so what's important here is that this cruncher is what got krieger under the required size the upshot of all of this was that the game came in at just under 96 kilobytes in literally the final hours before the competition deadline allowing it to grab the event and indeed the internet shortly after by storm i mean come on this is an incredible feat of problem solving design and coding especially for a team working solely in their spare time [Music] so of course we have the odd bug such as getting stuck indoors enemies getting stuck and there are lots of elements that the team wanted to improve upon including the addition of light maps better level design a brighter environment and the textures having less contrast but it's playable it feels coherent for a shooter of that era and it definitely looks very good what i find really interesting is how thomas says he almost felt like he was peering into the matrix by the end seeing the real world just like krieger as simply being made up of algorithms and mathematical shapes and models which of course it is if that's not booth for thought i don't know what is unfortunately although promised an updated finished version of a game with multiple levels never emerged this version was hoped to clock in at about 120k but given the cat was already out of the bag anything released afterwards would have been anti-climactic and i completely understand why the team never felt enthused enough to revisit it that's not to say they didn't do any work on it though and indeed some source code does exist for krieger final i'm actually talking to rig about getting a version of it up and running as i type this if that happens stay tuned on my second channel for a play through because that will be incredible but ultimately it was an experiment these were demo scene coders who enjoyed the thrill of creating something that pushed the limits of the current hardware that dazzled the senses and although krieger had certainly done that the gameplay aspect of it was really more of a novelty than anything else it was hoped more could come of it and the product did attempt to package up versailles and the krieger engine to sell it commercially but i get the feeling that the team weren't really behind this idea and in fact rigg spells that out clearly on his blog the demo team did make a few more creations including the incredible fr-41 debris which clocked in at just 177 kilobytes but the product as an entity was officially disbanded in 2011 leaving krieger as an incredible showcase at a time when most games were enjoying the new freedom of cheaper storage and getting larger rather than smaller this whole experience really makes me miss the bottlenecks of older systems i mean even more so than i already do they demanded that developers be much more efficient and creative with their visions than the more mindless high-level freedom that current technology offers so i find it so warming that demo scene coders were still propelling these ideas forward into the naughties and even still into today whether it's to save space or just speed up a game engine it's just fascinating to be given constraints and then create something as impressive as possible with them that's what krieger does and it's why so many of us myself included adore the vintage hardware and the limitations it still imposes i've been nostalgia nerd toodles [Music] you

Channel: Nostalgia Nerd

Views: 1,106,574

Keywords: kkrieger, farbrausch, demo scene, fps

Id: bD1wWY1YD-M

Length: 28min 49sec (1729 seconds)

Published: Fri Apr 23 2021

Reddit Comments

[u/begginer_PC_builder]

Breaking news: man says fuck you and compresses his game with a hydraulic press

[u/Nodinox]

It’s amazing how they worked out procedural material generation years before it hit mainstream. Nowadays I use it every day to generate near photorealism. Remember HL2 and doom 3 came out in 2004. And both cheated a ton with their textures and geometry. Doom 3 of course mainly by not letting you see shit. And I remember they were freaking huge in regards of file size. And the whole concept of bump-maps didn’t really yet catch on as far as I can remember. It’s been a while since I last played it, but I’m sure Vampire the Masquerade Bloodlines would have profited from using stuff like that, instead of just fairy simple texture mapping.

[u/GameStunts]

I was just watching this and was thinking of posting it here, did it come up in your youtube recommendations?

I loved the demo scene, I can remember other demos that fit in 64kb as well by using direct-x tricks and libraries it was impressive as hell, but an fps in 96kb is very impressive considering that includes game mechanics etc.

I fell in love with the demo scene on the Amiga, my favourite was Love by Virtual Dreams & Fairlight. Looks blocky as hell to the modern eye, but this was running on a power PC Motorola chip running at 15mhz with 2mb ram and demonstrating really cool effects like clipping 3d objects, early shading and refracting rendering, in 1994 on a machine that had come out in 1992.

I also appreciated the little end credits where they would try to reach out to people they hadn't heard from.

[u/[deleted]]

Omg I remember this from years ago

[u/mk7eam_Requiem]

O shit i totaly forgot about this, it was unheard off!! Every said its was fake.

[u/Kittylaser]

I've been looking for this for years! I played it way back in the day and I couldn't remember what it was called.

[u/EvilSpirit666]

Yes, I clearly remember the mind bomb that is .theproduct. Thoroughly impressive even today, or maybe rather particularly today.

Edit: Although, did it really need a "pretty beefy PC" to run? I remember being able to run it without any trouble and I have never had anything near, at least my concept of, a beefy PC

[u/Obokan]

My PC died while running this game back in the day, but it did look beautiful from what remember.. The bloom effects and shiny metallic materials.... Wonder if my 3070 can run it

[u/Mightbebullsh]

Step 1: Tap into the hundreds of megabytes of resources and routines made available by the DirectX package.