Good article. Though it does sound very similar, in theory at least to vector graphics and games. I think 97kb is pushing it though, I'd be happy at half the space current games take up. The regular HD format means yet another HL2 download... and at 512kbs it isn't pretty. I hope this is adopted, though I doubt the big industry really cares.

Woah. Cool.

I'm sure that we'll see advances in programing that will dramatically impact and improve gaming. I'll have to research this...

For a long time I've thought that they'll be a dramatic improvement in physics programming coming soon. Programmers will drop in a physics environment, tweak the properties to their specifications, and be done with it.

For example, there could be a standard "Earth" physics library, or an "other world" physics engine, etc. Tweak the way certain classes react, and it'd be done. Then programmers could be off to develop something else important. And we'd have fully interactive environments.

Hey I tried to argue for the longest time that it's not the power of the machine it's how well the developers create software for it that can make the graphics good....yet everyone instisted on slaming me for those kind of statements.

Finally a developer that has done just what I have been ranting about can prove it. This person deserves recognition throughout the gaming and technological community.

Wow, a Madden that you only buy once for the graphics and gameplay, then only pay $5 per season to update your roster. Save the Developer time and charge more for the initial installment. I'm down.

We have been using "procedural synthesis" in our demos (as in the demoscene) for almost 20 years, its nothing new, but it's really interesting.

Is this the same as software decoding, that a lot of FPS computer games of yesteryear use to support for systems that didn't have a graphics card with a 3D accelerator or is this something completely different?

What ever the case my be, to Joystiq's question about re-releaing last gen games on next gen systems with improvements, I say they not waste their time chugging with remakes.

The funny thing is that a lot of games use rendered procedural textures. They built the texture using layers of procedurals in 3ds or maya, and then they "froze" their textures into 1k images to use as textures in the game engine.

Hmm, wait billychaos. This proccess basicly makes "the power of the machine" the deciding factor on how the graphics will turn out. If CPU time is consumed, graphics will suffer, if your CPU rocks and is left otherwise idle, you'll get some pretty slick visuals. But if there was any a time where it depended on the power of the machine more than anything, it would be with this kind of technology.

Damn I have the machine specs and all but this demo won't run... was really looking forward to it! Crashes right in the loading section.

The 360 has been designed with procedural synthesis in mind. Abrash et al designed the system with the ability for the graphics chip to lock down part of the L2 cache and reserve that for use as a direct pipeline for generative content.

The graphics chip actually does the rendering from the high level descriptions. Otherwise, it's too bandwidth intensive to push all that crap across to the graphics chip.

any example of this game with a bad, mid-range, and high cpu? i'd be interested to see how much changes

@ billychaos, actually... .kkrieger doesn't prove that at all. It requires (especially when it was released in April 2004) a pretty loked machine to run smoothly. minimum specs are a 1.4GHz processor with 512mb ram, a graphics card with pixel shader 1.3 & DirectX 9.0b compatability. Those are the MINIMUM specs of a demo that was released over 2 years ago. I've never seen the game run smoothly on anything under a 3Ghz processor with 1Gb of ram... So it proves that file-size and graphical quality are not tied directly together, but the "power" of your machine is intimately tied to graphical quality.

@ Mr. Miller, it wouldn't really be a logistical nightmare for devs/publishers. The realism wouldn't continue to improve just by virtue of a new cpu/gpu. Aaron spells it out perfectly in the last page of the article, the advantage of procedural synthesis is that it would make it easier to patch a game to take advantage of newer hardware; it can't magically upgrade poly count or take advantage of new shader models without new code though. Honestly a far more likey scenario, IMO at least, is that EA wouldn't offer patches for last year's copy of madden, but rather use procedural synthesis to effectively sell us the exact same code-base/game over and over again, with less time/money spent on developing said "new" versions. Of course, they most likely do that to us already...

This game has been criticized for its stability, as it depends almost entirely on procedural synthesis.

Anyway, there is no way for developers to depend that much on Procedural algorithms. What if you need the CPU for other things?

Procedural generation is good, but it isn't the second coming. You might want to save CPU power for other things, while leaving some things static. You might want some extra space. The cinematic effects you want to give to your game need "next-next-next-gen" visuals, therefore making it impossible to generate, and needing cut-scenes (and therefore, SPACE on discs).

