Destructible Environments
An R&D project based off of the destructible terrain in Deep Rock Galactic.
Learn More Below!
About
The decision to create a Destructible Environment system, was out of curiousity by the immense joy and immersion, Destruction can bring to games.
My goal was to better understand the limitations of destruction and the possibilities within gameplay. I specifically wanted to improve my skills in engine and Deep Rock Galactic's implementation of Destructible Terrain was a truly inspiring prospect.
This project was more R&D than an actual game, but there are plenty of games that are made around this feature.
Role
SOLO DEVELOPER
Project Breakdown
The goal of this project was to recreate the destructible terrain from mega hit Deep Rock Galactic.
Dev/Publisher: Ghost Ship Games / Coffee Stain Publishing
Release Info: Microsoft Windows, Xbox One, Xbox Series X and S, and Playstation 4 & 5.
Steam Description: Deep Rock Galactic is a 1-4 player co-op FPS featuring badass space Dwarves, 100% destructible environments, procedurally-generated caves, and endless hordes of alien monsters. Steam
.png)
Game Reference
Feature
A dynamic mesh that is destructible after taking a specific amount of damage; the destruction is tied to an area chosen by the player. Can create tunnels through this mesh.
This gif is a reference taken from Deep Rock Galactic.
Initial Research and Approaches
Approach 1 - Pre-Fractured Meshes
My initial sketch in trying to break down the feature with the approach of using Unreal Engine's Chaos System.
1. Point of Contact on the mesh itself. marked by the [X].
2. Calculate the area of destruction. This is set by the developer so that the player destroys a consistent amount of terrain per hit. (can also make this random with some extra math)
3. Identify pre-fractured pieces within the area.
4. Remove fractured pieces or 'let them fly.'
Results!
Key Take-away: This would be a great approach for a game full of high octane explosions that don’t rely on the player needing to tunnel and climb through the mesh.
The detailed breakdown:
During my jaunt into the Unreal Engine's Chaos System, I learned that the chaos engine works on its own thread. This means that Chaos Physics is calculated separate from gameplay. This becomes clear when huge chunks of the square are destroyed and the debris move in slow motion.
To make this approach optimal, I’d have to put in more work to remove debris or hand off some of the smaller debris to the Niagara’s System.
This method is not easy to control. Due to the fracturing being a bone system; destroying one part of the mesh effects other parts of the mesh as well.
I like the idea of the chaos fields, but the parameters are not intuitive or easy to utilize with my current state of knowledge.
Approach 2 - Mesh Deformation
In my second approach, I decided to return to the source material and get a better understanding of how the developers of Deep Rock Galactic, approached this feature.
I quickly realized that their approach is not using any pre-fracturing, but rather a Mesh Boolean operation disguised by VFX.
1. The Pickaxe marks the location and deals some initial damage which is just a texture for player feedback.
No actual boolean logic has occured on the first hit.
2. When enough damage has been dealt, boolean mesh logic is performed.
2.5 Dust and debris are spawned for that player juice
Boolean Logic?!
Mesh Boolean Operations are fundamental in 3D modeling.
The user can combine two solid shapes and create unique outcomes depending on the operation. Common ones include: Union, Intersection, Difference, Symmetric Difference.
Visual from Boolean Operations on Polygons Wiki
Results!
First I made it functional in engine during the level construction.
I added functionality to allow the deformation of complex mesh geometry.
Then I got runtime mesh deformation functional.
I added functionality for the developer to change the shape of the destruction.
The gif shows a skull deforming the mesh, then a pyramid.
Final Steps
After the basic functionality was complete. I refactored my approach to consider developer ease.
I created documentation breaking down the feature, and how to set up this component into any project.
Museum to easily showcase the feature and functionalities
I created a mini demo level to show off the various functionalities of this feature in gameplay.
Added some juice to the Meelee functionality.
Added functionality to a ranged weapon.
Added new functionality to create ice platforms
(this was a bonus due to boolean operations)
Conclusions
Overall the project was a success.
There are many learnings from this R&D exploration.
1. Don't always settle for the first approach. Sometimes it takes a few attempts before you find the approach that is optimal.
2. This is especially true when thinking of software architecture. Considering how a feature may grow and how to design that feature so it may scale with ease.
3. Refactoring is a vital part in creating software. Just because it works once, doesn't mean it's done.
