Developing The Crew 2 came with its own set of challenges, challenges that emerged both from creating a follow up title to the original online open-world of The Crew and from introducing a suite of new features into the Ubisoft-published racing game.

Like The Crew before it, The Crew 2 offers its players the ability to race from sea to shining sea in a slightly modified version of the United States. The open-world map isn’t a 1:1 recreation of the USA as we know it, however, the team at Ivory Tower instead created a unique version of the country built around the USA’s actual geography but with the scale of states and landmarks morphed to offer players a traversable but easily recognizable spin on The States.

Of course, creating any open world comes with challenges that developers have to address, especially when players are moving through that world at breakneck speeds. Building the streaming technology to handle a massive world where the environments just fly by required the team to pay special attention to how objects were rendered in both the distance and near the player through a number of tools and graphics engine considerations.

Gamasutra recently sat down with David Guillaume and Carl Pedimina of Ivory Tower to dig the technical aspects of creating an online world that is both massive and detailed. The full Q&A below explores lessons learned by the team during development, ranging from how and why devs zoned environments into areas and sectors to lighten the computational load to tips on how fellow game developers can address the issues that creep up during development of their own open world games. 

Interviewees:

David Guillaume, Art Director

Carl Pedimina, Lead Engine Programmer

How did you go about designing your open world replica of the U.S.?

Guillaume: Our very first endeavor was to learn everything there is to know about the country’s geography, through an impressive collection of books, documentaries, maps, and other documents. Once we studied all these resources, it was clear for us that we needed to make a selection of places and environments in order to deliver the best experience, one that would be our own take on the US.

We carefully picked the cities, natural wonders, and iconic landmarks that we would recreate in the game, according to four major criteria:

One final step consisted [of] organizing research trips to the US in order to study the terrain up close and capture its essence. With such a rich database to inspire ourselves from, we could recreate an interpretation of the USA that would fit our needs and player needs.

How did you decide which areas to highlight, and how much map space to give to states, cities, and landmarks?

Guillaume: This wasn’t an easy task, indeed, and we had to proceed with a method and according to a consistent set of rules. We started defining our world’s size, with the objective to enrich it with as much content as possible. Doing this, we had to make sure we were respecting some core constraints:

Every choice we made focused on one result: giving players the best experience of the USA, [gamepad] in hand. That’s why our interpretation of the country isn’t a simple copy-paste of reality: you have to get behind the wheel to truly discover it. For instance, the Grand Canyon in The Crew 2 has been scaled down ten times compared to its proportions in real life, and we decided to recreate only the most iconic section of the huge formation.

The core of this feature will be around what kind of technology you use to stream your world. How did you design it? How does it work?

Pedimina: In the very beginning of the project, we tried to look at middleware like the Unreal Engine. It quickly appeared that this kind of game engine would not do. Our world is huge (approximately 120 km by 75 km) with a lot of different places and moods. Furthermore, the player can drive vehicles that can go over 600 km/h!

However, we did not want to reinvent the wheel. So we decided to take the basis of the Dunia Engine (used at Ubisoft for the Far Cry series) and revamp it to our needs. Eventually, we rewrote a lot of things like the world editor, the game editor, the world management, the streaming strategy, the graphics engine… and we used only 10-15 percent of the original engine but it allowed us to quickly prototype and build our own engine by providing solid foundations.

In such a project, you must quickly decide how your world must be partitioned and I think that there’s no good recipe that fits every game's needs. The core dev team was already experienced in creating and managing big game maps. The majority of us had previously worked on a racing game, so we did not start from a blank page. Our experience allowed us to quickly choose the best techniques for our project.

The world is subdivided in what we call “areas” and each area is subdivided into sectors. As you might expect, areas and sectors contain some kind of level of detail of the whole world, an area contains the low version of objects in a sector. A limited number of sectors and areas are always loaded around the player.

Because The Crew map is very big, we had to use low-resolution meshes for the far view of the world. These meshes were generated from the heightmap and optimized to have the least number of vertices. It worked surprisingly well and the player is not able to see the seams between the dynamic heightmap system used in areas and sectors and the traditional mesh used for the far view.

For The Crew 2, we added more level of details but it’s more an extension of the area and sector system to improve the view quality when using planes.

We also decided to divide the USA in “ecosystems”. An ecosystem can be seen as a library that contains the resources used by the specific places of the map. For example, you’ve got one ecosystem specific to New York, another one for New England… A few ecosystems can be loaded in memory at the same time. Ecosystems are hierarchical: a mesh in a child ecosystem can use the material of its parent ecosystem. But the opposite is not possible. The ecosystem system allowed us to have a lot of diversity by keeping the memory footprint as low as possible and [allowing] the reuse of resources without the need to load it several times.

We also extensively use object instancing: most of our buildings are made of basic blocs. It reduces the streaming pressure and the graphics engine can use hardware instancing to reduce the nu