What I'm trying to say is, you shouldn't have to rely on it, as it's not always the best solution. It's good, but other things that would be sacrificed are also good.

To be honest I wouldn't want any older Zelda/Classic game to be remade like that. Alot of the charm imbued in those titles are the graphics- while A Link to the Past isn't exactly realistic, it's very stylized and colorful, that alone which holds alot of great memories for gamers

It's the 2-D nut in me!

Oh, and as somebody said, if this is heavily relied on, then why should I pay 60 bucks for 96 Kbytes of content?!?

As the text says, the procedural synthesis requires processing time. Lots, and lots, upon lots of processing time. Sure, it may save you some storage space, but in exchange for what:
A) A game with less on-screen content, less physics, less AI, and so on.
OR
B) Insane loadtimes and huge requirements on RAM to store "rendered" data in

To me, the sacrifice of any of those bits, is something that would be completely unacceptable. It can be used for good though if used in SERIOUS moderation. But to go off and believe that with this technology, we can simply produce next-gen or even current gen full game titles, and have no pre-generated content such as models or textures stored on a physical media (HD/DVD/BD), would be foolish.

Try to run kkrieger, and you'll soon discover that it chews up 500MB of RAM and at least on my top of the line gaming PC takes almost two minutes to start. And the graphics, cool and good looking as they may be, what is and will be available on next-gen systems shortyly, will be surpassing these with polycounts and textures of insane numbers and sizes. Keeping all that in memory is not possible on a next-gen system such as 360 or PS3, and dynamically synthesising all these assets on-the-fly as needed is not even to think about.

If it could be used for anything, it would be as for such things as elements in spore which are more simplistic in nature than what you would find in 99% of all other games. Or in things such as some types of maps, characters, nature, or other things which need to be dynamically created for a "random" experience.

Perhaps when consoles come equipped with something simmilar to a 24 cluster Cell or somethign along those lines, and have 4GB of extremely fast RAM to operate on... than we may see fully synthesised games, but I'd bet that even then, there would still be somehting that makes full utilization of such a technology infeasible or unpractical.

Especially, if it takes them a lot less to make!


(Sorry for spamming....)

@ kleger, the graphics on .kkrieger don't scale according to the system they're running on. Depending on the computer in question, it'll run not at all on a low-end computer, slowly on a mid-range, and of course smoothly on anything high-end. being a 100% Procedurally generated game, the requirements of the memory (96k on hdd, but 512mb to create textures/etc for the game) and cpu/gpu are intense.

Just to be sure I dont want people to mis-understand my comment about not being the hardware but software. My argument was that developers are not thinking as hard as to improve their software as opposed to waiting to for the next best hardware to come out to support their monster of a game.

That said, I did run the game on my machine. I have a gig of ram so I didnt realize it taking 500 of it. But the graphics look very very well on my PC that struggles to run the Sims 2. Even when getting very close to walls or objects the textures do NOT get grainy.

"It's good, but other things that would be sacrificed are also good."

What are these "things"? with the onset of multi core processing, what has to be sacrificed? This article is mostly looking at this technology for graphics rendering, but what happens when you have beautiful artist created with procedurally created physics. spore uses it to determine how your characters walk, hunt, use tools,eat, etc.

Kinda Makes blu-ray and Hd-dvd look very unnecessary in gaming in the future when this gets some steam behind it...get it steam? ahh never mind

I want a completely NURB-based game.

All of you are looking at the big picture here, when really you should be looking at the smaller picture. Sure incorporating this technology into retail games is probably still impractical, except in small doses like with the trees in Oblivion. However, imagine using Procedural Synthesis on XBox Live Arcade games. Or PS3's downloadable games. Or on Nintendo's Virtual Console. If used correctly procedural synthesis might be able to produce sweet looking graphics with very little harddrive space required, which would be perfect for XBLA with that 50meg limitation. Imagine being able to download XBLA games that look as good as XBox games for $10. I'd be down with that.

Also as a note, the article did mention that procedural synthesis will likely not be used until XBox 720 and PS4, due to how much processing power and RAM it will take to run smoothly.

I'm scared that they'll start producing less games. I agree with the Madden question. Would we start seeing the generation gap between consoles shorten? Would video gaming start moving towards computer gaming where you have to constantly get newer hardware to keep up??

