Procedural content generation

Part 3 of “Building World-class Art Tools” from Develop 08

Last time round I argued that it’s increasingly worth investing in content creation, and before that I pointed out that your first solution should always be to buy the best that money can buy (and secondly to extend an existing commercial product).  Today, however, I want to turn to look at one way in which in-house tools are worth building.  It has to do with procedural content generation, and that takes some explaining.

Bad definitions of procedural content

How do you define “procedural content”?  I don’t like a lot of the standard definitions floating around.  While most people agree on many specific examples of content that is procedural (and not), few definitions sit well with me.  The most common reasonable definition is probably something along these lines:

Procedural content is content that has been created by a computer algorithm rather than custom made by an artist.

This tries to be a binary definition – either content is procedural or not.  But look at some examples, and it doesn’t seem so clear.  If a generating algorithm takes just a random seed, that seems procedural.  What if it takes an object made by an artist (e.g. a tree) as input, and repeats it in a procedural way (e.g. to make a forest)?  What if it takes some parameters that an artist can tweak (such as the area and density of the forest)?  Is that procedural?  Most demoscene stuff is generally considered procedural, but certainly requires some artistic input during its creation.  Where do you draw the line?

A better definition

In my view,

  • All content has algorithms applied to it, throughout its lifecycle: modelling applications, overnight build processes, and the game engine itself all transform data in an algorithmic way, to produce content.
  • If you’re in the business of selling content, such as in games, you also want all your content to be made by an artist, because they’re going to bring the aesthetic touch which makes people want to buy it.

Why do we have to choose between the two?  In real life, we don’t – it’s only the bad definition which tries to distinguish between them.  Rather than thinking of procedural as being a binary thing, why not have it be a continuous scale?  Why not consider content as a collaboration between artists and algorithms, with a definition which allows you to measure “how procedural” content is, in other words, how much of the contribution is algorithmic?

To illustrate some more, let’s consider a general model of content creation consisting of a pure algorithmic software system, an artist who provides inputs to this system, and content, the result of processing those inputs:

That system, that function in the middle, includes everything from the modelling package through to the game engine: all of the algorithms involved in transforming that content.  To measure how procedural the system is, let’s measure how much work the algorithms do on the artist’s behalf.  By work, I’m talking about adding value to the content, not just transforming it into a different format.  Perhaps you could formulate a precise definition using information entropy or something, but I’m going to be rather more hand-wavy in the interests of brevity; some examples should do the trick.  At one extreme, we have the identity function, which does no work:

At the other extreme, we have some kind of super-intelligent system that does loads of work on the artist’s behalf:

Another exaggeration for sure, but you can see the point, I hope.  Suddenly, it’s not a question of whether content is procedural, but how much.  Even tools like Photoshop and 3DS Max are procedural; in fact, they have a surprisingly high score on the scale, because they contain power tools with high leverage for the content creator, implemented using sophisticated algorithms.  Watch an expert use these tools and you’ll see what I mean.  But they’re still low down the scale in the grand scheme of things.  Game character customisation systems are more procedural, requiring relatively few inputs to create very detailed characters.  Even higher up, you have Elite – an entire galaxy made from a random seed.

With this definition, the benefits of highly procedural content become obvious:

  • Data compression.  In a modern context, this may be needed to send content over a network, whereas in times gone by, it was used to fit content onto limited-storage or limited-memory hardware.  It’s still done for fun in the demoscene, to impressive effect.  To take advantage of this compression, the bulk of the algorithmic work must be done after distribution to client machines, hence ‘on-the-fly’ generation.
  • User-generated content.  General users of games don’t have the time or skill it takes to produce modern game-quality content, but if a procedural system is built to take only a few intuitive inputs, it becomes quick and easy to use by anyone.  Character customisation systems are a classic example, with Spore being the flavour of the day.  What we’ve shown of APB isn’t looking half bad either 🙂
  • Programmer-generated content.  If you’re a lone programmer making a game, or if you can’t afford enough artists to build the scale of game you’re making, why not generate content using functions that can generate unlimited content from simple inputs such as random seeds?  Many a great game used this approach in the past; Introversion have some nice modern examples.
  • Artist productivity.  For a given amount of output (content), a more procedural system will require fewer inputs, and hence less work by the artist: it will be more productive.

I don’t want to belittle the first three, but since this is a series on in-house tools, it’s that last item which should catch your eye.  Boosting artist productivity is obviously good.  But what do procedural techniques have to do specifically with in-house software?

Expressing yourself

Being high on the procedural scale comes at a price: expressiveness.  The more procedural your system, the less expressive it’s going to be.  This sort of follows logically (I admit, it’s very hand-wavy!) from my definition of procedural content: a highly procedural system will have many fewer inputs, and so have fewer outputs by definition (and conversely, a highly expressive system cannot be highly procedural, as it requires many inputs).  It also fits in with intuition – systems we know to be lower on the procedural scale (3DS Max, Photoshop etc) are fully general-purpose, capable of building more or less anything your imagination could dream up, while systems we know to be higher (character customisation systems, Elite’s galaxy generator) are highly specific, capable of building only one thing, and probably only a limited subset of those.  This is usually a big disadvantage of procedural generation.  I say usually, because for user-generated content, you may actually be glad to restrict what people can do!

Looking on the bright side, this is good news for in-house tools programmers!  Here’s the key insight for today: the best commercial tools (like Max) will always be lowish on the procedural scale, because they have to be general. These tools will only succeed commercially if they can sell to the widest possible market, which means they must be expressive, and hence lower on the procedural scale.  And this is where your in-house tools gain a significant advantage: because you can aim specifically at the content you’re trying to generate, you can be highly procedural, and hence more productive than market-leading commercial tools.

Ultimately, this is the only way I can see that serious in-house tools can be justified in business terms.  It requires you to be generating large amounts of content of a similar kind (low in variety, in the grand scheme of things) to be possible.  This is totally borne out in practice: racing game studios usually have track editors, outdoor games often have terrain editors, and so on.  At RTW, we’ve built our own tools for procedural city modelling (comes in handy when you make Crackdown followed by APB!)

Just beware the dangers of low expressiveness.  If you invest a lot in a procedural system, and your game design or art vision changes such that the desired content is not expressible in your tools, you could have a big problem 😉

What about commercial procedural tools?

There are some highly procedural commercial tools around.  Some examples that spring to mind are Houdini, ProFX, Procedural Inc, and Speedtree (probably the most obviously successful one, in terms of widespread use and high productivity).  I’m not trying to say that it’s impossible to build a commercially successful procedural system, just that it’s very difficult (this is a small list, and most of them aren’t widespread commercial successes yet).  Difficult enough, I think, that there will always be opportunities for procedural in-house tools to build specific types of content – but of course, if a good commercial version exists, buy it!

This entry was posted in Develop 08, Tools. Bookmark the permalink.