Slashdot Mirror

Try out .kkreiger from farbrausch/.theprodukkt. It's a first person shooter in 96k.

Been done: http://www.theprodukkt.com/kkrieger ... 96k game with fairly high-quality graphics

Try .kkrieger -- FPS game in 96kB

I agree that this is the ultimate goal of procedurally generated content - a whole world built upon a set of "simple" well-defined rules, some starting parameters and a little room for God to play dice.

Not only would this make the world unpredictable, un-walkthru-able, endlessly inventive and open, it would lend itself to more and more elaborate worlds as developers learned to optimise procedural generation and spawn more and more depth and detail without games becoming unwieldy to install. Forget Spore: see kkrieger for a real-world example of just how efficient and powerful this concept can be. (I'm also excited about Introversion's latest project, Subversion).

However, there are problems with this. The first and most obvious is that designing procedural algorithms to generate good quality content is an enormously complex and challenging task when compared to conventional content development. It's like the difference between building a creature by adding and changing organs (again, see Spore), and building a creature by coding some DNA from scratch and chucking it in a cell nucleus. It's much more elegant, but so very much more difficult.

Add some randomness into the mix to make the world not only procedural but also unique, and you have a hell of a tricky project on your hands. Setting the range of starting parameters, such that the resultant world will always be interesting and varied enough to be playable, would be very difficult, even with a very simple system - see the Game Of Life if you don't understand why.

Secondly, there is the subtler problem of how to make good game content. Talented developers spend years learning their art and the pitfalls of the trade, and even then can screw it up too easily. Making good scenarios and content is an impressive skill, and the result can only be judged in human terms - how can a computer judge what makes a good mission, quest, set-piece or whatever? Even with a simple thing like Sudoku, hand-made puzzles are almost always more satisfying, more taxing in particular ways, more elegant... Procedurally generating a really good puzzle or quest on a consistent basis is, I suspect, impossible.

I really hope that what you suggest comes to pass - it's the holy grail of PG games - but for the foreseeable future it's exactly that. Quixotically difficult, and quite probably an impossible fantasy.

I'm utterly convinced those hardware limitations are well beyond the performance we trudge through. As a gamer and programmer, this just irks me to no end.
When a game is first launching, screw the 3d map loading to display behind the main menu (*cough* HL2, et al.), just give us text and load the pretty if it has time to idle. While a cut/intro movie is playing, the disc drive's lens motor should be going nuts, scanning back and forth between buffering the movie and reading data for the next level (or better yet, the disc would be laid out appropriately for this). With the same tack, do something awesome during the unavoidable en masse loadings; have us read a briefing, let us tweak our tires, show us eye candy, whatever! If Pacman was 13.4 Kb, Dr. Mario was on a 28 Kb chip, and a pair of hackers fit .kkrieger into 97 Kb, deep pocketed houses should manage more than a spinning icon. Again on en masse loadings, why do we need them at all? When you walk through an areaportal, it shouldn't just take the nearby rooms' load off of the graphics card, it should start trashing and loading distant geometry.

It's like they're not trying. On the flip side, some recent loading screen news off the top of my head:
Dungeon Siege http://games.slashdot.org/games/07/09/08/0354231.shtml
Resistance 2 interview

I recommend .debris. By the people who made .kkrieger, that game in under 100k. It's just really, really good looking.

Fully agreed. As a coder involved in a FLOSS game project (as well as some commercial projects) I know first hand how hard it is to find a good graphics artist. Especially for a FLOSS project. It's much easier to find a good coder or at least a promising contributor than a usable artist.

Personally, I don't find procedural content to be a savior here. It's most promising for automatic generation of large universes (see Elite, Elite Frontier, ...) but not so much for the generation of textures. Unless you're creating a 96 kb 3D game.

"Procedural" refers to the fact that content is being generated on-the-fly, rather than stored in giant texture files. It is derived from the procedural scripts used to define the parameters for the object to be created (although with the power of scripting languages today, one could argue that this no longer applies).

