Setting Up Destructuible Cars for Steel Hunters PvPvE Shooter

Destructible Cars

Goal

The sense of scale playing a giant mech was the main creative goal, and abandoned vehicles were one of the main scale markers and interactive objects in Steel Hunters. The main challenge while designing and implementing the system was to achieve a cool user experience, keeping in mind a wide range of user PCs, performance and gameplay constraints, production optimization, and the possibility of outsourcing asset creation. Here we'd like to share with you a high-level framework overview, which, I believe, might be useful in many similar production cases.

Concept Art and Asset Pack Planning

At the concept stage, we define the vehicle's type, pack, and purpose, develop its overall shapes and silhouettes, work out fine details, and identify destructible components, such as the body (made of multiple parts), wheels, glass, and doors. We also design common elements at this stage, allowing for optimized seamless production and reduced asset creation costs.

Production

Cars are modeled with destruction in mind. We use low-poly geometry while preserving visual readability and form clarity with a reasonable polycount. Topology remains clean and simple; small deformations like dents, seams, and surface irregularities are added later during the texturing stage.

To further streamline production, we unify repeatable parts for thematic asset packs, such as wheels, interiors, and chassis, allowing for reuse across different models and saving time on production. Each model is split into logically separate components: body, doors, hood, glass, wheels, and bumpers, with pivots set up at rotation points, all of which are physics-driven using real-time deformations.

Obviously, we use Substance 3D Painter and our own shared presets, templates, smart materials, and packing methods to create textures that emphasize contrast between materials: metal, plastic, and glass, and include wear and tear effects like rust, chipping, and soot to achieve consistency across the board. The key thing here is to prepare technical tint and weathering masks in the correct way for future in-engine customization.

The car's shader in the project uses two texture sets, separated by vertex color. One contains a texture atlas with components shared across the thematic pack, such as chassis elements, wheels, and other interior parts. The second set is unique for each vehicle model and includes details specific to the particular car, a baked normal map, and damages.

In Unreal Engine 5, assets are assembled into a Blueprint: collision setup is handled here, and individual parts' durability and weight are configured to control how each element reacts to impact. At this stage, we also actively test destruction behavior to catch all possible edge cases.

Vehicle Material System

In terms of per-actor customization, all cars and other destructible assets are integrated into the global customization system, which provides smooth per-biome asset integration:

Customization

Color

The car's blueprint is designed to support dynamic color changes by using Custom Primitive Data, allowing us to change the car's colors directly in the level without increasing the number of materials and draw calls. For recolorable models, we use a mid-gray albedo combined with a custom mask.

In-engine customization by custom primitive data

Global Weathering & Environment Integration

Just like other destructible entities or props (rocks, buildings, environment assets), vehicles are integrated into the global weathering system. The integration allows them to blend seamlessly into specific biomes, avoiding material and asset duplication.

Damage States

Using the same Custom Data approach, we can control the damage state of a vehicle, ranging from light wear to full destruction or burnout. By default, a pristine vehicle placed in the level will respond to external forces: shots or collisions from our character trigger deformation, glass breakage, and ultimately, an explosion. After exploding, only a scorched car shell remains.

Destruction

The big luck was the fact that cars were presented only on the client's side and were not present on the server, as they are not gameplay-critical entities. This gave us significant room for flexibility in the system's design and allowed us to fully leverage multithreading for optimal performance without worrying about replication overhead. However, since the game is focused on duos and squads, we used approximate replication so players can enjoy in-game situations without losing much of the experience.

All cars remained in a dormant state, placing no load on gameplay logic. Upon activation, they began performing per-tick calculations, but we optimized performance by using asynchronous ticking. This included computing the positions of doors, hood, and trunk relative to the vehicle body's world transform, as well as determining which nearby objects should be awakened due to contact with the vehicle's body.

The most exciting part of the game

We paid special attention to cases where players destroy tens of cars simultaneously. For that purpose, we determined the limits of dynamic objects in the frame for each graphics preset and created adaptive unload logic for dynamic objects based on bounding box size to reduce pop-up effects and exclude performance spikes.

Working with limitations is always a compromise between quality and performance. To support artists with an understanding of limits, reduce the count of performance issues in the build, and increase efficiency of the workflow, we prepared a "World Statistic" tool which helped artists work smart – not hard

Deformation

The last important ingredient for better immersiveness is morphing. Deformations are simulated using free-form deformations; the entire vehicle's local axis-aligned bounding box (AABB) UVW coordinates are used to map induced offsets to mesh vertices inside the vertex shader. Offsets are allocated in an atlas upon vehicle interaction and are interpolated using tricubic filtering. Each vehicle uses 4x4x8 texels to store deformation. Such a setup runs very fast and produces results similar to a mass-spring system (MSS).

Debugging deformation behavior

Summary

• Decompose your specific creative goal
• Formulate tech and art requirements, create a production workflow, and develop proper tooling for each stage of the production process
• Plan your asset packs and reuse as many details as possible
• Increase asset reuse in the world through multiple customization layers between shaders and blueprints
• Profile it based on your project's PC specs range
• Debug the workflow and document everything to achieve smooth asset creation by outsource partners

Kudos

Building truly dynamic, destructible objects was a collaborative effort between artists, designers, and engineers. Massive thanks to everyone who contributed creativity and problem-solving to make the pipeline possible: Vadim Morvaniuk, Ivan Kutenev, Oleg Groshev, Denis Zhuchenia, Sergei Larkin, Pavel Molchanov, Vlad Firsov, Aleksandr Strizhenii, Igor Mariev, and Anton Belov.

Anton Zheludev, Art Director