When the development of Dead Island 2 began, UE4 had just become available. Andre Dittrich explains how that influenced the entire process, how different disciplines worked together and how that helped to strengthen the team.

Setting out to do Dead Island 2 for next gen presented us with a number of new challenges: an open world game, which is best to be played in coop on a hardware that was initially unfinished using an engine that was also not quite done. This article will give you an idea of some of these difficulties and how we dealt and still are dealing with them.

Building an open world game with 80 people’s manpower

Having done »SpecOps: The Line« (SOTL) before, we knew pretty well how to build and tune a corridor game. In SOTL literally every meter of the journey was hand-tailored and tuned to fit the technical limitations whilst still fully supporting the vision we had for the game. So if we found out that a certain setup of content was not performing well enough technically, or was not good enough to support the game, all that hard work had to be touched again by hand.

We had workflows in place that tried to make sure that levels were built iteratively to avoid as much of that rework as possible, but it still happened often enough to be a real time sink. Building a level that literally spans multiple square kilometers in the same way was not an option as it would require a way bigger team than the one that had done SOTL.

Right from the start we were clear that even if we could, we would not want to grow the team a lot bigger than that size. We simply thought that our way of working would become a lot harder if not impossible if numbers would grow too far. So we needed to find technical and work flow solutions to the problem.

To fill an open world like ours with content, you need to enable artists and level designers to do that in broad strokes. They should not need to place every bush, piece of rock, tree or construct every house and piece of gameplay by hand. We also needed to find a way to update content that was already placed in the level in a fast and efficient way that required as little manual work as possible.

The landscape

A big portion of our game plays out in the open, so being able to create huge areas of hills and natural environment is crucial for us. Most modern day engines support to create landscape by interactively sculpting it and interactively paint textures onto it. As soon as you try to achieve a more realistic look you need to start applying weathering techniques to make your landscape look like wind and rain had actually sculpted it.

Doing this by hand is a very tedious process. So we looked at doing that procedurally. Sadly, Unreal Engine 4 does not have that kind of functionality yet. But using an external tool called »Worldmachine« and some clever ways of importing data back into UE4 allowed us to achieve highly convincing results in a very short time.

The next thing we need is to add life to our landscape with grass, trees, bushes, rocks and so forth. UE4 includes a pretty powerful foliage painting system already. It allows us to paint different pieces of foliage onto the landscape with a high level of control of how this piece is randomly placed. If you try to paint convincing plant life that still is a pretty tedious problem as you have to paint the grass first, then add the flowers, then add the bushes, then add the rocks and so forth.

Looking at how that was done in the editor we saw that actually huge areas of the map were sharing the same combination of individual pieces painted onto the landscape. So we implemented a collection system to combine pieces of foliage and there painting settings into one group that you could paint in one stroke – the foliage collections. These collections of settings can be stored as individual files. Their content can be changed at a later point and these changes can be applied back into the levels where they had been used before. That system actually allowed us to go even further as our foliage artists now could not only create meshes and materials but also could prepare full collections that could then be used by others and themselves to paint life into our levels.

Adding gameplay

A good way to describe the complexity of adding gameplay into our beautiful landscapes is by describing a short sequence of gameplay:

Nina is playing a Berserker. She stands in front of a small suburban house that she is going to loot now. The first thing she does is kick in the front door. She could have just opened it or if it was locked she might have had to pick the lock. Just as she enters the house she is attacked by a group of zombies. A few swings of the sledge hammer make short work of them. She walks into the living room and starts to look around for things to loot. A glass cupboard in the corner seems to contain something valuable and she smashes it open to get at the loot inside. A few packed bags in the corner had been left by the previous inhabitants.

She is looking through those as well, when she hears growling noises from the garage. Zombies, they probably had been alarmed by the noise she had made so far. Opening the door to the garage reveals another larger group of zombies. Upon entering the garage she notices a gas canister on the left. She picks it up and throws it at the horde which is obliterated in the explosion.

This example includes a number of interactions and gameplay elements and figures 1 to 4 show how they are represented within the level editor.

All of these elements can be simply dragged and dropped into a level and come with complete functionality. In addition to that are elements that are not that obvious to the player like audio volumes, post FX settings and of course the house itself. The actual experience for the player is forged by the combination of the individual elements.

»AssetGroups«

