Jun 15, 2018

11 BOSS BATTLES OF X-MORPH: DEFENSE - PART 3, THE BOMBER

X-Morph: Defense - voidreaver

One of the scenes from the boss’ intro prototype.

As you explore the newest expansion region, you start noticing the slight trembling of everything on the planet’s surface. Ripples on water start emerging. The tremors grow stronger, as cracks start appearing on the nearby windows. Your auditory sensors start picking up a low, steady hum. Hum grows louder and louder as everything starts shaking. Finally, something emerges on the horizon. Something so massive it blocks the last rays of the setting sun. A gigantic bomber, humanity’s ultimate airborne weapon. They mean business this time.

The camera work foreshadows the events that will unfold before the player.

That’s the kind of narrative we wanted to build with the boss fight that’s the topic of today’s article. Welcome back to ‘11 boss fights of X-Morph: Defense’, a series where we share our thoughts and insights about the design of bosses and the problems we encountered while trying to implement those ideas. You can find the previous parts <here> and <here>.

The boss would start the fight by collapsing a few bridges and re-arranging the scene.

As you know already, at its core concept X-Morph: Defense was supposed to have a boss fight at the end of each level, thematically connected to the rest of the map. The map in Britain is the first one where we throw airborne units at the player in a significant amount. New types of flying enemies are introduced, including the ones attacking the core directly. It shows the player that flyers serve not only the supporting role, but are a real danger. That is why we decided we wanted a massive bomber to be the boss in this scenario. A true flying fortress - resilient, with lots of firepower and quite intimidating. With multiple weapon systems, allowing it to attack both the player’s ship or the base directly, it was sure to be a handful.

THE DESIGN

The first time the players are able to see the boss in its entirety.

As far as the visual side goes the creation of this boss was quite straightforward. It was a massive, multi-engine aircraft with clearly distinguishable weapon system located either on or under its wings. In order to intimidate the opponents, the general shape and silhouette of the plane is quite aggressive, with lots of sharp angles and resembling a bird of prey diving straight for the kill. Not entirely in line with aerodynamics, but that was not our main concern here.

The boss’ wings are equipped with various weapons and multiple engines. It was clearly built for fighting it head-on and required re-design.

Designing the fight itself was the trickiest part. Although the flying colossus was supposed to be powerful, all the attacks had to be entirely preventable by the player, not to make the fight unfair. Thus, we decided the boss will follow a set of predetermined paths and launch one of its attacks while its at its farthest from the base, preceded by a subtle dialog cue. While not straightforward at first, we wanted the players to learn the attack patterns and start connecting the dots - getting better at predicting what to do next to prevent core damage effectively.

Early boss fight design for the Britain level. The paths of boss’ attacks are marked in yellow and orange.

The attacks could be aimed at the core, at the anti-air defenses or the player. Each of those would use a different type of missile. Every weapon system could be disabled by destroying the corresponding part on the aircraft. If slowly crippling your opponents is not your thing you could also go for destroying the pilot’s cabin directly or hinder the bomber’s ability to stay in the air by blowing up the wings and fuel tanks. All of these were equally viable strategies. Also, we made sure that nobody exploited the fact there are no weapons in the back, as the boss could drop airborne mines behind it.

Every system the plane is equipped with has its own hitbox. The player may destroy them in any order, which will result in a slightly different fight every time.

One last thing - the boss also had a near-death mechanic - a nuclear bomb. Triggering at very low health, the plane would rush the alien base head-on, and if it managed to drop the nuke it was an instant kill. It was meant to create a sense of urgency, but wasn’t deliberately difficult - just enough to boost your adrenaline levels.

IMPLEMENTATION

The player was initially supposed to fight the bomber head-on, but we made the weapon systems able to target objects behind the plane.

We have said it before and will say it again - the visuals are the easiest part of designing a boss. We had the model ready in no time, and throwing it into the game was no problem at all. We have lost a bit on the ‘epicness’ of the fight due to scale and size constraints. There were no problems regarding scripting the enemy behavior, though, and we managed to achieve all the goals we set for this fight.

Very early concept of the map. You can notice a lot of differences from the final version in game today.

Upon extensive testing we reached a different conclusion - the boss was a bit too much for this part of the game. Fighting this beast did not warrant the massive barrage of missiles fired upon the player. Although we liked the mechanics, they did not fare well in the tower defense style of gameplay. All the design objectives were set when the game was a pure top-down shooter. That was the real natural habitat for this boss. Meaningfully incorporating the tower building and strategy aspect of our redesigned game was not really possible.

One of the pages of the intro storyboard. We used these as a reference while preparing the cutscenes.

