Breaking down the completely destructible world of Deliver At All Costs

Who hasn’t dreamed of bombing around a city, wrecking everything in their path?

That’s pretty much the premise of Deliver At All Costs, a chaotic new action game created by Far Out Games and published by Konami. Players take the wheel as courier Winston Green, picking up unlikely deliverables, then blasting through absolutely anything and everything to get this cargo to its destination.

One of the title’s highlights is its completely destructible world – almost every building in the retro ‘50s beach vibe gameworld can be blown to smithereens, as can the player car.

Getting there (while hitting 60 fps target) was a feat. We sat down with game director Daniel Nielsen, technical director/lead programmer Jonatan Johansson, and Lars Olsson, Far Out’s CEO and level design lead, to learn how to create a world that falls apart differently each time you play. 

Unity: Let’s start with a bit about the game.

Daniel Nielsen, Game Director: In Deliver At All Costs, you play as Winston, a courier with a temper in a world where everything is destructible. You’re delivering the most crazy things you can imagine – everything from a huge one-ton swordfish that’s flipping and flopping in the car, to balloons which make the car fly. Everything’s based on physics.

Lars Olsson, CEO, graphics, and level design: It’s in a sort of 1950s Americana world. We spent a lot of time creating a nice atmosphere with coherent music and sounds from that era.

One really unique aspect of this game is the totally destructible world. Can you tell me a bit about how you created that?

Lars: The destructibility of the world has influenced everything from how we build our assets to the amount of geometry and meshes being used. Everything needs to be double-faced, so if you destroy something, you expect to see the inside – it’s not just an empty shell. We wanted to make the world a very reactive and immersive place to be, so everything you do impacts the environment.

How did you guys approach asset design where everything falls apart?

Lars: We model each building or prop or asset with that in mind, and make sure to add relevant meta data to the different elements of the 3D model. Then we bring it into Unity and we shatter it to make sure there’s a reasonable amount of parts that it can crumble into. It’s quite a set-up process in Unity to make sure that everything feels nice to destroy. We usually end up driving through each building at least 20–30 times just to know that it feels good to destroy it from every angle.

We’ve set up custom pipelines for different types of assets.

Jonatan Johansson, Technical Director: Yeah, we try to break it up a little bit already when it’s modeled in Blender. So you have the roof, the windows, and the walls separated from each other already at that stage, and you can categorize it and assign meta data depending on material.

Then, when we bring it into Unity, we have custom tooling in there to fracture all of these parts even further down into smaller chunks, and that will also take the meta data from Blender into account.

With our pipeline, we can say which parts of the building should have the glass effects on them, for example, which automatically sets up particle effects, sound effects, things like that. You do this for all the different types, then we have a tool that lets you press one button and it creates the whole baking setup with physics, optimizations, and required structures so that you can quickly get to the point of iterating on the feeling of driving into it.

Lars: When setting up a building or asset for destruction, I need to test the setup in a scene with environmental context. It's happened to me more than once that I’ve found myself realizing, after a while, that I’ve drifted off course and started destroying something else in the scene entirely. It’s easy to get carried away in the fun, so to speak.

Jonatan: The idea for the destruction in the beginning was quite simple: What if we take a building, break it down into a bunch of parts and add physics to all of them – what happens? It was just chaos, everything exploded everywhere. But we were able to resolve most issues with some pre-processing steps to avoid unnecessary collisions and what not.

Eventually we hit the biggest problem, which to be fair we had expected from the start – performance. It has been the biggest challenge with this system, and has been an ongoing effort throughout the whole production. It forced us to rethink some fundamental things to get it under control. Then maybe one of the most important optimizations was to apply clever culling logic to limit the amount of physics objects that are alive at once.

What were some of the techniques that you guys turned to keep the performance in check?

Jonatan: We have a lot of objects. The buildings can be around a hundred parts or physical objects each when fully loaded, which is quite a lot – usually, you maybe have single digits on a complex building. That causes the physics engine to take up a lot of performance, but of course also brings a lot of draw calls.

One of the main techniques we’ve been using has been very, very aggressive culling. We got a lot of help from the camera angle, which is sort of unique for this type of game nowadays.

It’s top-down, almost orthographic, giving an isometric feeling. We really used that to our advantage in the optimizations. Because we always know which direction the camera is going to be looking, we know for sure that everything that’s to the right or to the left of the camera, for example, won’t be shown. So we use that a lot to determine which elements are off-screen. Even then we found that we needed a significant part of the frame budget allocated to physics. There are a lot of other things in the game, like AI cars driving around, a lot of gameplay code running, and that also takes a lot of performance. We really needed to squeeze out every single bit we could to let the physics do its thing.