Ross, Ocarina of Time already has a GameCube cersion. Remember the pre-order bonus for Wind Waker? If they've kept the scripting system compatible it would not take much to use the Twilight Princess engine to run a version to OOT. The biggest immediate need would be the appropriate art assets.

The article mixes apples and oranges. Procedural synthesis and scaling are two different issues. Stuff produced by PS lends itself well to scaling but a game will only be a sharper version of what was always there. It will not gain additional details there were never part of the original code.

The Xbox 360 BC already uses scaling to run Xbox games at 720p but while the effect is very nice it doesn't create new details. It just makes the same stuff look better. A game can be almost completely scalable without any real PS being used. Abstract very high resolution textures will find their limit eventually but how much should a developer in 2007 be concerned with how his game might look on a Ultra-HD display that isn't likely to be widely used by consumers for at least twenty years?

Pretty much any mathematically generated object can benefit from scaling on more powerful hardware and that applies to most 3D games. It's like the difference between a draw app and a paint app. Draw programs deal in object while paint program use bitmaps. The draw object can scale infinitely while the bit maps lose quality as they're required to cover a larger surface. Thus a PS texture can scale better than a bitmapped texture but for many objective the bitmapped texture is so vastly more convenient to create and use that scaling to look good ten years down the road is just not on the list of concerns.

The real advantage of PS, and one we're just beginning to see, isn't merely making a unique forest on the fly but having one that really looks like it grew there. Trees that are very close together will grow differently than widely spaced ones, for example. It does more than move past visual monotony. It gives developers the chance to create real worlds with making a single game their life's work. The system can generate thousands of square miles of believable wilderness while the developer focuses on just those spot where something interesting should happen.

This paragraph is completely wrong:
"In order to allow Xbox titles to be run on the Xbox 360, Microsoft included an 8 Gigabyte emulator on the harddrive containing information for each game compatible with the system. If a game like Oblivion were designed for it, it should theoretically be possible to upgrade a title by simply updating the mathematical algorithms to be more advanced as it moves to a faster processor."

Has he actually played an Xbox game on a new 360 system? Did he not notice that there was a download required? Does he really think this is what consumes 8 GB on a new 360 system? Any emulator that took up that much space should cover almost every game system and personal computer from the PDP-1 running Space Wars to the generation leading preceding the Xbox 360.

It's an OK article but he's very confused about some things.


#3 Billy, you have it completely backwards. Itis the immense growth inprocessing power that make heavy use of PS practical. If a believable human face can be generated in realtime from a few hundred K of data, that is a big win over storing megabytes of animation for the same face.

The game referenced in the article uses a very small code base but it requires a platform that can not only run Unreal Engine 3, which is a significant load before you've added any unique elements for your game, with the additional through put requirements to everything algorithmically rather than relying on fixed bit maps for most of the visual elements.

These aren't new techniques on the software side. Some of them have been around since the 70s but only used in pre-rendered animation. Being able to execute these algorithms in real time for improved graphics quality that can respond to inputs, for instance, a bashed in wall looks different depending how you hit it rather than just being a generic scripted event that looks the same every time, is a big gain for the realism. If I through a boulder at a wall I want a visible effect that corresponds in a detailed way to how far away the boulder was thrown from, how hard it hit, and at what angle. It may not change the outcome of knocking down the wall but it makes the experience much more fun.

This takes a lot of power. Back in 1981 the graphics for 'The Last Starfighter' took six months to render on a Cray supercomputer. Today, a game that delivered those graphics in real-time would not get a good review. The growth of machine power has raised our exectation for what the software will do. But it doesn't matter if the programmer has the techniques down tens years previously if the hardware can't let him make it work in a game.

#6 There is a conceptual relationship in that the early 3D era came about when systems got fast enough to do simple stuff in software but it was the advent of affordable dedicated hardware that made things really happen. As PS becomes a more common procedure more systems will be designed to better enable it.

Much as they did to create the MMX and SSE SIMD functions, processor companies will analyze game code and interview developers to find what ways their products can be enhanced to perform better for those types of use. This is especially true for groups of instructions that happen with great repetition, such as decoding compressed textures. Putting hardware support for that in GPUs was a big gain in memory efficiency for very few transistors dedicated to the task.

