This is a condensed version of the talk i gave at GDC 2010:
You cant teach anyone to be an artist. You can tell them what you know, you can guide and advice them, but to be an artist you need to follow your own direction and find your own way. Procedural generation is as much an art as science, and as such I cant tell you how to do it, but what I can tell you is what I know.
The earliest games to have procedural generation used it to create massive amounts of content on machines that neither had the memory or storage to keep them. Rescue of fractalus, Populous and Elite where early procedural games that managed to do huge games on very limited hardware.
The problem is that the generation of content needs to be deterministic. This means that you must be able to determine the state of a particular peace of data with nothing but the position of that data. (you simply don't have the memory or anything else so it cant depend on whatever is around it) This means that it is ridiculously hard to make any interesting content and since the content is generated while the game is being played it needs to be perfect since no game designer can go in and fix it. More then anything the main benefit to this approach is that you need very little storage and ram, but these problems have largely been overcome by modern hardware.
So whats the point of Procedural generation? The main problem of game development today is not lack or ram or storage, it is the cost of filling it with content. By moving the procedural content creation in to our tools we can solve that problem. The tools will output data during development that we can use in any normal engine that that is data driven and the designers can properly test and tweak any content that is generated before shipping it.
Most developers only develop tools when they hit a wall and simply cant do something without creating a tool. I on the other hand do a massive game alone so I walk straight in to a wall just for waking up in the morning. This has lead me to create some tools that save massive amounts of time. Developers should stop thinking of in-house tools as a necessary evil and start seeing the opportunities that come with making your own tools. Rather then just looking at what you cant get done, why not try to make tools that help you do the things you spend the most resources on even if they are simple?
Here is an example: Fable II had 300 developers, Photoshop on the other hand has about 15-25 developers. If a team making a game as big as Fable II would use less then 10% of its workforce to make a new Photoshop, that paint application would only need to improve the productivity by 10% to essentially become free. Given that the design of Photoshop is 25 years old, and was never intended for game development, it shouldn't be hard to do substantially more then that. Not only would it be a good investment for the development of a game, the tool could also be sold and/or used on other projects. All of a sudden all projects gets 10% better productivity.
A great example of this is the automatic UV Unwrapper i showed last year. It makes the tedious work UV mapping fully automatic. It took about two weeks to develop and could easily sate 20% of the art budget. So if your allotted budget for you art department is more then 10 man weeks, its a very good investment. All tool development may not yield that kind of return, but given how stagnant the commercial tools have become there are some very easy gains to be made.
For this years GDC I have spent a week (Sorry Love Players...) developing a prototype texturing tools that lets you take any 3D model and add procedural filters to it. It uses shades to composit the different layers making it be able to operate on 4k textures in real time. Lets have a look:
Lets start with a un textured model:
We start by applying a noise texture and we remap the color of the noise to resemble rust.
Then we a apply a layer of chipped paint. The paint algorithm finds edges where the paint will be more likely to have worn off.
Finally we add a layer of dirt. Note how the dirt predominantly gathers in cavities.
If we want we can with a few simple clicks change any parameter, to for instance change the color of the dirt.
The tool currently doesn't do multilayerd textures like bumpmaps, specular maps and so on and it is missing lots of functionality that I would like to add like polygon selection, decals and particle splatter, still I think it proves a point. The uv-mapping and texturing above can be done in about 2 minutes and with full artist control. Done by hand it would most likely take hours.
One technique I use for semi procedural content generation is something i call "Deploy" or "Polygon replacement". The basic idea is to create a small prefabs of geometry who's outline has a simple, well defined shape, like a quad, a triangle or a corner. Then you can build or generate a very simple mesh describing a level, and then "replace" the polygons in this simple mesh with the prefabs. This for instance can be done to place trees on the ground, or be done recursively. (a house on the ground, windows on the house, cracks in the windows...) The nice thing about this is that you can art direct each small peace of geometry with out the need to build the massive geometry of the world.
However, the true potential of procedural content does not lie in productivity, it lies in game play.
Ask yourself what is best: a hand animated death animation or a rag doll? A hand animated animation may look better, but the thing is that a rag-doll animation can react to your actions. You cant have a animator sitting next to you to pauses the game for a few hours every time you shoot someone so that they can animate the perfect death animation for each situation. A rag-doll is a procedural death animation, and if you want everything else in the game to be able to react to your actions, you better make them procedural too.
To do this you need to put the procedural tech back in the engine. Wait, you say, dint I just write that having the procedural generator in the engine was a big mess? Yes, its hard as hell because there is no margin for error (I know I have done it) but if you can make it work, its worth it. In a game like love the procedural content can adapt to the way players play. Its not about space, it is about time.
Lets say you are designing an adventure game. In order for the player to reach the end they must overcome a bunch of obstacles or barriers. Each of these barriers have a key that lets you pass. The "key" may be a boss you must kill to progress, a task you must preform or a item you must obtain like say a key. If a player finds a key they know that they will need to find the door in order to progress. Each key must reside on the right side of the barrier otherwise the game becomes unsolvable (you don't want to store the key that opens the door to the castle inside the castle).
Its not very hard to make a algorithm that can create a game like this, but if we imagine that the environment is large and constantly changing, then it becomes almost impossible to constantly make sure that the game is solvable.
If you find a key on the street in real life, you know that it represents an opportunity, but you may still not even pick it up, Why? Because you know that the chance of finding its door is slim, that if you find the door you still may not want to burglarize some ones home. Most of all you know that your life will continue just fine with out the key, or finding the door. You know that life is full of opportunities and that this isn't your only one. Similarly if you loose your key, you know that every thing in your apartment is not forever unreachable without this key. It may be a hassle, but you know you will find a way back in to your apartment because you can improvise.
This is the key to procedural game design; let the player improvise. Instead of having one key to the castle, have five, then it doesn't matter if a few of them are in the castle. Statistics will tell you that it will work even if you cant actually test it. It doesn't even matter if the players can figure out that you can just climb a tree and jump over the castle walls and skip the need for a key altogether. What would be a broken game under normal circumstances becomes a better one. What does it matter if the player can skip your puzzle if you didn't spend anytime making it? The goal is not to have the player see what you have created, but to feel like THEY cam up with their own solution. That creates a true emergent gameplay experience.
So how do you create an engine that can do this? At last years GDC I was at a session where about the destructible environments in Red Faction Gurilla, and at the end of it they stated that despite the difficulties they had proven that it was possible to make a game with destructible environments with current hardware. My mind immediately went to Super Mario Bros. Is 25 years old and has a completely destructible environment. The reason of course is that its a simple block based game and its easy to remove any block in order to destroy them. Today we use polygon soups, a much less organized primitive, to draw our environments, making the modification of the environment very hard. So in order to build a dynamic procedural game I would say its less about he actual algorithms that creates the content and more about the kind of primitive you chose to build your content out of.
There are many primitives that are far more structured to consider like height maps, voxels, blocks, or implicit surfaces. Love uses a home cooked block based height map that is reasonably simple while at the same time provide lots of flexibility. You may not want to build a game build completely out of blocks, and this is where the polygon replacement comes in. Polygon replacement lets you "dress up" the simple generated representation with hand modeled geometry. When you place a token or any other object in LOVE you are basically telling the engine to replace the ground surface with hand modeled geometry.
Given that you today can store the entire data set in memory you don't need to make your content creation algorithm deterministic. The obvious way would be to write an algorithm that plans out the game, but what i rather suggest is a "opportunistic" algorithm. You basically start with a simple deterministic base data set like a landscape (that may be generated using something like a Perlin noise), and then you write a number of "passes" that you run over the data that will try to detect good places to add features like bridges, buildings, roads and even puzzles. Since the algorithms will brute force check for any opportunity, they will often discover opportunities that a human designer would not. When writing these algorithms you usually end up with very restrictive algorithms that need very specific circumstances to come in to play, in order not to flood the world with a particular feature. This brute force detection system often makes procedural data feel very rich and natural compared with had made data where the designer only focus on the path they want you to take. A opportunistic programming model creates a great foundation for creating very complex environments and lets you add more and more passes easily without influencing other algorithms. For instance in Love i create houses but first creating a pass that creates lumps, then a second pass that makes the lumps hollow, the a third that ties to find the best place to put a door, and then finally a forth pass to add windows. If i want to create a different type hows i can just make a new lump pass and then re-use the other three passes to make it in to a house. I even managed to build houses out of mountains by applying the three later passes.
I believe that some day procedural content can revolutionize gaming and make all other games feel old. I may be ahead towards that but that doesn't mean that I will be the one who eventually makes it happen. Procedural content generation is an art, so go out there and be your own artist. Take what i have learned, and use it, but also go in your own direction, because life is like a procedural game, there are always more opportunities for experimentation.