> games should do procedural terrains

The decision between prerendered and procedurally generated terrain/textures/etc. is a tradeoff between.. oh, I dunno, developer time, artist time, platform disk space, download time, platform CPU usage, platform graphics usage, and other factors. If you believe game studios have been consistently going for the less optimal choice, then you or someone else could start a studio that makes the better choice, exploit that inefficiency, and gain a market advantage. (Perhaps the demographic of gamers with modern CPUs but 1990s hard drives is ripe for tapping?).

If on the other hand there is no such market potential, then it isn't clear to me in what practical sense the assertion that games 'should' be procedurally generated holds.

So, now you need your artists to be programmers.

I don't think you quite understand what you're asking. The number one rule for high-quality aesthetics in games is that you let the ARTISTS call the shots, with someone in-between to tell them when that's a terrible idea technically. This would break that horribly.

And that's ignoring the load times, which increases massively if you have to procedurally generate it. And having decent level design, which I GUARANTEE will not often pop up naturally in procedurally-generated environments. Meanwhile, disk space is pretty damn cheap and will save you a bunch of time and money.

> So, now you need your artists to be programmers.

There is some arguments if you should allow artists to program (Blender does have a built in scripting language).

However, the same group that created the FPS demo also created a tool to create demos - artists can go as wild as they want without needing to write a line of code: http://www.farbrausch.com/prod.py?which=168

If you want something a little more well documented and updated you should check out ZGameEditor - http://www.zgameeditor.org/.

> And that's ignoring the load times, which increases massively if you have to procedurally generate it.

Any reason why you can't render and save the textures on first run? I feel like Natural Selection 2 does that.

> Meanwhile, disk space is pretty damn cheap and will save you a bunch of time and money.

You are forgetting the step in between. Using your argument that disk space is cheap (and assuming they don't use their hard drive to store anything else...) - in the US ISPs are playing a dangerous game. A small DSL provider has a 5GB cap and will charge outrageous fees for going over: http://stopthecap.com/2010/04/14/frontiers-5gb-cap-is-back-n...

Downloading that 20GB RAGE game has turned into quite a challenge (of course you could always use the Valve response of "take your computer to a friends house").

Here's the thing: Procedural rendering is a tool. It's useful in some cases (like, say, randomly generating massive universes with distinctive patterns a la elite, minecraft, etc). It's useless if you want to do predictable things which obey a designer's vision. Going from concept art/blueprint to a live mesh is completely impossible with the tooling we have today to do procedurally.

Yes, most games could certainly optimize their contents. I'm certain there's dozens of gigabytes of data which could be shaved off on any gamer's computer between all the installed games, but most of what's in there is there for a reason. Also ... something about frying fish.

So treat that technique as a tool. Not everything is a nail. Is RAGE too large? Maybe. Would procedural generation be appropriate for it (in a way that meaningfully reduces contents size)? Certainly not... not without redesigning the game from the ground up.

>Downloading that 20GB RAGE game has turned into quite a challenge Dated First World problems notwithstanding I immensely enjoy the harping on RAGE, especially the fixation on the assets (and the resulting download size). GTAV is nearly 60GB and is immensely popular. It uses a traditional texture model compared to the Megatexture technique used in idtech. Computing the quantity of textures on install would result in people remarking how long it takes to install instead of download.

> You are forgetting the step in between. Using your argument that disk space is cheap (and assuming they don't use their hard drive to store anything else...) in the US ISPs are playing a dangerous game. A small DSL provider has a 5GB cap and will charge outrageous fees for going over Canadians have been dealing with dinky quotas for awhile and entertainment streamed or downloaded thrives there. In the states there are plenty of people on dial up who live out in the sticks or are on satellite connections and you know what? I'd wager these people aren't the target market. For the vast majority of businesses the most expensive thing is employee overhead. Storage is cheap and getting cheaper, developer time not so much. I appreciate technical efficiency as much as anyone. The reality is that the junk pile is full of technically superior products that died because the competition beat them to market or out marketed them.

>However, the same group that created the FPS demo also created a tool to create demos - artists can go as wild as they want without needing to write a line of code: http://www.farbrausch.com/prod.py?which=168 If you want something a little more well documented and updated you should check out ZGameEditor - http://www.zgameeditor.org/. Neat. I'd sincerely enjoy seeing an attempt at making a game like RAGE with zgameeditor. I see excellent examples of toy tools. Using the right tool for the right job makes a world of difference, take a look at Unreal4, ZBrush, Maya, and a host of others involved in asset pipelines. You'll notice many of these tools are specialized. Pay close attention to the features and compare those to zgameditor.