#7 Sean, that is true but the critical difference is that a texture generated in real-time can be altered by conditions in the game. It opens up all sorts of possiblities for creating more believable worlds.

#13 Boots, this is run of the mill decision making for game design. You lock down your static requirements for CPU time, then see what more is required to meet the minimum performance of the scalable elements. That gives you your minimum system requirements. People have been living with that ever since PC games began commonly allowing people to choose what resolution to run in. Reviews of video cards especially have long focused on performance of well known games at different resolution with various effects turned on or off.

#16 Kawf, how is this different than things have been for a long time? Many people found it preferable to play PS1 games on the PS2 because the faster drive reduced load times a bit. An entirely PS game would make for another item for benchmarking. A top system from a year later could be expected to have a much faster initialization of the game than the current speed king.

The thing is that tech stuff keeps evolving. What was once remarkable and expensive becomes cheap and run of the mill. A few years down the road, between improving broadband speeds and improving PC performance, a game like this could download from a web site almost instantly and be ready to play within seconds.

For stuff coming off a high capacity local disc there would of course have to be a more rational application of the techniques in mixture with more conventional approaches. Why spend weeks getting a PS algorithm just right for something that can be done much more quickly and satisfactorily by just having the art department deliver several versions of a bit map? As I said above, it would be ridiculous to future proof your game for an audience that isn't even yet born. If there is still call for the game that far down the road then surely it's worth paying someone to do some new work on it.

Doing a whole game as PS is today more of a stunt than anything else. It serves to demonstrate some of the potential but isn't terribly practical in of itself.

You guys just got word of this game now? This news is prehistoric. I'm talking over 2-3 years old.

T-Bag: They posted on the NEW about.com article, not the game. Chill. The. Hell. Out. Asshole.

@The Article: Sorry, but no.

Procedural Synthesis is kinda cool, yes. It can make for some fun effects, some really cool tech demos (like .kkrieger), and can be a great help in creating art resources where it would have been humanly infeasible, like the trees in Oblivion.

HOWEVER!

The idea of using it to create "Self Upgrading" Games is a bit ludicrous, if you ask me. For one, graphics that are generated entirely procedurally tend to look very artificial in large amounts (because, well, they are!) You simply can't match the touch of an artists hand with an algorithim. The best way of handling content like this is usually to let the computer do it's thing and then "tweak" it manually. Look at Enemy Territory: Quake Wars as an example. It has technology that allows the entire landscape to be covered by one gigantic high-res texture. This, conceptually allows an artist to hand paint the entire thing. This is, however, fairly impractical because of the work required so what they end up doing is procedurally generating the inital texture and having artist do touchups in places where it will be noticed. The results look pretty dang good in the end, but the point is that you've still moved away from entirely procedural, and therefore it can't evolve as it goes.

There ARE ways of allowing artist to create content that can "improve" procedurally, such as modelling in NURBs. The curved surfaces in Quake3 were a simple example of this, and with enough computing power it could be applied to pretty much everything. This is not without it's problems, though. Today's hardware, as fast as it is, still isn't up to handling those types of surfaces in large amounts (in fact, they're fairly hard-wired against it) and there's no real indication that that's going to change in the future. On top of that, though, one has to wonder what the real benefits would be to such a system, since after a certain point the eye can no longer detect the added detail. Also, you wouldn't get any extra fine details unless you added them into the base model, which negates the point anyway. And that's JUST for geometry. With textures it get's even nastier.

Finally, even IF it was feasible to create such a game, would it be worth it? Pure Procedural graphics are really really hard to make look good, arguably harder than creating content by hand, but in the end there's only so far you can take your graphics before nobody cares anymore. What really matters in a game is gameplay. Let's say the original Zelda magically upgraded itself to Xbox 360 level graphics. Would it matter? Hell, don't get me wrong... I think it would be great fun! There's a reason it's a classic. But would that negate the need/want for Twilight Princess? Would you really WANT to keep playing Mario 1 over and over again, a little bit prettier every time? No matter how fun the game, if the gameplay itself didn't evolve over time with the graphics the public would quickly loose interest, thus making all your hard work on making the graphics spectacular null and void. Now of course, you could get around this by creating some awesome procedural gameplay creation system (like that game from Enders Game) but graphics would be cake compared to THAT monstrosity.