We’ve ended up heavily optimizing a lot of our own game systems. But we also made optimizations for a couple of systems that we did not build ourselves. For example, we used Unity’s terrain system for the ground mesh for most of the scenes, but we’re not really using LODs because of the camera, since you will always see the game from the same distance. The terrain system has its built-in LOD function, which took a couple of milliseconds every frame from the frame budget, and we didn’t really need that but there was no way to turn it off. So we implemented our own hybrid solution. We baked the terrain into a mesh, essentially, and that saved us a couple of milliseconds. We also got some big savings from optimizations to the decal rendering. We’re heavily relying on decals to add extra detail into the textures since we have so many different types of assets.

Lars: We’ve had huge advantages using the Unity terrain object with its tools as well – the optimization that Jonatan’s talking about happens during gameplay, but for me as a level designer, I can still work with the Unity Terrain tool and don't have to think about that part.

Daniel: Another big optimization that we did was tweaking particle systems. When we changed them to unlit, that saved a lot. All these tiny parts that you work on for many years make a difference together.

Jonatan: We’re using a lot of particles for the destruction. If we were doing a truly realistic destruction, we’d need thousands of parts, which wouldn’t work.

You could say that there are a few different steps to the destruction. First, you have the whole building, then you have the building broken into parts, and then each part breaks into mesh particles, which is the particle system. It’s a lot cheaper, and we use a lot of dust to hide all the small little details that we don’t want the players to see, but it blends everything together in a nice, coherent way.

Lars: It hides the transitions. Spawning dust particle systems hides the transitions between real physics bodies and when they turn into particles, so it feels as fluid as possible.

Daniel: I think one of the most impressive things about the whole game is that if you play the game on PlayStation® 5 or Xbox Series X and destroy everything you see, you’ll still have 60 fps no matter what you do.

The last thing I wanted to ask about was physics. There’s a few different areas where physics gets really interesting in the game, the destructible buildings of course but also the way cargo shifts in a moving truck bed as you drive.

Daniel: The cargo’s actually been customized for every single mission in the whole game. There’s one mission when you’re delivering this huge fish, the marlin, and that’s been set up with bones.

Jonatan: We have some fundamental things that are the same. Since most of the packages you’re delivering are intended to impact the car and driving in some way, we usually start out with just adding a physics joint between the parcel and car to see how that interaction creates interesting moments.

There is obviously a lot of scripting going on to make the features work well in gameplay. With the fish, for example, we added a lot of forces to the car and played around with it for a long time to get it to feel just right. That by itself creates interesting interactions – just putting something crazy on the car, and letting the physics engine figure it out is a good start.

Lars: The player car itself heavily relies on physics as well, but we’ve also needed to tweak a lot of stuff, since physics can be a little unpredictable. For instance, if you drive off a cliff and are airborne for a certain amount of time, we found that you would usually suffer less damage than your instincts tell you, so we increased the damage factor so the car reacts more like you would expect it to, rather than in a way the physics engine would automatically lead to.

Jonatan: All cars are also destructible of course. The player car has around 36 parts that can fall off, and they’re all deformable also.

For the car and the parts, we use the physics engine and collisions, but we also calculate all the forces and try to figure out what the damage should be. Sometimes we have to cheat a bit with the damage numbers to make it feel like this corresponds to what you’re doing.

For the doors, if you hit the door, we can break it off and add a joint so that it swings out and hangs, and then if you hit it again, it will just fall off completely and stay on the ground. You can also lose the wheels of the truck, and then it affects the driving because you start driving on metal. If you lose the two front wheels, you can’t steer, but you can still drive – but we have a way to repair them of course.

Daniel: The biggest challenge we actually had with the player car was that it tended to roll over, so we had to do a lot of different tricks. For example, for every wheel off the ground, the gravity on the car increases to stabilize it and force it down on the ground. Another problem we had was that if you drove into civilians, they often got stuck between the many colliders in the car, since we have 36 detachable parts. To solve this, we changed the setup to just a handful of large colliders. It was quite uncomfortable to see the civilians getting stuck in the car, since their ragdoll setup would start to freak out. 

What are you most proud of in the game?

Daniel: I think it’s making everything destructible. Around 95% of everything in the game is destructible.

Jonatan: And running at 60 fps.

Lars: We tried to not repeat assets so players will explore the world and find new things throughout the world. And since it’s all destructible with physics, even if you drive through the same house a hundred times, it’ll never crumble exactly in the same way. It’s always something new, which I think makes the game very replayable.

Deliver At All Costs is available on PC and for PlayStation 5 and Xbox Series X|S. To read more about projects made with Unity, visit the Resources page.