|Game Design||By Shamus||Sep 23, 2009||46 comments|
|If it were possible to jump off your vehicle, Fuel would have the makings of a fairly thrilling base jumping game.|
Some people equate “procedural” with “totally random”. It’s true that it can be random (within the limits of a computer’s ability to generate “randomness”) but it doesn’t have to be. It’s fairly trivial to make the computer generate the same sequence of random numbers, thus having a “random” area appear the same each time you visit. In any case, it’s true that there will be aspects of the world which were created without direct participation of a human being. The placement of objects will in that sense be “unpredictable”. But this unpredictability – this loss of direct control – is one aspect of the tradeoff we’re making when we aim for procedural content. The more specific you want the content, the more it needs to be built by a human being. Do you have a rigid expectation of where each and every tree should stand? No? Then let’s not waste an artist’s time by making them place the things manually.
On one end of the spectrum is the hand-made world: An artist (or a team of them) will use shaping tools to sculpt the topography of the land. Then they paint it in some meaningful way. Grass over here, dirt in this valley, exposed rock on steep surfaces, etc. Then they populate the land with trees, shrubs, rock, grass, and whatever else the game calls for. You can do something like this in an hour or so if you’ve got good tools and you’re only filling in something modest in size. On the other end of the spectrum is the purely random world: Have your world-o-matic moosh a bunch of random noise together to make generic rolling hills, and then randomly sprinkle vegetation around.
|Remember this building. We’ll be seeing a lot more of it in a later post. Also: Is anyone thirsty? Me? I could drink.|
Placing each and every tree is time consuming and needless. Instead, you observe that trees do not grow randomly in the real world, but behave according to observable rules. There are rules about where trees grow, how they’re spaced out, and how big they get in different places. Trees don’t generally grow on steep hills, and if they do they don’t get very big. Dense trees tend to choke out undergrowth. Undergrowth prefers soil to rocky terrain. Grass gets tall anywhere you don’t have tress or undergrowth. Some trees grow denser than others and have different preferences for elevation and moisture. Etc etc etc. A programmer can bang out a few rules like this and add them to the editor. Now instead of the artist saying “I want a tree here, and another here, and here, and here, and I hate my job, and here, and a couple here, and I wonder if McDonald’s is hiring, and now onto the shrubs…” The artist can just say, “Given the rules for trees, I want a forest over this region.” Boom. Forest done. Now instead of planting trees and bushes, the artist is placing forests and grasslands.
This is where people who love to haggle over definitions will jump in and say that this is no longer art. They argue that once you distill a process down to rules and numbers, you’re no longer expressing or communicating, you’re just imitating. But I see art in making the code that makes the world just as I see art in using the tools that make the world. I see the compiler as simply a very strange paintbrush. But fine. We don’t have to call this art and there’s no reason to derail ourselves by going for another trip around the “how do you define art” mulberry bush. Art or not, the goal is to create a space that feels plausible and aesthetically pleasing.
I think Fuel pulls this off.