Give me a hand built universe any day, even if it's a little dusty in the corners.

#5 beat me to it, but this has been a staple of "the scene" for ... heck, 15-20 years. There was an amazing one a few years ago that was a good 15 mins or so long and under 64k. Wish I could remember the name, still worth seeing today.

I guess I should have RTFA, it's the same guys, Proddukt. Awesome.

This would kill the software industry unless they took micro payments or upgrade fees. The hardware industry would love it though.

This seems like technology that's way ahead in the future (at least its deployment, since it's very unconventional). As you may have noticed, the article's most recurring phrase was "what if".

Thank God. It's about damn time people pay more attention to stuff like this.

For more than 10 years I've been waiting for somebody to base a procedural synthesizer on fractals (not just the "Photoshop filter" type of generators used by Farbrauch). It's not difficult, you just need lots of vector power to do it.

Even realtime fractal demos are extremely rare. Haven't game developers ever seen XaoS in action, or visited www.fractalus.com? Does anybody else have JuliaSaver as a screen saver? I'm sick of mp3 and ogg soundtracks, too.

What's really funny is that I'm listening to a ripped soundtrack of "The Product" as I'm reading this. Best 64K soundtrack ever.

As for the people complaining that kkrieger is slow, please keep in mind that the game was designed to be as small as possible, as a proof that is CAN be done. It's not designed for practical usage. That's what the demoscene likes -- breaking the rules. Also keep in mind that kkrieger is based almost exclusively on procedural synthesis. Real games would have a better balance of technology.

The TRUE test of a 3D engine is how scalable it is. Some 3D games have lightning-fast load times. Some, like Painkiller, are rediculously long. The reason why is because the "bad" games scale hi-res textures to fit into your video card memory every time the level loads. "Good" games don't do that -- they use caches. Apply caches to procedural synthesis, and you've solved the slow loading problems. Also note that PC games have to use scaling of some kind, because the amount of available memory is different every time you use your computer. Consoles don't have to worry about that (yet).

* Tom: "I want a completely NURB-based game."

Most 3D engines, even those used for movie special effects, have to tesselate NURBs into polygons for rendering. True, textured NURB rendering is a nightmare, and doesn't make a very big difference in terms of quality. You're better off with tons of polygons than throwing processing power out the window with true NURBs.

NURBs are entirely hype, I'm afraid.

I agree with some of the moe educated individuals here, Procedural Synthesis was what the xbox 360 was DESIGNED for and why currently the games look like crap, because the engines the developers use to creat the games are at least 2 years old, even the unreal engine 3.0 is pushing 4 and not a single game has been released yet using it. (the first unreal 3.0 demo was shown at E3 2004 its been around alot longer than that) As others have pointed out the GPU on the 360 has direct access to the CPU cache which basically streamlines this process and prevents the major RAM hang ups and requirements seen in the mentioned demo. In addition, the unified shader arch of the gpu allows the gpu to dynamically change the amount of geometry or shader effects on the fly, thus if a scene is more geometry intensive or shader intensive there are plenty of pipelines to allocate to either scenario. So lets look at the design of the 360, I personally like the structure as it offload almost all graphical data to areas beside system memory, IF used in the intended way. proedural content is rendered directly in the gpu from the cpu, the framebuffer is restricted to the edram. This frees the system ram considerably from constraits. The problem is Developers have been creating games a certain way for a long time and while using elements of PS have yet to full exploit it due to the lack of horsepower until now. Anyway you wont see a game engine that makes full use of this until 2-3 years down the road. As for the industry this is a HUGE bonus, most game content can be procedurally generated in some form. Textures, models, even sounds. Two examples of sound generationg are the ability to mix sounds on the fly, for instance a developer can mix the sound of metal hitting wood and rather than play the two default sounds at the same time. they can generate a new sound on the fly based of the properties and sounds of the two objects. A second example is Spore where based on the position and mouth, the system will generate a sound based on the way air would likely flow and how a creature of that shape and size would sound. Spore is only dabbling at what we can do with this concept. We can create worlds as large as spore on a single DVD, or create infinite detail in a microcasm. I know people claim its not the end all be all, however i beleive its the future of game development. Mostly because once written its several times cheaper than highing artists, plus they can reuse variations of the code in other games. Basically devs do nothing but win from using this method.