Two systems are heavily involved here: the blueprint system of Unreal Engine 4 and a system we build: the so-called »AssetGroup«. Both support the general idea of being able to simply drag and drop something into the level that works and is playable right away.

We call this Functional Content. Blueprints are used to create entities like the cupboard the player can open, lock pick, smash open and then loot. They also allow us to combine art content like meshes, animation, audio, particle FX and so forth with functionality. Art content can be arranged and parameterized and functionality can be added by using a visual scripting language. This combination can be stored as an asset for the engine and can be dropped into the level.

Most importantly new functional content can be created or existing can be updated by technical artists and designers.

A house like the one described above uses art content like meshes, particle FX, animations and functional content like doors, loot containers, AI spawners, windows, breakable pieces, audio volumes and many more. The combination of these pieces is not something we could easily create with the Blueprint system. So we implemented the AssetGroup functionality. Any combination of objects that can be placed in a level can be combined into an AssetGroup, which then can be drag-and-dropped into a level. AssetGroups can be updated and the changes can be distributed automatically through all our levels. They are also mainly built and maintained by artists and designers. So we wanted to give them a tool they were already familiar with – the level editor.

AssetGroups are created in a level and can be play tested and tweaked in there. As soon as the creator is happy, the individual pieces that are to be turned into an asset group are selected and saved as an asset. Changing an existing asset group is as simple as placing it in a level, do the changes and update the existing asset group asset. So the whole house the player in the example has explored becomes an asset like a mesh or particle system that can be placed in the level.

Now creating a whole neighborhood of houses becomes of matter of selecting the right fully functional houses and drag them into a level. Level designers now can focus on adding quests and filling up the area with unique little pieces that turn the area into an interesting place. Artists can either improve the AssetGroups directly when polishing the houses or adding the little touches that give character to an area directly in the level. So they can focus on turning something that »just« works into something that is special.

Dealing with the uncertainties of unfinished hardware and software

When we started working on Dead Island 2 neither Xbox One nor PS4 was available in a finished state. Also Unreal Engine 4 had just become available and was still highly in flux. So when questions were raised like »How big can our textures be, how much memory do we have for that, how much physics can we have, how many Zombies can we render in what quality?« – we could not really answer them.

But we also knew that we would not be a launch title so we could rely on first experiences from the launch titles being shared on conferences and in articles and we would actually have final hardware to test and analyze our game on for a significant amount of time.

So key for us became to create the content for our game in a way that would allow us to adapt it very late in the project in an efficient way. So the update-ability of our systems described above served a double purpose.

To give one specific example: In order to be able to build a huge number of houses efficiently, the art team came up with a system of building blocks that can easily be arranged to create a multitude of different houses.

When we build the first few for the game we did not yet know how the rendering system would handle them. Should we leave it in small pieces to be able to cull more efficiently or would it be better to combine all the pieces into one or a small number of meshes to reduce draw call count? How would we create the LODs for the houses?

Initially there were no LODs but as we had expected they became necessary very soon. So we extended the houses to support LODs and distributed that change to all our houses in the levels automatically. Once we know exactly what balance between number of meshes and their size works best for the culling system of the renderer we also will be able to update all the already placed content in the game.

The closer our levels get to final quality the better we are able to analyze the performance and memory behavior and adapt our content accordingly – again and again relying on the ability to update the content of our game in an easy way.

Game development has become a much more technical process

The technical solutions described above were implemented by a mixture of engineers, level designers, technical artists, artists and so forth. For a project like Dead Island 2 we involved content creators much more into the technical side than before, because allowing them to create the game in an efficient and fun way is as important as getting it done in a way that will give us good results.

New rendering techniques like physical based shading require content creators to have a much deeper understanding of the technical details of it to create content in the right way. A system like the »mix and match« system that allows us to create hundreds of different looking zombies was mainly invented by the character art team.

The foliage collection system was developed by a mixed team of engineers and artists. Functional content like doors and containers are completely implemented by technical designers and technical artists. The game designers are actual part of the implementation process of their features.

So one of the biggest changes we see when looking at the way we build Dead Island 2 is how much closer people from different departments collaborate when working on the game and how much more everybody needs to understand of the way his peers do their work. This shortens iteration times dramatically.

It creates a new level of understanding between the different disciplines and by that strengthens the team.

Andre Dittrich

Further reading on MakingGames.biz