T w e n t y S i d e d

This shows the zooming in, just to give you a sense of scale of the world.

I mentioned earlier that I wrote a road-generating program. I want to talk about that project a bit and then compare it to what we see in Fuel.

Roads are interesting because of how organic they look. They bend and twist and split and have overpasses / underpasses, change width and (from a distance) tend to resemble more a circulatory system than a circuit board.

Roads have rules which most of us intuit even when we don’t think about it, and when a virtual road breaks those rules it tends to break immersion as well. Proper public roads generally don’t bank (or only do so very slightly) but are graded such that they are higher in the middle, so rainwater will run off. Roads tend to change direction more readily than elevation. When circumnavigating a hill, the road generally cuts into a hill a bit, (as opposed to jutting out) so you’ll have a steep bank upwards on the inside and a drop downwards on the outside. If that drop is steep enough or the road curves abruptly enough, there’s usually a guard rail. Roads bend all over the place, and it’s not uncommon for you to find yourself on a “northbound” highway heading due east or west. And there is a limit on how steep a road can get.

And these are just the rules for a single road, which is what my program dealt with. (It was eventually going to be a screensaver. If I were to do it again I’d no doubt put the thing on Google code for safekeeping.) The program would load in or generate some hills of dubious realism. (This was before I did my terrain project, so the terrain system here would have been crap.) Then it would plot a road to go from the south edge to the north edge. It would examine the angle between its current location and its desired endpoint, and would try to head in that general direction while staying as level as possible. It ran on a flexible scale: The bigger the deviation between it’s current heading and its desired heading, the more willing it was to go up or down hill. This worked amazingly well at producing a road that wasn’t too hilly but didn’t get lost. It had a “create a bridge” fail-safe for when it just couldn’t find a proper solution, which happened whenever it was cut off by a steep valley. The “bridge” was just a section where the road would run straight and level until it ran into the opposite wall of the valley. All told, it wasn’t a flawless system but it produced some amazingly plausible roads on some challenging topography.

Check out this heightmap I swiped from Google Image Search:

On the left is a straightforward heightmap. It’s like a satellite view, with brighter pixels representing higher elevations. The right is the same thing, but with a particular elevation set to red. If you were standing on that red area, you could obviously go pretty far without needing to go up or down, as long as you didn’t mind swerving around a bit. This swerving is basically the exact behavior you see on a road. My program would basically travel on the red as much as possible. If it was forced to go up or down, then the “red” area would shift radially – outward from the tip of the hill if it was moving down, inward if it was moving up.

Top: The road system on perfectly flat terrain. Bottom: The road system in pervasively hilly country.

Fuel seems to take a similar approach. It works out a network of roads. It begins with a couple of backbone highways that cut across the zone. Between those, it will form a loose grid of evenly spaced secondary roads. And between those it makes a network of dirt roads. It deliberately tries to make them a bit convoluted. You can see this in action in White Flats, one of the last zones in the game to be unlocked. (I cheated, as unlocking this zone would have been way beyond my skill.) The land is, as the name suggests, perfectly flat. Yet the road system doesn’t just default to an axis-aligned grid. Roads intersect at odd angles and form a plausible network. However, the individual roads are perfectly straight. This suggests that the road system works not unlike the one I came up with, where roads bend due to topography. This means the bends in the road are emergent, which is pretty cool. (As opposed to the programmer trying to force the road to bend around arbitrarily to make it more “realistic”.)