One of the coolest procedurally-generated demonstrations I have seen is .kkrieger, which is a first-person shooter whose content is almost entirely procedurally generated. The effect of this is that the entire game fits into a 96 kilobyte executable (as in: you could fit 15 copies of this on a 1.44 MB floppy). Pretty cool stuff.

Personally, I'm working on a procedural map generation algorithm for a real-time strategy game.

... they generate buildings and clumps of grass and trees? And the textures on dirt have random mess on them to make less uniform and more believable? Something like that? (..) Are there screenshots of this?

Just for kicks: a nice example came out of the demoscene a few years back: kkrieger

I'd call it a 'proof of concept' 3D shooter. Nothing challenging, just a few levels you can easily walk through. Nothing exceptional on the graphics side. Runs on Windows like so many games.

But: a true HW-accelerated 3D shooter. Has enemies that jump / try to hurt you if you let 'em. A few big spaces to walk around in and admire the artwork on the walls. And all of this packed in an amazing 97,280 bytes! Hell, each screenshot on that site is already half that!

Procedural generation can be used for anything from models to textures to AI. In the case of textures it gives games the ability to generate them on the fly, allowing variation each time - so you can do things like making a different pattern of spots for a creature each time one is loaded. This also saves you storage space as each texture does not need to be kept on the drive, but comes at the cost of some processing power and RAM from generating everything and storing all the information in memory (for an extreme example check out http://www.theprodukkt.com/kkrieger, a game in 96k).

MegaTextures on the other hand are a way of reducing memory requirements by only loading the needed parts of a giant texture - so rather than have say 20 different ground textures loaded into memory it only grabs the part of the texture corresponding to the ground that's currently in the player's view. The texture file itself still takes up a lot of storage space. You can also use the texture to let the game know what kind of surface a player is walking on - say if you wanted to slow down movement when running over sand or something it's easy to do by checking which part of the texture you're loading.

Each has it's own benefits and applications, and it's not like using one precludes the other. They both provide ways of making textures unique and non-repeating but this is only a part of what they can do.

Actually the full name is "fr-08: .the .product". .theprodukkt on the other hand is a spin-off company of some Farbrausch guys to monetize their procedural content generation technology and tools to a certain extent.

Always thought the KKreiger demo was pretty impressive for only being 96k

Synopsis:

theprodukkts first product: chapter I of our experimental first person shooter. all the code, textures, geometry, sound, monsters and, well, lots of bugs - all crammed into 96 kilobytes.

http://www.theprodukkt.com/

> we will be tempted to include more and more content into our games.
People don't appreciate (or understand) how complicated reality is, until trying to simulate it.

Content will always be the bottleneck. Whether it is audio, video, geometry, AI, or narrative, crafting a good game is always about trying assets to keep these in control.

> I have believed, and still believe, that procedural content is the answer.
After seeing demos such as .kkrieger - chapter I (Quake/Doom quality in 96K!) I certainly hope so! The main drawbacks so far, are

- Loss of artist control. Currently, artists feel like they need control over as much as possible. I think the real issue is that it is just VERY difficult to adjust parameters to easily generate textures that the artist(s) want. I completely agree that we need better tools to map what the artist is thinking, to the actual output. ZBrush rocks definately rocks in this area.

- CPU overhead -- we just don't have the horsepower to generate "good" procedural textures in real-time. Basically why would I trade IO (loading) time (of premade textures) with CPU time (generating)??? As CPUs get this faster, then this balance will definitely shift to procedural textures.

What's really cool about procedural textures, is that we can have 'infinite' detail, or as much detail as we need, with next to zero increase in cost of time (artist or cpu.) I think this will 'win' out in the end.

> For years we've seen some companies stick stubbornly to building their own engines, a costly affair.
Are you talking about PCs or Consoles?

Let me know when you have an engine that runs on PC, PS2 and Wii. Not everyone is doing next gen PS3 and XBox360 games only! I'm not even going to mention the 'mobile' market.

> It is like the car factory that insists hand-built is better,
Hand-Built is better, the problem is that it doesn't scale (up.)

This is what, the 4th paradigm shift of game development?
1) The move from 8-bit to 16-bit and to 32-bit
2) The move from 2D to 3D was pretty big (i.e. we can now blend any animations at run-time.)
3) Streamed data
4) Coming up with better ways to create large content creation is probably the next big shift.