" If a game is made entirely using algorithms, could an older console game look vastly improved
on a next-generation machine? Imagine Ocarina of Time looking like Twlight Princess."

Procedural synthesis has nothing whatsoever to do with porting older games. You could rewrite Ocarina completely to use procedural graphics, but then you could rewrite it completely to use the graphics engine from Twilight Princess.

On the other hand, a game originally written for procedural synthesis would scale very, very well to higher-end systems if you set it up to generate greater detail if it detected more available resources.

Fun fact: The PS2 was designed with procedural synthesis in mind: a low-memory highly parallel architecture with very good system bandwidth. The tragically doomed Exo was to make heavy use of the technology for its textures. The downside was of course that the PS2 wasn't all that efficient at "normal" rendering. The PS3 continues the theme, so we'll see how that turns out.

With the gaming industry slowly moving toward digital distribution, procedural synthesis could help make the transition smoother, it will probably take an industry leading developer like Epic, Valve or Id Software to develop a game engine that uses this technology that delivers a solid framerate and a small footprint.

Doesn't the Unreal Engine 3 use procedural texturing to some extent?

My understanding has been that .kkreiger uses procedural synthesis to generate art assets at run time, but NOT dynamically during gameplay. The generation of assets is what is occuring during the long load sequence. That information is unpacked into RAM.

The slowness of the game engine is an entirely different issue related to the fact that the engine wasn't fully developed.

This is what sets aside .kkreiger from what we REALLY want to talk about, which is procedural generation of textures and assets in real time for inclusion in a game. This is, in part, what Oblivion does, it is what Neon does (textures are being fed back into themselves, it's very neat), and it's what you're going to have to do to generate a believable wide open world on the current next generation consoles, because the man-hours needed to generate that content would be terribly prohibitive, and the storage space available, both on discs and in system and graphics memory (combined on the 360, segregated on the PS3) is limited.

Ok, this is just a message confirming what I just said about .kkreiger generating content at run time and not during gameplay. Reference .theprodukkt's website here:

http://produkkt.abraxas-medien.de/faq

"You need that fast graphics cards to calculate the textures, right?

no. all the textures and models are calculated entirely doing the loading phase and by the CPU. in case you wonder why, different graphics cards render things very similar, but not quite the same. even a small level of unpredictable inaccuracy is unacceptable - some of our textures and models are made in hundreds of steps, and very small errors in each of those steps can (and will) cause an entirely different result. The reason we need fast graphics cards is because we use rather expensive (but also visually exciting) techniques like per-pixel lighting and realtime shadows in rendering."

The 360 was well designed to include procedural synthesis.Any machine can do it but as far as I know,it's the only machine that is custom made to do it efficiently at this time.

I hope that developers will use it for downloadable games even if they just tap it for generating textures.Takes less time to download and less storage space on the HD.If Procedural Synthesis should ever take off then downloadable full price games could be a dream come true.

Question,

If the programming is done on the fly, are the algorithims going to produce the same "effect" on all same type systems like the 360. I read the article and they mentioned that no 2 games of Oblivion would look exactly the same using the Speedtree PS.

So how will this come into play in multiplayer games? Will the different systems create different visuals or even different "cover" formations. Can this be corrected by an overriding contol program, or does the linking of two or more systems create an integrated world environment.

Guess we won't be needing those vaporish, dual layer 50GB Beta-ray discs that Sony claims can be produced.

Impressive.
Now if only they'd used a more efficient programming language like x86 assembly instead of C++, they could probably drop the size several more kilobytes and speed up the game in the process.

Oh, right, gotcha. I misunderstood the intent of the analogy.

epobirs: Its not that its hard to make a completely new game with graphical updates thats reminiscent (or in most cases, Identical) to an older game. PS will remove the "w00t, graphics" component that plagues so many games today. I dont want a billion reiterations of the same damn sports game, or a rehash of the same fsp with newer graphics... I want new gameplay mechanics, new game ideas, more engaging storylines. PS will force EA to rethink their rehash repackage method of releasing games. After all, if a brilliant game that was developed years ago still looked up to par with todays graphics, There would be little point to try to imitate it.

Thats what PS could do, Force us to be creative, not focus on pushing 10 quintillion pixels on the screen at once...