[Note: this was written prior to Phil Carlisle's article, so I apologize if there is any duplicate perspective in here. For that matter, check out his article here, he has a lot of interesting insight as well: /2011/03/20/the-future-is-procedural/]
On the 7th day, [insert preferred deity here] became lazy and said, “Nature, design thyself.”
There is an undeniable link between math and nature. I could start boring you with talk of the Mandlebrot set, Voronoi diagrams, Delaunay triangulations, the Golden Ratio, and so forth, but here is a cool video that does the job better than my words could:
[youtube]http://www.youtube.com/watch?v=kkGeOWYOFoA[/youtube]
Whether it is nature that defines math or math that defines nature, we will leave those questions to the burger flippers…oh, I mean philosophy majors. ;) For now, all we need to know is that this link, as programmers and artists, benefits us dramatically. It means that we can more easily abstract the laws of nature into code, and thus more easily simulate and create nature in a virtual environment.
But procedural generation applies to much more than just nature, it is also perfectly capable of generating non-organic, “man-made” structures. In fact, it might surprise some people that man-made structures exhibit many organic properties, and are often intentionally designed to mimic nature. The columns in Ancient Egypt, modeled after papyrus and palm plants, are one simple example of this. A city map, in some rural areas, often looks similar to the vein layouts on certain plant leafs. Even in areas not directly tied to nature, structures exhibit mathematical symmetries and designs that can easily be expressed by simple logic.
So, those of you who do not already know might be asking, “What is procedural generation?” It is, as the name implies, the process of generating things procedurally (or, via code). The opposite approach would be manual generation, or “doing it by hand.” As far as it is related to game design, these things are better known as “assets” or “content.” These assets can literally consist of anything – textures, meshes, animations, scripts, behaviors, parameters, you name it. In terms of the types of content that can be produced, the sky is the theoretical limit: humanoids, buildings, cities, terrain, plants (flora), animals/creatures (fauna), clothing, vehicles, and so forth. In some cases, game designers will expose some of the procedural generation abilities of their engine to the end-users, either in-game or in an external editor. This leads to user-generated content (henceforth: UGC). In some cases, the mechanisms used to achieve this can be very complex (as with some map-editors), or they can be very simple (masked as elements of gameplay, as in Spore).
So, in less words, procedural generation (henceforth: PG) takes much of the work that your artists and level designers would have to do by hand, and automates it. Sounds awesome right? Well, it can be, if it is done right. But many people in the industry frown upon PG (and UGC, for that matter). Sometimes, it is with good reason, and sometimes, it is just because they don’t really understand what PG and UGC are capable of and how they can easily be abused. I would like to clear up a few of those points (I will call them “myths,” but feel free to disagree). Mind you, all of the “myths” below have been said to me before, often multiple times.
Myth: PG/UGC leads to watered-down, random, sand-boxy gameplay
Many people will claim that PG is a lazy replacement for real, intentional, hand-crafted game design. And it often is. In The Elder Scrolls II: Daggerfall, all of the towns, people, dungeons, quests, and so forth, were procedurally (or randomly) generated. On one hand, this led to a huge game world, far beyond the size of anything that had been made before it. On the other hand, the towns, people, dungeons, and so forth all had (in my opinion) incredibly boring design, because they all lacked the hand-crafted touch that could have made each character and location unique and interesting. In some cases, PG gets the job done adequately, like in Rogue-esque games such as Diablo, which are basically all about grinding.
But these are not the best examples, because they were around before the term “procedural generation” was being used a lot. To date, the reigning champion of PG (and UGC) examples is Spore…unfortunately. [Side note: I was contacted by someone at EA many years ago that asked if I wanted to work on Spore, after they saw some of my work with PG - I did not take the job though.] Don’t get me wrong, it is an interesting game in its own right, but it failed to properly represent the capabilities of PG/UGC on many levels, and caused many people to get the wrong ideas about PG/UGC. Before I insult anyone that worked on it, let me say that they did a remarkable job given their constraints. The problem with Spore is that it is not so much of a game as a sandbox. And even as a sandbox, it wears thin pretty quickly. Its main problem is that it does not really use PG or UGC to its advantage – the assets you generate do not impact gameplay very dramatically or meaningfully. Some aspects of it were done very well, but at times it felt a little bit too much like Mr. Potato Head, where the procedural generation was simply pasting together prefabricated assets.
UGC is an issue on its own. It can be difficult to monitor UGC, and in some cases it can detract from the suspension of disbelief (especially when juvenile humor is involved). A strong brand and design can also be easily destroyed by UGC. That said, UGC can be given constraints that make it an effective tool for growing your game’s content while not destroying its image. The best way to do this (in my opinion) is make the design process for UGC directly affect gameplay. So, for example, if users are building a castle in an RTS game, it will survive if it is properly designed to defend its people, and it will be destroyed if it is a pile of garbage. People can also police/moderate themselves, which is also sometimes an effective mechanism.
As for PG, I would argue that it is almost always a good thing, if it is done right. PG should be used to help the designers and artists, and get rid of monotonous work. If it can’t be properly automated, then it should not be.
Myth: Procedural Generation == Random Generation
Random Generation is a subset of Procedural Generation, just as squares are a subset of rectangles. Procedural Generation does not have to be, in any way, random. Explicitly provided parameters can be used to adjust every aspect of procedural content (for example, the radius of a tree trunk or the number of buildings in a city). Random generation can often work against designers, and they will find themselves regenerating assets constantly to get them to “look right.” Even “random” assets can be given a consistent look by using a fixed number for the seed in the random function (versus, say, basing the seed on the system timer).
Myth: Procedural Generation cannot produce assets of type X
Anything that you can logically describe can be procedurally generated. Some things are much harder than others. One of the hardest things, in my opinion, is procedural animation of creatures and humanoids. It has been done successfully, to varying degrees, depending on how you define success. But I still do not think anyone has yet created creatures that use true AI (without any preset behaviors or motions) to navigate through complex environments using all of their limbs (for example, jumping and grabbing onto ledges, and so forth). I’m working on that one, I’ll get back to you on it….;)
Myth: Procedural Generation cannot produce stylized characters or assets
Wrong. Spore is very stylized, although, as I mentioned before, it is, at times, a bit too cut-and-paste of pre-fab assets. As stated before, procedural generation can produce anything that can be logically described, which is…anything. As humans, we like to think that we have some kind of special “creativity” gene that computers can never replicate, but our notion of “creativity” is clouded and vague. Creativity is actually very simple – it is simply the process of absorbing all that we have learned to produce something “new” (not necessarily unique) that has intentional meaning. To clarify, even if a computer randomly threw blobs on the screen, and it happened to look like a butterfly, that is not creativity, it is coincidence. Computers can, and have, already produced creative works of art, without explicitly being told how to do so. That said, at this point in time it is not really the job of PG to be “creative” – PG is only supposed to help artists and designers express their creativity faster and more efficiently. Artists should be able to tweak almost every attribute of a PG object to style it according to their vision.
Myth: Procedural Generation is a lot of work, and often not worth the effort
It is true that procedural generation is more work than it is worth, if you are looking at one title. But if you are reusing your work, PG is the goose that lays golden eggs. Once it is built, it is built, and there is no need to reinvent the wheel, only fine tune it. When I look at many modern games, I cannot help but think what a shame it is that so many artist hours are wasted on what are essentially identical assets. Even worse, all of the work that goes into assets that never get past the cutting floor – PG can at least let artists experiment rapidly with prototypes, before they go in and fine-tune things manually.
Myth: Procedural Generation is too slow to be used in commercial games
Some consoles might be too limited to use PG with (in terms of memory), during runtime. That part is true. But you can do PG offline and benefit from it as well. However, if it is done right, PG can be a lot faster than loading dense meshes and texture maps from disk (That is, generating data in memory, even with a bit of CPU work involved, has the potential to work faster than a hard disk or DVD can load). Often times, it will be too slow to generate assets every frame (as with procedural textures), but it can be done once and then cached in many cases.
Myth: Procedural Generation will never go mainstream
I would argue that, as a force of nature, it will have to. Budgets for games are simply growing too big. People simply cannot produce content fast enough for consumers. There is not enough room for risk and innovation.
Myth: Procedural Generation will replace artists/level designers
PG will empower artists and level designers, but it will never replace them until we can build an AI that can do everything an artist or level designer can (no small task). At that point, we would probably have AI that would mostly replace programmers as well. Whether or not that is possible, feel free to debate, but I think it is – however, not for a very, very long time from now. Regardless, the goal is not to replace people, but allow them express their vision easily without worrying about the tedious details. If you define procedural generation as taking a high-level command to create/modify low-level data (a mesh, texture, etc), artists already use procedural generation every single day. A brush stroke in Photoshop takes a click and procedurally turns it into a set of pixels (or bytes) to mimic a brush stroke. A tween procedurally creates frames of animation between the parent key frames, freeing the artist of a time-consuming task. I could go on…
Conclusion
In short, I think that procedural generation has a bright future, but we still have yet to realize a fraction of its potential. Progress has been slow for two reasons, in my opinion: the misconceptions listed above, and the generally low appetite for risk within the industry. I think that PG has the potential to bring us back to the golden era of the 80s and early 90s, when “AAA” games were made by small teams. I have much more to write on this topic but I need to leave room for my next articles. Please join me next time for a more interesting and in-depth discussion on PG and UGC.