Cheers

--
'Cuz Wii, had a better sound to it then Gamecube 1.5 :-)

I'm reminded of theprodukkt, a coding group that released a first-person shooter that takes up about 96 kilobytes. If this is possible, it's amazing that comparable games tend to take up gigabytes.

Here's a good example of procedurally-generated content. A basic fps in 96k.

Ah, you mean like fr-08: .the .product by farbrausch http://www.pouet.net/prod.php?which=1221

An awesome 3D demo in only 64K
or Krieger: http://www.theprodukkt.com/kkrieger
A demo game in 96k that pisses all over Quake 2/3 in graphics terms, has real time lighting, shadows, bump maps, everything!

Code-generated art is a really good idea. I played a concept demo of a 96k FPS that generated its textures by emulating how artists make textures for games. A smart game engine could be designed that "creates" the art in the background while you are playing, and then caches it for later use.

PC Games tend to come on DVDs these days, even the fastest broadband would take long enough to download 4.7GB

So leave the downloader on overnight. How much does such bandwidth cost vs. sending a DVD via FedEx or UPS or round-trip bus fare to a game store? And if you want instant gratification, then include the game engine and the training mission's assets in a separate download, and download the rest of the missions while playing the training mission. Or you could use algorithmic textures to squeeze an entire game down to 96 KB.

The context definitely mattered here. At the Game Developers Conference most of the audience already understood the concept of procedural content generation. I would like to think that most of them had played .kkreiger already, a 96kb game that uses the PCG concept to produce an environment prettier than most modern 1GB games.

The idea is not very new. What Spore is doing is taking it to new heights. EVERYTHING will be generated procedurally. The game might realistically only be a few dozen megabytes. No textures, no models, no animations, no sounds. Just code for PRODUCING textures, models, animations, and sounds, given randomized and user-provided input. Assuming you have the code to figure out how a legged creature walks, theres no reason to store animations for 4, 6, and 37-legged creatures seperately. The video shows a 3-legged gait, iirc.

Currently, games come on DVDs, either single or dual-layered. That's 4.7 or 9 GB.

The PC FPS .kkrieger comes as a zipfile. That's 0.000096 GB. Not all games have to be huge, and procedural synthesis is one tool to compress games to a decent download time.

It was .theprodukkt. And yes, far less than a meg, only 64kb in fact..

But how many of those sequals had to include the now mandatory hi-res textures for HD resolutions?

If developers can use procedural synthesis to fit code, maps, models, and textures for an at least current-gen-quality first-person shooter for PC called .kkrieger into 96 KiB, then who needs even a DVD?

I'm sure space even on DVD-9s will become tight as higher res textures and models are packed into games.

O rly? If this first-person shooter fits in 96 KB thanks to procedural meshes and textures, imagine what you can fit in 8,000,000 KB.

