Procedural Content
Danc recently blogged on Procedural Content, sparked by an article from Introversion on why ‘Content is Bad’. While I am a big fan of procedural techniques, I have to point out that I’ve seen them used incorrectly more times than not.
Procedural Techniques are hard to get correct – and the less human intervention required by the process, the harder they are to mold to a desired result. As such, I’ve come to look at them in a slightly different light than they are normally discussed:
Procedural technique is another name for tool
Photoshop provides us with a huge array of tools to work with. We have brushes, layers and selections. We don’t think of these as procedural content generation, but in fact, that’s exactly what they are. When we paint with a brush, we’re modifying many pixels at once using a procedure defined by the program code and a small piece of content; in this case, the data for the brush.
Through many operations, an artist can create a masterpiece that would be impossible to generate entirely using procedural techniques. This would be technically feasible to do one pixel at a time, but by providing a higher level of abstraction (brushes), we reduce the difficulty curve of reaching that level of mastery immensely.
As such, it’s important to think of your procedural technique as a way to augment your creative process, either by creating a useful and understandable abstraction in the way a brush does for an artist – or by replacing large sections of ‘busy work’ with a procedure that fills out that data.
If your artist is afraid, so should you be…
Programmers love procedural techniques – artists (or designers) generally fear them. If a procedural technique is integrated correctly into your design, an artist will not see it as a thing that replaces their work, but rather helps them achieve their goals faster. In essence, a good procedural system is viewed as a tool instead of a procedural system.
The reason for this is quite simple; a tool has an understandable need, use, result, and a process which can be directed to solve a problem. If you can’t identify all of these for your procedural system, should you be building it?
Don’t over-solve the problem
Often when I hear people talk about procedural techniques, it’s as a way to ‘generate infinite content’; as if that is going to make your game last forever. But people are incredibly adept at seeing past the algorithm and sensing the underlying possibility space, and tiring of its parameters. As such, there is no such thing as infinite content.
Procedural techniques, and tools in general, should be designed to allow their users to create the right amount of content. If a tool is hard to use, people will avoid it and you won’t have enough of that type of content. However, the converse can be just as bad. If a tool is too easy to use, you will see too much of the type of content it creates, and users will tire of its output quickly.
For instance, when we designed the landscape system for Asheron’s Call 1, we designed it to allow an artist to quickly create large areas of terrain, and populate them with monsters, scenery, and ambient sounds. As such, we ended up with a huge world filled with this data. However, our process for placing hand crafted content was not nearly as refined. So while there were huge areas of procedural content for users to explore, there was a lack of the artists touch in many areas.
Your content is usually not, actually, procedurally generated
Often people talk about the procedurally generated dungeons of Diablo as content; but in reality, they aren’t actually content from the perspective of the design. You don’t actually explore dungeons in Diablo – what you’re really exploring is the treasure system. And while the treasure system does employ some procedural techniques, the real rewards of that system were entirely hand crafted.
In fact, the true success of Diablo’s procedural systems is that they managed to acceptably scale out a small amount of custom created content over a large amount of procedural noise. Thus, the ratio of hours played to custom content created is very high.
Use procedures to augment artist input, and stretch your content further
Guitar Hero uses a procedural animation system to animate the characters playing their instruments. It was written in about 2 weeks, and requires a very small amount of unique authoring input to work. It pulls most of its animation from data that’s already there for game play reasons, mainly the note gems. A small amount of data is required by the person authoring the song, and they have various hints they can give to the system to adjust the results.
We’ve improved that system over the last few years, and the data mining is becoming quite complex, as are the modifications to the animations and other data it’s outputting. But for the most part, we’ve avoided authoring extra data, because the carefully crafted note charts and meta-data are a goldmine for information about what the music is doing.
Reach your quality bar first
Before building a procedural technique, it’s important to understand all the nuances of what you’re trying to do. As such, it’s best to create a quality result before trying to break that down into some type of procedural system. Looking at the data, be it animation or content, will help you spot the patterns which can be replicated and varied, or the busy work involved which can be automated or abstracted. Attempt to solve the problem as a tools issue until it has been proven to be one that has to be solved in a generative way.
