Procedural World Building in Ghost Recon Wildlands

Technical artist Erwin Heyms showed how his team approached the production of small cities, rivers, and roads in the open world game. This is the second article in the series, talking about the production of Wildlands. You can find the first part here.

Introduction

My name is Erwin Heyms, I’m from the Netherlands and I am a Houdini Technical Artist with a background in level design and event scripting.

I joined Benoit Martinez’s team on the Wildlands project in 2013 and have been responsible for the creation and application of some of our most intricate large scale tools such as the road builder and the settlement builder.

GR Wildlands was my first real job in the industry. After I graduated I followed up with an internship at Side Effects in LA, where I was responsible for their Siggraph 2013 Demo of the Houdini Engine API.

Roads and Rivers

Creating roads was the first task I was in charge of when I joined the Ghost Recon Wildlands project.
At the time we were exploring how far we wanted to go with Houdini and tools in our pipeline.
We didn’t just want to create another open world though – we wanted to create something huge, credible and beautiful, something players could really get deep into for an extraordinary experience. creating the world of Wildlands was far too big of a task to tackle using traditional terrain sculpting techniques, that’s why we decided to create new tools.

We had potentially thousands of kilometers of roads that had to make sense, the varied and often mountainous Bolivian landscape. It would have been nearly impossible to reach a consistent result without some kind of unifying system.

We got the road system operational quite quickly and it made us realize the power of a tool driven pipeline.

Not just because it allowed us to have a high iteration speed for our road network, but also because it provided us with a boat load of metadata that we could use for all kinds of other tools and data for features in our game.

The road builder toolset is basically a customized pathfinding algorithm that follows the terrain features of our game world.

The pathfinder runs in a loop, adding roads sequentially onto the existing road network.

Designers use the tool by setting waypoints for each road segment, and by telling the tool what type of road they want it to create.

The tool had to be easy to use and flexible enough for our artists, and be able to automate as much as possible the actual road construction process.

So we took this into account and made sure the designers could configure everything from the curviness of the roads, to which areas the pathfinder should avoid, to how strongly new roads should magnetize using existing roads.

This may sound complicated but it’s really quite simple to understand.

A good way for making a tool that builds natural looking roads is to think about how people would build roads in the real world.

And just like in the real world, it all really comes down to construction cost, and how to produce the cheapest road possible.

Under the hood the system basically does just that.

By defining in the pathfinder features such as steep slopes or making lots of tight turns in the road costs more than shallow roads with less turns, we make the pathfinder look for cheaper alternatives.

And as a result the roads that the toolset produces will snake their way up a mountainside.

Similarly, by telling the pathfinder that following existing roads are dirt cheap compared to other options, newly created roads will seek out existing roads and branch with them instead.

This feature especially is responsible for some really nice and realistic looking road networks.

As for how we applied the road network to the terrain…

By running the road network through a terraforming tool, we would get a series of height maps, materials and masking textures.

To keep the workflow light for our designers, the terraforming tool was able to run exclusively on our render farm.

Every time a designer was done placing a road, they could push the job to the farm, and within a few minutes they would have the result ready to stamp on the terrain.

The railroad and river tools used a similar process, they all used pathfinders but with different rules.

The railroad tool requires much shallower and more sweeping paths than the roads did, creating tunnels and bridges along the way as it tries to navigate mountain slopes.

The rivers and streams made by Twan De Graaf were only allowed to path down a mountain slope and would try to find their way from the tops of mountains to the nearest body of water below.

The resulting blend of rivers, roads and other elements could sometimes create some pretty amazing locations.

City Building

One of the biggest challenges was to get the towns to look realistic, especially for different environments and sizes.

Road connections had to make sense, the town had to look as if it had grown outward, with bigger buildings in the center radiating outward into smaller houses and farmland.

The road pattern in the town had to change as well, we had to be able to define districts, ensure key buildings were placed in logical locations, etc. The challenges all-together were quite staggering.

The first version of the tool that was handed to the designers could build towns that looked like rural villages.

It built a series of main streets with smaller streets interconnecting the center, radiating outwards into the outskirts and farmland.

A step by step process of how the first version of the tool works.

Initially, the tool produced mostly small villages such as this one.

This worked quite well, but as with a lot of things in production, once you give artists the ability to build big, they will build bigger.

While our designers were able to manually draw or erase roads, the tool in this form was too limited to create a convincing result.

What we really needed was to create cities and this represented a whole different bunch of challenges.
So for the second version I added support for grid roads, sidewalks, rows of buildings and several other features.

Barvechos – A sprawling city.

There is also the time it takes for the tool to calculate building placement. This “cooking time” grows exponentially with the area of the settlement you’re trying to create.

Calculating all the buildings at once for some of our largest towns could take up to 20 minutes.
However, cooking time can be mitigated by caching the data to disk, which could also allow building placement to be calculated in smaller clusters at a time.

Algorithm 

The building placement system is probably the most complex part of the entire settlement tool.

It uses a self-aware packing algorithm that we feed with a list of buildings, each with its own rules for placement in the town.

The algorithm tries to place each building from the list in order of priority or by a predetermined ratio.
The tool prioritizes key landmark structures first and then fill out the rest of the town with houses, market stalls and other secondary structures that really bring the town to life.

The algorithm works by dividing the town into small areas separated by roads and then working outwards, scanning each area for suitable placement locations.

And it then gathers up a large variety of information about these locations which it checks against the buildings in the list that could spawn there.

Notice how each area in the town spawns different buildings.

Information such as proximity to the town center, water’s edge or nearby railroads, the slope of the terrain or specific districts are defined by the designer.

But the tool also looks at information about other buildings that have already been placed.

If a church already exists in the town, it won’t spawn another religious type building within approximately 150 meters of that church.

All together I created more than 70 different rules and conditions that we can set per building and it really makes the placement algorithm extremely powerful and flexible.

Many of the towns in our game have specificities, and knowing that we were able to achieve this level of detail using a tool still amazes me today.

It also allowed us to keep towns across the world consistent. And if we had to move or change a town for whatever reason, the tool could make this otherwise intensive task quite easy.

To put this into perspective, over the course of development Barvechos, one of the biggest town, has probably been completely rebuilt more than 5 times.

This is the Settlement Builder for Barvechos and the terrain stamp which we converted into a height map.

But of course this level of complexity comes with a few downsides.

First, we had to manage all these rules somehow and be able to keep them consistent for the designers.
Luckily, Gratien Vernier, our technical level designer, wrote a very handy interface that allowed us to configure each town and each building easily.

So if we had to change a settlement we could simply change the rules, load the new presets into the tool and re-export the result.

The final result of a town is stored in a series of files and textures and instanced in the world using a lightweight instancing tool.

This settlement instancer also allowed us to make final tweaks to the town without having to re-cook it completely.

Khochi – this town combines a lot of different tools together.

Those tools allowed us to build a more consistent and authentic world because it helped the artist to get rid of repetitive and tedious task, giving them more time to focus on adding extra details and telling meaningful stories on top of the procedural layers. At the end I can tell that we are all very proud of what we achieved!