Feeds:
Posts
Comments

Archive for October 9th, 2009

Shamus over at Twenty Sided has a great series of articles up on FUEL, specifically the game design aspect of procedural content, and how it fosters exploration in the FUEL world.

FUEL:  Introduction

FUEL:  Defining Procedural

FUEL:  Roads

FUEL:  Terrain

FUEL:  Final Thoughts

It’s well worth reading through all of them if you have any interest at all in how games are made.

Procedural content is a fantastic tool for devs.  It multiplies art assets and labor, and makes higher level art direction easier in some ways.  WoW made extensive use of procedural terrain generation, and I suspect pretty much any MMO has used at least a simple fractal generator or three, at least as a starting point for the huge swaths of land they tend to boast.  Crafting all of that by hand just isn’t feasible.  Hand-polishing places here and there, and lovingly crafting certain high traffic locations is smart, to be sure, but you can do a LOT with clever procedural algorithms.

This is one good example of fractals that show up when you know what to look for (thanks to Postcards From Azeroth):

The Mirror Of Dawn

The edge on that lake is very fractal.  Compare it to the Mandelbrot set fractal over here.  You’ll find this sort of thing all over the place when you look at large scale geography in games.  Fractals tend to look natural enough to fool the eye, at least as long as you don’t look too deeply.  There are entire programs built around this.  Bryce is perhaps the most common one, but Terragen looks to be one of the more powerful ones.  (I keep meaning to experiment with it… when I have all that free time, right?)

Whether you use one of those programs or an in-house terrain generator, the principle is the same, though.  Let the computer do the mindless, repetitive vertex shuffling according to some simple rules that can generate complex output.  (Pretty much what fractals are all about.)  Computers love to do that sort of repetitive, mindless number crunching, while computer artists and engineers tend to see it as a waste of time.  (Not to mention mindless and morale-killing.)

It’s a bit like brushes in Photoshop, or filters.  They exist as visual “macros”, quick and easy ways to perform repetitive tasks, hopefully freeing up expensive artist time to work on art direction and specific set pieces.  That’s a significant part of why Photoshop and Painter even exist.  I could reproduce the Mona Lisa pixel by pixel in MSPaint, but why in the world would I want to beat myself up that way?  Computers waste a lot of our time already, why not let them shoulder the load when they are good at it?

I worked with Renderman for a while in college.  In one class, I wrote shaders from the ground up, effectively creating textures for 3D objects completely in code.  There are some shots of my work over here:

Renderman (There are also some cool eye shaders over there that I had a blast putting together.  The mesh for the eye was just a simple NURBS sphere; all of the subtleties of the cornea and coloring came entirely from code.)

OK, it was done in Renderman code, which is more like scripting than coding.  Still, there was no painting involved, no 2D graphics program, just code and a 3D mesh from Maya.

Procedural Gourd Texture

Procedural Gourd Texture

Everything that made this gourd’s coloring was typed up in a text editor.  The assignment was to take a real gourd and replicate it with a simple Maya 3D mesh and the Renderman code.  The color, texture, lighting, surface lighting properties and even slight bump mapping (I don’t think I used displacement mapping on that one) on that gourd are entirely text-based.  If I, a paltry college student, could do that, imagine what the Pixar guys get away with.

You can do a lot with code.

That might sound a little odd, coming from me, an artist.  I’m one of those newfangled artists, though, who sees great value in this sort of thing.  I loved the “tree painting” tool I used for EA.  It let me “paint” where trees should grow, how dense and how tall, on a Maya surface, and it would bring in preconstructed trees and scale them appropriately.  I effectively painted forests onto the world.  It really could have gone a step further and had the trees themselves be procedurally generated.  Trees are perfect for that sort of thing.

Roads are another natural fit, considering they tend to either fit a grid or flow with the terrain (itself procedurally generated).  Sure, you need more constraints in how they actually behave so that they make sense, but it’s precisely that sort of process that game programming deals with all the time.  It’s all in finding the simplest rules possible that will, when given a starting point and a bit of randomness, can produce something that looks natural.

In a way, it’s telling the computer how to process rules like we teach art students.  If you can give the computer the code equivalent of the rules and principles of art, like balance, rhythm, line, proportion, variation, motion, color theory and so on, it can generate a lot of art in short order.  (All that artists do is apply the same rules to whatever ideas rattle around in our head.)  It may not have the spark of creativity that makes the finest hand-crafted pieces as great as they are, or the rationalization that allows us to think a Pollock painting is high art, but computers, sufficiently educated, can do a lot.

Though, it should be noted that educating them takes time and effort, as well as an artistic eye.  Computers are also notoriously stupid (or exceptionally smart) in that they are rigidly bound to internal logic and thinking “inside the box”.  They are fantastic tools, but must be used the proper way to be of any use.  You can’t just put Deep Blue in a room and tell it to whip up the perfect video game.  You can, however, use them to shoulder a lot of the inane repetition in the development process.

Shamus describes it in depth over at his place, so again, I heartily recommend his articles.  I’m mostly just chiming in as an artist, noting that I love it when the computer can help make my job faster and easier.  I suppose that at some point, it could be argued that a sufficiently advanced computer could do the job on its own, but I’m confident we’re at least a few years from that situation.  And, well… once that day comes, I’ll be telling the computer how to do the job I once did, so things will work out.

Read Full Post »