Since X-Morph: Defense is supposed to cater to the fans of both genres, including such a boss fight in the game would mean that some of the players would be thoroughly disappointed, as the highly tactical level suddenly turns out to be classic bullet hell. Rather than trying to rework it from the ground up we scrapped the boss from the game completely, reusing some of our ideas elsewhere.

All of this was also happening at the time when we were quite fresh with working on boss design. Nowadays, we tend to pair the designer with the programmer, which optimizes the workflow and ensures that we do not design something we actually can’t pull off. Moreover, it was the first time working with lua scripts for some people in the studio. Although we got the boss working it didn’t feel right. The boss fight was boring, exploitable and just not rewarding enough.

CONCLUSION

The fight was difficult and not satisfying. We backed off at the right moment, and this GIF sums it up perfectly.

The flying fortress boss was another idea that had to be scrapped completely because what looked great on paper did not translate well into gameplay itself. Not all of the work went to the bin, and we learned a lot, but this was a hard lesson in modesty. We wanted this fight to be epic and exciting, while it turned out to be not so epic and repetitive. Sometimes it’s better to admit to the mistake and delete it rather than to face the players’ disappointment.

Join us next time, as we unveil the intricacies behind the design and implementation of the boss from the Germany level in X-Morph: Defense - the highway tank, JAGUAR. Until then, follow us on our social media channels for updates and fresh content.

See you next time,
EXOR Studios
www.facebook.com/exorstudios
www.twitter.com/exorstudios
www.discord.gg/exorstudios

Jun 6, 2018

11 BOSS BATTLES OF X-MORPH: DEFENSE - PART 2, TARANTULA MK V

X-Morph: Defense - voidreaver

A scene from the Tarantula Mk V’s in-game intro sequence.

In the previous article about boss battles we explained that not all our plans regarding X-Morph: Defense came to fruition. Even though it was not the first game we worked on, we did not manage to realize some of our concepts. One of the casualties was the mechanical scorpion boss, which only made it into concept art. Critically analyzing your own failures is important for your personal growth, but you must not forget about the things that went right. Today we will present to you an example of a boss battle which we managed to finish. It’s everyone’s favorite - the Tarantula Mk V.

CG animated version of the Tarantula Mk V walking through a city.

HALF THE NUMBER OF LEGS, DOUBLE THE DANGER

Originally named ‘four-leg mech’ (innovative, isn’t it?) the Tarantula Mk V is the first boss you encounter in the base version of X-Morph: Defense. The first level acts as a tutorial, easing the player into the game world and its mechanics. Therefore, the boss needed to be iconic and easy to defeat. After the aliens manage to tear through the defensive efforts of surprised humans in South Africa, the machine is deployed as an ultimate weapon in order to stop the alien invasion. Since there are many more levels in our game we think you can guess how that ends.

One of the few possible ways to destroy the Tarantula Mk V.

The Tarantula was actually the first boss we used for testing the game and it can even be seen in the footage from the X-Morph prototype, although there are a lot of differences between that and the final version. The original Tarantula Mk V was a boss for a classic, scrolling, top-down shooter. It wasn’t supposed to walk around the level freely, therefore it only moved very slightly. The weapon system wasn’t sophisticated either, as we wanted it to follow a strict firing sequence, just like in other bullet hell kind of games.

Footage from an early gameplay prototype circa 2012. Classic vertical scrolling shooter gameplay.

Thus began the lengthy process of adapting the machine’s behavior to the tower defense style of gameplay. Luckily, as we already learned, the visual design is the shorter part of the process, so we already had high-quality assets we could use. We ended up featuring them on both the old and new versions of the concept art and in the CG announcement trailer.

Tarantula Mk V promotional art.

ENVIRONMENTAL PROBLEMS

As the player launches our game for the first time it is important to establish some sort of expectations for the rest of their time with the game. X-Morph: Defense is not a simplistic shoot’em up. There is a lot more depth to it and the scope of operations is more akin to blockbuster movies rather than arcade classics. Had we simply put the boss on the map out of nowhere, the general atmosphere would have taken a huge hit. You can’t destroy the whole planet in the prologue of the game, however, so we had to limit our destructive drives and come up with something which was both exciting and reasonable.

X-Morph battling the Tarantula Mk V. In-game footage.

From the very beginning of our project, we were aiming for a spectacular, cinematic style of presentation. Both the graphics and music were supposed to emphasize the epic scope of the game. Following this line of thought, we wanted to introduce the Tarantula Mk V to the player through a cinematic intro sequence. A classic story board was made for that purpose, and we later followed with production. The in-game version of the boss intro sequence was over 2 minutes, which was way too long. On top of that we didn’t have a system for rewinding cinematics at that time, so after not long the entire team hated waiting through this sequences over and over again. As a result, we decided to remove the entire intro sequence and to re-make it at a later date.