Look at kkrieger (can be found at http://www.theprodukkt.com/). This is a first person shooter demo that is on par with most first person shooters today...

Okay, that's neat as a demonstration of techniques, but saying that it's on par with most first person shooters today is incredibly disingenuous.

There's no challenge, it's about 10 minutes long, the sound is as good as nonexistent (there is sound, but it's awful), I could go on, but that'll miss the point. It's nothing like modern first person shooters. It's not impressive as a game at all, just as a demo.

I have to wonder if you've played any of the latest games - give F.E.A.R. a try on a beefy box and you'll see where the size of the content comes into play.

High-res textures and higher polygon counts causing more disks? That is kind of hard to believe. In general even if a model is very poly that shouldn't take up too much space. If they really need more then one DVD for models and textures they need to learn about data management. There are lots of ways to reuse texture and make the games look good.

To me it seems like the problem is video based. Videos take up a lot of space on a disk, especially since they now have to be HD videos. They should rely less on pre rendering thing and think about scripting things with the game engine.

Games should not have to use 40 Gigs of space. Look at kkrieger (can be found at http://www.theprodukkt.com/). This is a first person shooter demo that is on par with most first person shooters today, and it only takes 96 kilobytes. That can fit on a floppy disk!

If you need more then a DVD for your game there is defiantly a ton of optimizing you can do.

• Shot #1 - This is screenshot from our prototype running in realtime. That's a shot taken at 80x60 (4-bit color), but it can go as high as 100x80 with 32 colors on higher-end machines.
• Shot #2 - This demonstrates the engine's realtime shadowing. Every single pixel has its own shadow, which is something no other platform can say. Further, it's done without pixel or vertex shaders, making it compatible with older systems. (However, they must support the Photoshop "emboss" plugin.)
• Shot #3 - In 1998, lens flare was all the rage. 2005 is the year of the bloom. Or maybe it's a glow effect? I can't remember which one it was -- I'll check with our marketing department and get back to you on that.
• Shot #4 - You're thinking, "Hey, that's nice, but I bet you can't do all three effects at once." Well, we can, and we did.

Ah, this talk reminds me of kkrieger: takes up 96k diskspace but requires 512MB ram, a 1.5GHz processor, etc.. :D (requires DirectX 9.0b)

"lower quality" is a silly 'argument' for .. physical disc size.

Awesome.. :)
This reminds me of kkrieger, a beta first person shooter in 96k (requiring 512MB ram, 1.5ghz processor, um, DirectX 9.0b)

That's mostly like the sort of tech used in today's 3D games. It would be real easy to make such a 'movie' interactive. Walk around in a scene, or choose a character to follow in the story, and tag along with another character when you view the movie next time.

The first time I ran it, I was very impressed with the intro of the game Half-Life. You sit in a rail vehicle, can't get out, so the story is very linear, but you can move, look around, all sorts of things happening around you. If you know the game, you'll know what I mean.

If you see that some skilled coders can cram incredible demo's, or even a FPS in a 100 KB., it's clear that the amount of data to process is do-able. It's really just computing power that's needed. Today's home PC's aren't yet powerful enough to pull this off, but we're getting there real quick.

So I'm wondering... I'd like to get some input from some game developers (professional or otherwise), what is the design mentality behind optimizing game content? I mean, after playing DOOM3 this week and seeing how completely immense game information is getting, doesn't it seem to make more sense to try to automate as much as the game as possible, rather than manually creating so much of the contect (art, FMV, etc.)? How much are developers concentrating on actually trying to use LESS space but deliver MORE content? I understand there are certain things that will always take a lot of space (music, voice acting, etc.) but is there any push at all to create games that don't need as much space?

There is a cool little game/experiment called kkrieger that has been able to present some pretty impressive graphics by rendering them dynamically as the game starts, so it CAN be done. But is anyone doing it?

I believe it was created by the guys at .theprodukkt. Heck, the front page link even goes to www.theprodukkt.com. How can the mods not notice this stuff?

Yeah, theprodukkt have released things with the "fr" imprint, but notice that they only mention Farb-Rausch in the past tense on the current page, and that the linked Farb-Rausch page is just a collection of links, not really a page at all.

the system will have two processors, with an ARM-9 CPU running at 67MHz and an ARM-7 unit running at 33MHz. Retail DS devices will have 4Mb of main RAM (while debug development units will have double that), with additional chunks of cache and shared RAM for the processors and 656Kb of video RAM.

You know, despite the fact that these specs don't wow the average desktop gamer, after seeing this 96kb first-person shooter, I think the sky's the limit as long as they've got competent programmers. Moore's law supposed to point to resources available, not resources used.