FUEL is a racing game from team Asobo, published by Codemasters. (Codemasters also released racing titles DIRT and GRID. They’re an okay publisher, but someone need to tell them to lay off the CAPS LOCK.) The hook with FUEL is that the gameworld is procedurally generated. I’ve done some procedural design myself (example) and I’m really excited to see procedural techniques making their way into mainstream games. Up until recently, only indies and experimental projects like .kkrieger used procedural content. Spore is the other major title to give procedural content a go, but a lot of people looked at that stuff and couldn’t picture how it could be used to make anything besides more Spore. I think FUEL solidifies the idea that procedural content can be used in existing genres of games, and that it will become more important as game content becomes increasingly expensive to produce.
The world of FUEL is massive. This is the first game I’ve ever played where you could sit down an have an honest-to-goodness “Sunday drive”. You can jump in a car, start driving, explore back-roads, highways, and interstates, and not have to worry about bumping into artificial walls or going in circles. The game is so big that nobody, not even the creators, is going to be able to see the whole thing.
“Procedurally generated” simply means that the gameworld is built on the fly as you drive around. Note that some people conflate the idea of “procedural” with “random,” and while it’s true that you can make random areas using procedural techniques, it doesn’t have to be. (The world of Diablo was procedurally generated by linking together pre-determined sections to form the overall map.) The content generation in FUEL is entirely deterministic. Any given area is the same each time you visit, but the land was not built by an artist sculpting every individual hill and valley. The geometry of Blacktrial Pass and The White Flats doesn’t exist until you go there. Nobody sat down and placed all of the millions of trees. Nobody said “let’s put a road right here.” It’s all (or mostly) made according to algorithms and preset rules. There are a smattering of hand-made courses and buildings added to the world to serve as set pieces and landmarks, and the rest comes from the Asobo gameworld-o-matic. It gives you the benefit of having handmade courses, but without needing to stick the course inside of a playpen to keep the user in.
But what if the game wasn’t procedurally generated? Let’s imagine someone tried to make the game the old-fashioned way. What would it look like?
The box claims that the world is ~14,000km2. This means the world is a square region 118.32km on a side. I’m betting that’s the playable area, and that the actual world is 128km on a side. (Just because 128 is a power of 2, a very natural number for programmers to end up using.) The extra 10km is no doubt the buffer zone around the edge, so that you aren’t looking into the void when you hit the boundary of the world. (Yes, there is a boundary. It’s just that in this game you probably won’t bump into it unless you’re trying to.)
Once in a while you can see a little “spike” in the terrain geometry – a single point anomalously raised above its neighbors. These are rare, hard to spot, and usually covered by foliage, but in my hours with the game I’ve managed to spot a couple. They look like a tiny little pyramid of dirt, and are the result of some trivial bug somewhere in the terrain generation. It wouldn’t be worth mentioning, but these little spikes give us a clue as to how detailed the terrain is. Comparing the size of these triangles to the size of the player’s vehicle seems to suggest that the terrain is built at one-meter resolution. (Team Asobo is based in France, so it’s a safe guess they’re using meters and not anything screwy like “yards” or “cubits” or somesuch.) An elevation point every meter means the gameworld has 128,000 elevation points to a side, which means the whole world is a grid with (drumroll) 16,384,000,000 total points. 16 billion and change.
You’d need four bytes of height data for every point in order to produce nice rolling hills. You’d need at least another couple of bytes for surface information like texture mapping / foliage / surface behavior etc. This will hold data defining the surface, letting the game know that this little patch of land is made up of grass, mud, clay, or one of a dozen different colors of rock and dirt. Then there will be a few bytes for controlling the placement of shrubs and trees. This is a really conservative estimate, and in practice you can easily end up with a lot more than that. But assuming just twelve measly bytes per point – each single one meter square of the terrain taking less data than the sentence you’re reading right now – the final size of the gameworld comes to 196,608,000,000 bytes of data, or about 196 gigabytes. You would need a stack of around forty DVD disks just to hold the terrain.
And then you need the roads, which will consume at least a couple more gigabytes. Plus the buildings, road signs, vehicles, bridges, and other infrastructure. Plus the game itself. We’re looking at a stack of 45 DVDs for a game this size. Perhaps the “Gold” edition of the game would ship in its own collectible wheelbarrow.
Obviously, this game wouldn’t even be possible without procedural content. Forget about building that much content by hand, which would take an army of artists. Indexing and accessing that much data and serving it up on demand at the speeds required by a racing game wouldn’t be a picnic either.
Procedural content takes time to make. No, actually the technology takes time to make. Once you have a world-generating tool, content is free. Feed it some scraps of data and tell it how much world you want. The idea here is that it won’t magically make games cheaper to produce, but there is hope that it can give us a lot more gameworld for the same money.
On one end of the spectrum is the Valve Software approach to games. Everything is meticulously hand-crafted and polished to a mirror shine. It makes for some nice gaming, but it takes forever, costs a fortune, and doesn’t offer a lot of gameplay. When Episode 3 finally comes out, we’ll have waited three or four years for what? Six hours of gameplay? Maybe ten. I’ll be glad to have it, but it would be nice if we could get more game in less time. On the opposite end of the spectrum is Spore, which offers limitless variety but it all sort of feels the same. (Disclosure: I haven’t played Spore for various reasons. I’m going by the reviews I’ve read here and elsewhere.)
So up until now the choice has been: A) Lots of bland content for nearly free, or B) A bit of dynamite content for excruciating development costs. The FUEL formula suggests a nice compromise between the two, with a bit of hand-crafted work to give the game character, and the rest filled in with broad strokes from a procedural engine of some sort. Applying this to a shooter, you might have key locations in the game (boss fights and plot points) take place in carefully crafted areas, but turn over the generic tunnels, boiler rooms, sewer levels, and outdoor areas to procedural code. Those are places that players usually breeze through without a second glance, and it doesn’t make sense to pay a room full of level designers to labor over those if their talents could be spent on the areas we actually care about. The handmade stuff is the steak, and the procedural stuff is the free bread the waiter will bring you to make sure everyone leaves feeling full.
I’m really excited to see time being spent on technology other than graphics. Graphics have looked fantastic for the last few years, and constant increases in hardware and development costs hasn’t seemed worth it in the face of such modest visual nudges. Yet we’ve hardly scratched the surface of what could be done with procedural tech.
Shamus Young is the guy behind this movie, this website, these two webcomics, and this program. His dream is to see the FUEL tech used in something like Fallout, so he can have the full 118km2 post apocalyptic “Mad Max” experience.
