X-Morph: Defense is a hybrid of twin-stick shooter and a tower defense game. In our game we give the player control over an alien life form invading the Earth. It is obvious that alien invaders are not going to care for anything that stands in their way, hence the need to incorporate destructible environment into our game. Our ambition was to give the players the means to destroy everything they see in its entirety. 

The concept of total destruction is great, however we did not want it to be simply cosmetic. It needed to have a real effect on the gameplay, altering the enemy behaviour and level shape. Using NVIDIA’s PhysX was a good starting point. It allowed us to calculate hundreds of simultaneously colliding objects at great speed. However, we needed a custom solution to simulate the destruction of entire skyscrapers. This is why we needed to devise our own destruction system, geared specifically towards lifelike building and bridge destruction.

Over the years, many video games have charmed us with the degree of destruction they allowed us. There is an unspeakable amount of joy in completely demolishing your surroundings, a sense of power even. While developing X-Morph: Defense we wanted to give players that feeling. It wouldn’t be much fun if a simple block of flats proved to be too tough for the alien technology. Our destructible environment was born.

Destructible environment - sounds good, but what does it actually mean?

The purpose of introducing the ability to rearrange the environment was not pure aesthetics. Since X-Morph is a tower defense game there are some rules it must follow. One of such rules is that the enemy units move across the map following a route. We wanted the destructibility to be one of the ways, alongside the laser fence mazing system, the enemy paths could be altered by. Then again, if every object could block a path, the game would become unpredictable. Thus began our longer-than-expected quest of creating something that looks fun and realistic, not being game-breakingly random at the same time. 

The player can collapse buildings to destroy enemies and block their passages.

Destroying the environment calls for rubble to be left over and introducing a large number of moving objects on the screen puts a huge strain on the processors. We had to figure out how to achieve a satisfying level of destruction on the screen while maintaining a good framerate, especially on consoles - 60FPS on PS4 and XBO was our benchmark. Large objects are handled by their own system, completely different from the system for small ones. This required our team to prepare the assets for the purpose of destruction in mind. All large models are divided into parts, which we call chunks. Each chunk is of similar size. 

Early prototypes of the building destruction system used simple gray blocks as construction chunks.

At this point we had a pile of cardboard boxes stacked on top of each other. Knocking them over can be fun, but gets old quickly. We wanted the different parts of the buildings to interact with each other, while also being aesthetically pleasing, dropping parts and deforming. Moreover, when you destroy a building, you actually expect it to behave like a mass of concrete and steel, heading towards the ground at a breakneck speed, driven only by the forces of physics. Unfortunately, material mechanics calculations used in the real world would be too complex, requiring to much data input and processing power. The real-time game world would not be able to handle it.

Another thing worth mentioning is predictability. We needed the system to behave in a way that is easy to foresee for the player. Since no part of the destructible environment in X-Morph: Defense is scripted we had to tweak the physics a lot. Otherwise, we risked the playability. Most players would not be happy about a random wreck hitting a skyscraper and sending it down on their carefully planned defenses. Also, we needed to make sure that the toppled buildings fall where the player wants to see them. 

Brick by brick

While creating destructible objects we decided to divide them into some categories. Small buildings would consist only of one logical part and the player could wipe them out completely. Then, medium sized buildings - large enough to be comprised of chunks, yet not big enough to block enemy paths. 3 or 4-story blocks of flats or shops fall under this category. Then, we have the biggest ones - ‘skyscrapers’ as we call them. They are usually comprised of at least 7 floors and demolishing them may result in changing the enemy behavior. 

Destructible building cutaway. All interior detail was modeled manually.

Figuring out the right scale of the game world had a great impact on the destructibility system. Had we kept realistic proportions, the view of large parts of the game world would have been obstructed by the massive buildings, towering over the rest of the area. Other meshes would have to follow the same scale, rendering some things barely visible or invisible at all. We found the solution to this in the classic representatives of RTS genre. We have changed the scale of particular parts of buildings in order to fit the game screen and not obstruct the view. Lower floors of skyscrapers, for example, have kept their size, but the higher ones are smaller. It is almost impossible to notice this in-game, as the isometric point of view allows us to mask this procedure. 

If you would like to learn more about this technique and its implementation we recommend reading this great article. 

Now that we had the scale problem out of the way we could finally decide that the chunks must have similar size. We have reached this conclusion after series of tests. Chunks of different sizes would behave too unpredictably for the player to consciously use to their advantage. Therefore, we have made the decision to base them all on one size, with later tweaks. 5m*5m*5m seemed like a decent choice. Of course, this limits the resolution of the final object we can create, however, one must remember that increasing the number of chunks would put a lot of additional strain on the processors. The number of elements grows to the power of 3, and that can get out of hand pretty quickly. The size we decided on gave us enough to work with, while still being renderable in real time.

Typical destructible building structure. Chunks have regular size and are connected using joints. Joint connections describe a building’s physics skeleton.

Next, we had to give our chunks physical properties. Each building has a special type of physics skeleton that describes the connections between all chunks. Physical connections between chunks are called joints. They are the pieces connecting our logical elements of the bigger object. They are dynamic and are influenced by the forces of tension and compression. If the tension on the joint is too high the elements become disconnected. When the compression gets out of hand the element is destroyed completely.

Early tests. Destroying bottom chunks destabilizes the structure and makes it fall apart.