A fragment of the Tarantula Mk V intro sequence storyboard.

Not only the intro cinematic was revised. After making the whole first level and testing it a number of problems emerged. First of all - people picking the game up for the first time had trouble completing it. If someone accidentally dies during the tutorial because of their mistake that’s fine, but we had a bigger problem on our hands. Even after several attempts, the level was still too tough. Furthermore, if somebody managed to get through the initial waves of enemies the boss fight seemed too easy. Rather than redesign the existing level we made the decision to prepare a completely new map.

The initial version of the South Africa level. The X-Morph were supposed to land on a golf field situated right next to a slum district.

FIRE IN THE HOLE

The Tarantula Mk V is the simplest boss in X-Morph: Defense but it’s by no means simplistic. All the legs of this abomination are independent systems, the player can both damage and be damaged by them individually. The spider’s body itself has 4 weapon systems, able to operate on their own and again, be disabled by the player. It’s worth mentioning at this point that we have simplified the Tarantula’s structure. Originally there were many more individual elements, but we decide to merge them for the sake of better gameplay.

Boss collision meshes are attached to its skeleton and animate along with its movement. Glitches in an animation can also displace physical collisions as pictured above.

The textures on the Tarantula represent the amount of damage it has taken, changing dynamically as the player shoots it. Not only the textures change - as the legs or weapon systems take damage, they spawn scraps and debris, making the battle look more realistic. That alone is a lot of work. There are over 500 individual objects, comprising the body of the boss. All of them have both the graphical and physical representations. As individual sections of the Tarantula’s body get damaged, it’s possible to see the damage, the debris and feel the power of the alien ship. It’s all possible thanks to a special set of hitboxes you can see below. They allow us to calculate screen space collisions of player weapons. Screen space collisions are a special gameplay trick that we use to make the player’s life easier. Instead of calculating if a bullet has hit an object in 3D space we check if the bullet is overlapping a hitbox on the game’s screen. This way you don’t have to worry if you shoot over or under an enemy because the hit will register whenever these objects overlap on the screen. That being said, we use this system very selectively, such calculations happen only between the player’s weapons vs all enemies. Thanks to this system shooting always feels “right”.

Tarantula Mk V’s hitboxes envelop its most important parts, that can be destroyed by the player.

What we enjoy the most, however, is blowing things up. Therefore, every destroyed part triggers an effective sequence of explosions, comprised of several particle effects, carefully modeled by hand after real-life examples. As a fun fact we can tell you that there are 214 explosions comprising all of the boss’s parts’ destruction sequences. The boss itself can be taken down in two different ways - by destroying the legs or the main hull - and each of those leads to the epic end animation, taking down a great part of the city in the process.

Tarantula Mk V’s death sequence destroys a large part of the city.

As we mentioned already, every part of the Tarantula Mk V is an amalgam of smaller parts, each with their individual characteristics, making the machine whole. Everything about the boss is scripted individually - its behavior towards the player, finding the path to the alien core, even the reactions to the destruction of its individual parts. With the destruction of each system on the Tarantula, an individual event is triggered, complete with a dialogue line (translated into 13 languages) and an English voiceover.

CONCLUSION

Tarantula Mk VI - a tougher version of the same boss makes a re-appearance in the Nigeria level.

All in all, after we finished implementing all of the systems that we wanted to have for this boss, it turned out to be much more time-consuming than we expected it to be. The visual representation is only a fraction of the necessary work. This made us reconsider the number of bosses in the game. Starting from 11 designs, we finished at only 4 in the main game and 1 in the DLC. Each of those has its own story and individual problems, and we will try to tell you about them in future articles.

Until the next time,
EXOR Studios

http://www.facebook.com/exorstudios
http://www.twitter.com/exorstudios
http://www.discord.gg/exorstudios

May 18, 2018

11 BOSS BATTLES OF X-MORPH: DEFENSE - PART 1, THE SCORPION

X-Morph: Defense - voidreaver

The first boss battle - Tarantula Mk V.

Before the era of deep stories, rich worlds, and morally based decisions, computer games had to catch the players’ attention by other means. The main character, level design and gameplay mechanics had to be iconic enough for the players to fall in love with. Even though the technology evolved and games have more means to keep us entertained there are some elements that never changed. One of them is boss fights.