While not completely unrealistic, this abrupt curve is a little dubious. (There is actually a turn like this not far from where I live. The people who live on the outside of this bend have placed a row of massive rocks in their front yard, just in case some drunk or fool is careening down the road without paying attention. They’ll be stopped by the rocks instead of the house. In the above picture, note the blank gray area on the outer part of the corner, no doubt that exists to hide the awful distortion in the road lines.

The one thing that bedeviled me was the difficulty of splicing roads together. This has gotten way, way harder as graphics have gotten better. Merging two strips of flat gray polygons is trivial, but a real road isn’t flat gray. Real roads have a very distinct pattern of light and dark stripes, which I assume are the result of tires depositing slight amounts of rubber into the asphalt. Real roads have white lines at the edges, and dashed lines (or double yellow) down the middle. Splicing two of these together is murderously complex, because you can’t allow the texture to distort at all. If you stretch one texture at the point of the splice, the lines in the road will get longer or shorter, and that will look really, really obviously bad. You can’t do a hard join and simply end one road as it intersects with the other, as the patterns of light and dark won’t match up and you’ll get a huge seam. The problem gets even harder when you take into account the fact that some roads will have different numbers of lanes, and they’ll be joining at unpredictable angles. I never did come up with a way to do it without needing multiple texture passes.

It’s hard to see, but just above my driver there is a staircase-shaped seam where the two roads were stitched together.

It seems like team Asobo ran into the exact same problems. They have all the seam issues I anticipated, although they to manage to make a bulk of the road joins look passable by blurring and fading the textures where they meet. Still, every once in a while you’ll see a spot where it just couldn’t solve the splice, and you’ll get all sorts of strange artifacts. (Although to be fair, you won’t notice these bits if you’re just roaring along at 100mph, which is more likely than not.) There are a pair of extra-large four-lane highways in Fuel, and they join just southeast of the center of the map. The texture mapping is predictably wonky, but the real hilarity is that one of them brings its guard rail into the merge, thus cutting off a lane of traffic with a completely inappropriate guard rail:

Guardrail fail.

You could solve this problem by having artists make pre-fab intersections. For example, the artists could make the four-way intersection pieces, the forks, and the merges, and the program could use those the way a plumber uses pipe fixtures: Just bend the roads around and plug them in. But that only works on level land, and flattening the land around every single intersection will instantly make the world a lot more generic and repetitive.

In many cases you can get away with joining two roads with a hard edge, as is done here. It’s not perfect, but it’s not awful, either.

There are no over passes in Fuel, and no clover leaf intersections. I can understand why. Knowing when to place one or the other, and making them look acceptable on arbitrary topography, is a huge problem to solve. Engineers design these things do so on a case-by-case basis, and in games these things are made by hand, by artists. This is the first game I’ve seen where someone took a crack at doing this with code. Sometimes you need to take away earth. Sometimes you need to build up. Often you need to do quite a bit of both. You need enough clearance on the bridge yet the ramps of a cloverleaf can’t be too steep nor turn too sharply. And of course, cloverleafs would look naked without the copious signage required to make use of them, and placing those signs where they will look right and not cause problems for either of the intersecting roads is a non-trivial problem.

To the people that have been pointing to Dwarf Fortress as the zenith of procedural content: Being unfettered by graphics, DF will never have to face the worst of the procedural challenges. That’s fine. It doesn’t need to. But the really humbling challenges will be for programmers who have to work with polygons to realize their world.

One of these days I’d like to take another crack at the highway system problem. It’s a toughie, but if you can solve it you’ll have gone a long way to making game content turnkey. Even in fixed worlds like GTA, I’ll bet the art team would love a tool that let them make roads by drawing simple lines, and having the software work out all the messy details and landscaping.

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.

If it were possible to jump off your vehicle, Fuel would have the makings of a fairly thrilling base jumping game.

Confusion always arises when I throw out the word “procedural”, as there seem to be a lot of different (perfectly valid) definitions bouncing around. In my view, procedural content is about making things using simulation, automation, and approximation.

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.

The hand-made way is agonizingly time intensive, but will produce compelling scenery. The later is cheap and fast, but produces a big bland soup of scenery where seeing one spot means you’ve basically seen it all. One is stupid expensive, and the other is pointlessly dull. But the thing about the hand-made approach is that the artist spends a lot of time doing very repetitive non-creative stuff. They’re doing tasks which don’t actually require a human brain. The goal of any good procedural system should be to make sure that the artist is directly involved with the artistic decisions and is never bothered with any of the routine grunt-work.

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.

Now, artists usually jump in here and insist that you can’t cut them out of the process like this because the resulting data will be sterile and random. But note that what’s really going on is that some of the artistic work has been offloaded onto the programmer who had to implement these rules. This is probably why it’s taken so long for people to get a handle on procedural stuff: It requires a very particular sort of programmer to do this sort of work. You either need an artist who is very good at explaining what she does in concrete terms (as opposed to saying, “I keep adding trees until it looks good”) or a programmer who has an artistic flair. I’m a good example of the latter, which is why I was able to pull of the Procedural City. (With apologies for the excessive ego for the previous statement, but I really do think this is an area of particular capability for me. Too bad I don’t get to use it more often.)

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.

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.