These calculations are easy enough for the computer to handle in real time, yet just enough to give birth to something decent. Obviously, disappearing parts and detaching cubes are still far from what we are striving for. When a chunk is destroyed it spawns debris, a number of smaller elements representing the remains of what used to be your neighbors’ living room. When a large building is destroyed we usually spawn hundreds of individual pieces of debris. This is where NVIDIA’s PhysX really shines. We use the system for all rigid body calculations. It can handle enormous amounts of objects. All of these calculations are done on multiple CPU threads which leaves plenty of space for our main game update loop. Additionally, the explosions in X-Morph: Defense are usually the size of one chunk, covering up for the things we simply could not hide. 

Buildings interact with each other making chain reactions possible.

Getting to a satisfactory level of object behavior took a lot of tweaking. We needed to decide what was enough to destroy a building and what is not. For example, a crashing jet fighter will obliterate a single-chunk house, but will only make a dent in the composition of a skyscraper. This is due to the consistency we were striving for. If everything could destroy a building the player’s defenses would be under constant threat of being crushed by a random construction falling over. Accidental destruction of buildings would make using them tactically almost impossible. We made sure that only certain types of weapons were able to consistently cause enough structural damage to set off a chain reaction resulting in an engineering disaster. The only other force able to deal with unwanted pieces of architecture are bosses. This way the player always has the avenue to control the environment and affect the gameplay the way they want.

Controlled demolition can be used to reliably shape enemy path.

In addition to that, we added lots of smaller elements that enhance the feeling of something explosive and eventful happening on the screen. Camera shake, paired with controller vibration make you feel that something massive has just been destroyed. Randomized parts and sparks show that what you destroyed was not an empty cardboard box. Last, but not the least - we spent a lot of time tweaking the physics of falling objects in order to prevent them from bouncing comically. Imagine this colossal tower being cut in half, only to happily jump through the whole city. 

It took a lot of tweaking to get the parameters right. Early results were often really strange.

Content Creation - The toilet paradigm

Cutting up a building piece by piece reveals its interior.

So far we have put the player in an environment decorated with nice, physically accurate, buildings, which can be utilized in combat in a predictable manner. They are not houses of cards, either - they behave like an amalgam of steel and concrete should. However, they are still devoid of life. And so began the lengthy process of handcrafting everything. We estimate that this undertaking took at least two years of hard work.

We started by creating sets of interior decorations. It is easy to go absolutely crazy trying to model every room in the smallest details, so the toilet paradigm was born. If an object is smaller than a typical toilet - disregard it, move on to bigger stuff. Having enough to complete at least three distinct floors was enough for us to mix and match the rest of the interiors while keeping them all non-repetitive and realistic. Now, why would we bother creating interiors if everything was going to be destroyed anyway? 

Everything comes back to our pieces of the puzzle - chunks. You may destroy them in any order you like, which means that slicing off half of a building horizontally is possible in the right circumstances. What the players expect to see at that point is not an empty space, but the remains of the floor. Therefore, modeling the interior design was necessary, as even the parts of the walls and some furniture give you the impression that the building you just razed was actually used for something. It is certainly better than blank walls.

Destructible buildings are very complex and expensive assets. We used multiple texture sets to increase their number at a fraction of the full development cost.

This method of designing and modeling objects was very time-consuming. In the end, it was all worth it, since the mayhem on the screen is immensely satisfying for most people, but if we decide to do a similar thing in the future we will need to introduce some automation. Sacrificing another 2 years just to make good models is not a feasible solution. 

Destructible environment vs gameplay

Bridges can be collapsed to eliminate paths and destroy enemies that are on them.

The last, and perhaps the most important, thing to mention is the behavior of enemy units when faced with such a dynamically changing environment. We wanted to make the enemy unit navigation easily predictable so that the player could use the characteristics of the environment to their strategic advantage Some patterns of enemy behavior have been introduced as a direct result.

If the path is obstructed, but not blocked entirely, the enemy units will simply walk or drive around. The attack path will visibly change but it will be clear for the player that more work needs to be done in order to block it. Dropping a big enough object on the path will block it completely and the units will turn around, looking for an alternative route. As for the unfortunate ones under the actual rubble… well, they don’t have to worry about anything anymore. 

Falling buildings can be used as a weapon.

Whatever you do, no matter how much explosives you use, you will not be able to get rid of the building foundations. The reason for which these elements are indestructible is not a technical limitation. It is a conscious gameplay decision. Had we allowed to level the whole map, the game would have become too easy. The defenses you would be able to set up would simply prove too much for the puny humans, so we gave them a chance. 

A problem arises when the last possible path to the core becomes blocked. Our laser fence mechanic has its built-in limitation that will not allow the user to block the last possible path. What should happen if the same path can be blocked by blowing up a skyscraper? Sometimes the simplest solutions are the best. In this case, the remains of the building dissolve, allowing the units to pass through. 

The last enemy path towards the alien core can not be blocked. Conflicting buildings will be automatically dissolved.

There were some experiments with different approaches, like trapped units calling for air support to help clear out the way, going over, under, around… but that comes at a cost of inconsistency. If they are able to bombard this pile of bricks, why can’t they just bomb the core? To avoid questions we did not have a real answer for, we decided to simplify the mechanic. It needs no introduction and the players didn’t seem to object to it.

Conclusion

Creating our own system to handle the destruction of large objects was well worth it. We have managed to meet our design objectives and achieve the look we were striving for. In hindsight, however, it took too much time and effort. We had our hands full all the time with work which was very tedious and repetitive most of the time. In the future we will have to introduce automation, leaving the division of meshes into chunks to the computer. This will drastically reduce the time necessary to achieve similar results.

You are all welcome to follow us on Twitter and Facebook. We are always keen on discussing technicalities with other developers and share our thoughts on gamedev. We hope to talk to you soon!