Bosses in video games keep the players honest and the game flow in check. A good boss fight is difficult, but not frustrating. It simply requires making use of the previously introduced mechanics, sometimes in an unconventional manner. It is not an overpowered heap of meat with lots of health. It’s a gateway to the next level of gameplay awaiting the protagonist, often entirely different than before.

Vertical scrolling shooter gameplay prototype - circa 2011.

We wanted X-Morph: Defense to follow this philosophy. The initial concept for the game we had was a side-scrolling shooter, much like River Raid. We wanted to set each level in a unique environment and finish each one off with a final encounter with a boss, giving a sense of closure. We ended up designing 11 biomes and their bosses. However, it turned out that the visual representation and design of the enemy is not even half of the necessary work.

In the final version of the game, we included 4 boss encounters and an additional one in the European Assault DLC. In this series of articles, we would like to show you both the bosses who made it into the final cut, and those who didn’t. We will describe the production process, the initial design, and the end effect.

THE MECHANICAL SCORPION

The Scorpion boss starred in one of the game’s main concept art pieces

Let’s kick our series off with one design you might have already seen on some of our concept arts. This creepy crawler was supposed to be the final foe of the Egyptian desert level. It’s not the biggest contraption we’ve ever designed, but it would be nightmare-inducing for sure. With multiple smaller weapon systems and a massive laser at the end of its tail, the X-Morph would definitely feel the sting of the scorpion.

Scorpion boss render without armor plating.

Imagine this scenario. You’ve just fended off a couple of waves of enemies and suddenly the ground starts shaking. You can hear the rumble of something massive underground. Then, all of a sudden, the boss emerges from beneath the sand. You start the defense of your core and as the fight progresses you learn that the scorpion can dig into the sand and unborrow elsewhere!

Sample animations with in-game objects to scale.

This kind of behavior is unprecedented in X-Morph: Defense. Moreover, contrary to what you see while fighting other bosses, it would not follow a specified path but freely move, forwards, backwards and sideways. As for the arsenal employed against the player, that consisted of a classic minigun, an AA flak cannon, a scattergun capable of launching grenades (effective against towers), the tail laser and the tail itself. Yes - the fighter could be blown out of the sky with a massive swing of the tail.

In order to defeat this behemoth, the player had to find the weak spots and there were a couple of ways to go about it. The first, and perhaps most obvious, were the legs. If all 6 were critically damaged, the whole construct would fall down. The second was to destroy the cabin. In order to do that, the player would have to disable the shield generators first, and then destroy the command bridge. Also, the tail could be damaged in a way that would destroy the whole machine.

IMPLEMENTATION

Our graphics designers have done a great job with this one. We had the art ready in no time and the model followed shortly after. Based on what can be seen in nature we’ve made the basic set of animations. After applying textures we had a pretty good idea what it could look like in the final product. Based on that we went on to design the hitboxes, which followed the initial concepts we had for the various systems comprising the boss.

Scorpion boss hitboxes and weapons.

The whole battle was supposed to be mixed with fending off even more enemy waves, requiring the player to switch between protecting the towers and the core form the scorpion, and crowd control. We wanted the terrain to be much like the real desert. Units were supposed to slow down while walking on sand or climbing dunes. We wanted the fight to be both exciting and full of opportunities for strategic outplay.

Initial level layout and gameplay concept. In the end, the boss battle, unfortunately, had to be removed and the entire level design was changed.

Although it seemed that most of the work was behind us, it was only the tip of the iceberg. After designing the battle sequence we realized that it would take ages to implement it in our game. Additionally, programming all those special actions, attacks and win conditions also proved too much work to get it done in a reasonable amount of time. Last, but not the least, the Scorpion's movement system would have to be implemented separately for this single enemy. We had the basic animation set, but making it look fun and realistic in all possible cases would be too much to handle during the time we had left to finish the project.

CONCLUSION

You can always estimate how much time you will need to make something work. However, over time you will learn that most estimates are way off, and there are more things that can go wrong than you can think of. The concept design for the scorpion was very quick and painless, but the technicalities made us drop it altogether. We will tell you how much effort is necessary to make a boss fight work in our next article, describing something you already know well, and what actually made it into the game - the Tarantula Mk V.

Apr 27, 2018

Creating fully destructible cities while maintaining 60FPS

X-Morph: Defense - voidreaver

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 the 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 behavior 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.

https://youtu.be/mBJSeVKWPZ4

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 gamebreakingly random at the same time.

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

Destroying the environment calls for the 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 with 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-storey 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 behaviour.

Destructible building cutaway. All interior detail was modelled 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 neighbours’ 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 behaviour 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 defences 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 expects 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 behaviour 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 behaviour 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.

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!