Crash Force

Head Designer / Art Director: Demetris Markitanis Lead Programmer: George Neokleous Software Architect: George Tziazas

Bringing Crash Force’s essential multiplayer to life



Developer: Ascanio Entertainment Game Title: Crash Force Release: July 20, 2017




EFG spoke with Ascanio Entertainment about their multiplayer arena shooter Crash Force. Crash Force features multiple hovercrafts across three classes, a plethora of abilities and ability types, and fast-paced arena combat – either online with other players or with bots.


The impression I got was that Ascanio put a lot of work into Crash Force, and many hours went into testing and balancing the various hovercraft and their abilities. Perhaps the biggest challenge Ascanio faced was balancing the different hovercrafts. With three classes, and three vehicles in each class, balancing statistics for each vehicle was difficult. Add in multiple abilities for each vehicle – both movement and combat abilities – and you have a lengthy development process. Each vehicle needed to feel unique, but also balanced, which means that Ascanio was constantly testing and tweaking the gameplay with each iteration. Pacing and balancing combat encounters may have been difficult, but for the team at Ascanio, it was important that Crash Force had to be fast, fun, and competitive.


Exploring Hovercraft Design Options

Hi, my name is Demetris, and I’m the Head Designer at Ascanio Entertainment and Art Director of Crash Force. My role in Crash Force was to come up with the general design direction for the game and later implement the pre-decided concept within the game. Furthermore, I took part in the design of the UI wireframes, feedback systems, and the levels.


Generally speaking, all vehicles in Crash Force fall under the category of hovercrafts. However, at the time we were designing concepts and coming up with the main functions of the vehicles, we did not necessarily want to follow the conventional ACV (air-cushion vehicle) approach for the designs to avoid limiting the conceptualization of the desired sci-fi element.


In addition to the main category of the hovercrafts, there are three sub-categories solely based on the vehicle size and its primary functions in the arena. Consequently, there are three main categories: small, medium, large.

Translating Bird Anatomy into Hovercraft Vehicles

There were many ideas for the design of each hovercraft. What we had realized early on was that we had to base them on a specific concept which we would have to maintain throughout the entire game. Thus, we had decided that each hovercraft was going to be designed based on anatomical characteristics of real birds that exist in nature.


Since we had already laid down the subcategories of each hovercraft (small, medium, large), research was conducted to find birds that would reflect the characteristics of each sub-category and start analyzing their key features.


For example, one of the bird families that was analyzed for the design was the “Aquila” genus a.k.a. “True Eagles.” As with every other bird family, there are thousands of species that fall under the same category. We went through and analyzed many of those species to find specific birds of which key anatomical and behavioral features would make the foundations of the hovercraft family. Fortunately, for the design of the vehicles, we had significant help from a 3D art studio (Digireal Studios), which aided the design process and helped a lot with the general conceptualization.


For each vehicle, the design process was the same:

  1. Identify key characteristics of the bird family, mostly anatomical characteristics.
  2. Choose a bird species from the pre-decided bird family that potentially reflects gameplay characteristics for the specific hovercraft sub-category.
  3. Design drafts of concept art and analyze each design too.
  4. Finalize concept art.
  5. Design 3D model based on the concept art.


Currently, there are three families of hovercrafts in the game (nine vehicles in total). We have decided to ship the game with nine hovercrafts to give players enough options and versatility. However, we are planning on adding more hovercrafts to the game as we want to keep improving the gameplay experience.

Family Specific Abilities

Each family or faction (if you prefer), has a distinct, unique ability which we call a “family ability.” These abilities have been designed and implemented in a way that they reflect the characteristics of the bird family the hovercrafts were based on.


If we take “Aquilas” the eagle family as an example, all three hovercrafts of that family share the ability of “wormhole.” The wormhole ability allows the hovercraft to bend time and space around it to “jump” or “teleport” (if you prefer), in a relatively further location. We had decided that this ability suits this family since eagles are considered to be fast, agile and in some sense predatory-like creatures. This ability gives the vehicles of this family an advantage in mobility and survivability in the arena.

Technical Limitations

The first thing that comes to mind is having to alter certain vehicle models that were exceeding a certain number of polygons. This process is always expected when working on a 3D game. However, we felt like keeping the polygon count below the average optimization line to make the game playable on a wider player demographic, i.e., players that own computers with lower than average system specifications.


Unfortunately, in any game, there will always be technical limitations. There are always things to keep in mind when designing in order to keep the game optimized and at the same time maintain an acceptable graphical fidelity up to the standards of our audience and of course of our own.

Finalizing Hovercraft Designs

Discarding or scrapping vehicle designs always comes early on in the development of a vehicle. During the process of art conceptualization, designs do not always meet all the requirements to be finalized. Thus, what we do is a procedure we like to call “mix and match,” where we take features that we like from each design and compile them to a final design.


It is often hard to decide when that time has come, where we must determine that a vehicle is finished and ready to get in the game. We often struggle with the notion of “Finished vs. Perfect.” However, when working with strict deadlines, you do not always have the luxury of constant iteration for each design. Thus, we determine that a design is ready and finished when it meets all the requirements already pre-decided in the Game Design Document (GDD).


Hello, my name is George Neokleous, and I’m the Lead Programmer for Crash Force. My role in Crash Force was to design and implement various functionality in Crash Force such as the multiplayer and mechanics of the game.

The Client-Server vs. the Host-Join Model

At the moment Crash Force offers one type of multiplayer which is the authoritative client-server model with the use of dedicated servers. The reason for using this type of multiplayer instead of the host-join was first to minimize the possibilities of cheating. Second, players would be able to play the game on equal terms as far as latency goes, since a host has no latency during the multiplayer communication.


Last but not least, designing the multiplayer model in this way, the machine and internet connection of a player does not affect the others, something that is a major drawback in the host-join model.

Game Modes

As far as modes go, Crash Force now offers three which are Deathmatch, Team Deathmatch, and Capture the Flag. We also have a training arena where players can sharpen their skills on different hovercrafts. Modes are an ongoing procedure so they will keep coming as the game moves forward. Our next mode to be added in the game will be a type of Control the Point.


Crash Force at its core is a very competitive game that urges the player to engage both strategic skills as well as fast reflexes to keep up with the ranks. Multiplayer was mandatory for Crash Force, as far as we see it, due to these reasons. We feel that the true beauty of Crash Force was greatly enhanced when played with or against other players, especially friends. The implementation multiplayer for Crash Force was also crucial since we want to have the option of entering the e-sports scene.


Modes will keep coming into Crash Force as the game progresses. The reasoning on what game modes were available to the public during the release was to give the players the option of a casual Deathmatch mode and also smooth them into the more competitive team based and objective oriented modes of the game using the Team Deathmatch and Capture the Flag modes.

Implementing Multiplayer and Using Unreal 4

The whole process of implementation for the multiplayer took place within UE4 due to the fact that the engine offers a large selection of tools for implementing and testing multiplayer functionality such as simulated packet loss or latency. Well, one of the biggest reasons for selecting the engine to use for Crash Force was the multiplayer functionality that the engine had to offer. What it meant for Crash Force was an excellent multiplayer system developed in the engine that had been used by several other titles and proven to be very solid.


Implementing multiplayer functionality takes into consideration several factors such as the quality of the internet connection of a player as well as the ability of a player’s system to compute and process the packets received through the network. During the implementation of multiplayer, we faced several issues that had to do with too many multiplayer related actors trying to update values and creating network hiccups and failures. Several of these issues were solved using actor pools, where only a predetermined number of actors could make network calls instead of an infinite, or better said, an unknown number of actors constantly being created, destroyed and updating values.


Another way we used to limit our network calls was to combine them whenever made sense to do so. For example, values like energy and rotation, even though they have nothing to do with each other, were combined for an update in a single call because the rate of update of these values is the same. Instead of having two network calls for each value we use one call to update both. This method limited our network calls in more than half of what we originally had.


The advantages that UE4 has to offer for the multiplayer functionality is firstly the almost no need for network code due to the fact that Epic Games has made an excellent replication system that works almost out of the box when using the engine. Secondly, UE4 offers great flexibility when it comes to prioritization of network traffic and how easily you can set the network relevancy of different actors.


The disadvantage of using UE4 for our multiplayer functionality was the amount of work needed to make the game work with dedicated servers. For some reason, Epic Games has very little documentation regarding dedicated servers, and unfortunately, the replication system is built around the host-join type of multiplayer, so we had to work on making the game work with dedicated servers without much help from the documentation.

Challenges and Limitations

The biggest challenge we had to face is the ability for each hovercraft to stand its ground against the rest of the bunch. For example, a tanky hovercraft should be not only able to take damage effectively but also be able to do the damage if need be. The same applies for the small crafts, where even though they are easily killed due to low health, they all have means to escape effectively, and they can also pack a heavy punch. Not as powerful as our mid-range hovercrafts though, since they are the ones considered to be the damage dealers. The way to overcome this challenge was the constant fine-tuning and balancing of values like speed, health, energy, and damage for each hovercraft.


Limitations, as described in previous questions, included the number of network calls and processing time for the calls. There wasn’t any functionality that needed to be scratched during development as such, but many of the functionalities that initially were network relevant have been migrated only on the client side, such that the gameplay and graphical fidelity would still be high on the client without loading the network with unnecessary functionality. One of the most visible examples of this method can be seen with the particles used depending on where the hovercraft currently hovers. While you can easily see the particles of water flying around your hovercraft when hovering upon the water, you cannot see these particles for any other hovercraft except your own.


I am George Tziazas, and I am the software architect of Crash Force. I have worked in various parts of Crash Force, one of them being combat design.

Pacing the combat

The idea behind Crash Force has always been to be fast-paced. Combat should follow the properties of the game without negating the concept of team play and strategy. As such, combat in Crash Force is fast. Hovercrafts have high damage outputs, low cooldowns on their abilities, and high speed. While a lot of games have fast-paced shooting, very few of them also have abilities on the characters. Even fewer put those abilities on a very low cooldown to make them almost constantly replaceable. Crash Force is the only arena shooter to have hovercrafts that move at high speeds. The selection of hovercrafts as characters has impacted the way our combat system works. The match is intense for most of its duration because you are always fighting. The maps are large enough not to feel crowded but small enough not to make it possible to move for four seconds without finding an enemy or an ally. All that, without losing the notion that this is a team based game and players win and lose as a team. This constant thrill is also the reason why we made our match length ten minutes only.


Encouraging Team Composition

The team composition is important in Crash Force since it can make or break a fight. With nine different hovercrafts and three more on the way, the players have a variety of options to play with.

There are options for the players: to select different hovercrafts depending on what they like to play, and what their team needs. There are three distinct “super classes” a player can select to play with.

  • First, we have the small hovercrafts. They are more fragile than others, and their abilities revolve around crowd controlling their enemies (i.e., stun, blind, slow). They are excellent disruptors and can disengage easily.
  • Second in the list is the category of medium hovercrafts. They are the main damage dealers in the team. Their damage output is the highest among the others and their abilities revolve around ways to maximize their damage.
  • Last, but not least, we have the large hovercrafts. They are tanks for their team. They all have at least one ability that deals a good amount of damage, while the rest of their abilities are either engage/disengage for their team or disruption for their enemies.


We can also categorize the hovercrafts to three different families. The families are defining the allegiance of the hovercrafts in the storyline. They also define, in a way, the playstyle of the hovercrafts.

  • Aquila: This family’s hovercrafts have more speed and damage than their enemies’ counterparts. They have a raw power advantage.
  • Cicuma: This family’s hovercrafts have lower cooldowns and better energy consumption that the other families. They can continuously utilize their abilities.
  • Clava: This family’s hovercrafts have better survivability than the rest. Their abilities help them stay alive longer than the rest giving them the opportunity to fight for a longer period of time.


A skirmish in Crash Force usually starts and ends within five seconds. The participating hovercrafts will engage, fight, and then either disengage, or some of them will go to the scrapyard. A team fight in Crash Force can take up to twenty-five seconds. It starts with the initiators trying to crowd control the damage dealers of the opposing team. At the same time, their damage dealers try to kill as many of the crowd control hovercrafts of the enemy team they can. The rest of the fight heavily depends on the hovercrafts participating.

Testing and Balancing Ammo Usage

The pickups were an addition that came in early in the development of Crash Force. First, we tested the game with unlimited ammo on the weapons. The balance felt off since the damage dealers were overpowered. They did not need to pause to refill their weapons. They just pressed right click and kept it pressed; then, they won the match. We had to do something about that, so we decided to have a finite number of ammo on each weapon, and when the hovercraft stopped shooting, it would “regenerate.” It was definitely better than unlimited ammo, but something in the forced downtime did not stick to the fast pace of Crash Force. We then tried ammo pickups, and we decided that was what we need. Ammo pickups are not just refilling your ammo. Ammo pickups are a way to deny power to the enemy, or never stop shooting, or create ambushes around them. Ammo pickups gave Crash Force a lot more than just a way to handle ammo. They gave it more strategies and playmaking potential.

Balancing Damage Per Second (DPS)

Well, let me start by saying that the initial values of damage per second (since the game begun) to the today’s values are very different. The values of damage on the weapons of a hovercraft are given having in mind what we need that hovercraft to do. How do we want it to perform? How do we want it to battle? What is its purpose in team fights? These are some of the questions we use to determine the initial value of the damage on a weapon.


Then, we have to take into account the abilities of that hovercraft, as well as the most probable skill trees to be used with that configuration. These factors also impact the damage but also the rate of fire of a weapon. Then, we have to test it internally and since we are not always able to test every possible configuration, give it for testing to our users. If everything works as intended, great, if not, back to the lab; we still have work to do.

Overall Balance and Ability Testing

We wanted Crash Force to be a game that can accommodate as many different playstyles as possible. We wanted our hovercrafts to be as diverse as we could make it in order to accommodate all kinds of players (this is also where the vast skill tree selections come in play). We wanted Crash Force players to be able to play the way they want to play. Some players like to be supports, others like to be tanks, others to disrupt and others like to deal damage. It would be unfair to the players and to the game itself to not cover as many as possible of those playstyles since the potential is there.


The first tests were always conducted internally. We were testing the hovercrafts with different team configurations, different skill trees, and different players. Then, we gave it to the early access environment and waited on their feedback. Community feedback is something we always took seriously. If a balancing issue came up, it would probably be in the lines of: with this particular skill tree configuration and this hovercraft I always win. In that case, we rolled up our sleeves, tested it, found what makes that configuration overpowered, tested similar configurations, fixed it, tested it, and redeployed it. I am happy to say that since we left early access period, there have not been incidents of overpowered hovercrafts.


There were cases of shuffling around abilities that did not fit the character of a hovercraft, or even redesigning them completely because they were hard to understand and/or use. An example of such an ability would be Aquila Rapax’s upend ability. Upend travels the player four seconds back in time giving the player the health and position they held at that time. Originally, it was placed on another hovercraft of the Aquila family, Aquila Minuta, and the player had to activate the ability once to a state where they would like to return when they reactivated the ability. Playing with it, it felt wrong on Minuta. A small skirmishing hovercraft did not need relocation. We then tried it on the assassin of the family, Rapax. Immediately, it felt natural. Rapax went in, killed someone, got out. It was still awkward though the fact that you had to activate the ability twice for it to work. We limited the time to four seconds (originally it was up to fifteen), and we made it only need one activation. Players started using it more because it was easier to realize what it did. When we started seeing outplays and combos by our players, we knew we made the right choice.

The Challenges of Balancing and Pacing

The biggest challenge when designing the combat system of Crash Force is a close call between the balance of pacing and strategy and the balancing of the hovercrafts. We wanted to create a combat system where the strategical decision was necessary (team composition, skill tree utilization, arena management) to win but at the same time, the preparation for combat and the actual combat would not take more than five to twenty seconds. The damage, health, abilities, cooldowns, and speed of each hovercraft had to be assigned having that in mind. Additionally, we had to also have in mind the interactions between those hovercrafts and the skill trees such that no hovercraft would be too strong or too weak.


My name is Demetris, Head Designer at Ascanio Entertainment and Art Director of Crash Force.

Principles of Level Design

Since the design of the prototype of the game three years ago, we wanted to take an elemental approach to the level design. Consequently, we have designed each level to feature a unique setting to enhance the overall gameplay experience and make each level identifiable. In addition, each level was designed and named based on key characteristics of each hovercraft family.


As a result, we currently have three unique maps in the quick play pool:

  1. Aquila Plains: Desert plains with a cave and some ruins, home of the Aquila Family.
  2. Cicuma Forest: A forest scenery with two small lakes, a temple-like building, and altars, home of the Cicuma Family.
  3. Clava Tombs: A dark, high-tech, three-story building, home of the Clavae.


Wireframes and generic layouts for each level were initially designed with pen and paper. We had to make sure that the structure and general flow of the levels made sense first before proceeding to start modeling the architecture and placing props and structures inside the game. Modelling and design of the architecture for each level was made inside Maya.


Using as references the biggest and the smallest of our vehicles we produced guidelines for the measurements of each level to make sure that the vehicles would be able to navigate through them without obscuring their movement, as well as avoiding compromising the fast paced feeling we wanted to give to the game.

Balancing and Testing Levels

Testing and balancing the levels was a non-stop process that was re-engaged every time we added something new to the game. When adding new abilities, or changing existing ones that had to do with the mobility of the vehicles, we had to go back and re-test every level to make sure everything was working as expected.


Internal testing was an ongoing process during all the development phases of the game. Fortunately, though, we have a big community of beta testers which definitely helped us with testing the levels and generally the game.


It is pretty hard determining whether a level is balanced. There were definitely things to keep in mind in order to avoid favoring or hindering players based on their spawn locations in the level. Again, this is something we had major help with from our community of beta testers.

Graphics vs. Performance

As with everything else in the game we wanted to maintain high quality in graphical detail. However, as I am sure you are aware quality always comes as a trade-off in performance. The prototypes for the levels were designed in great detail in their architecture and environment, something which caused a few instability issues in performance and would resultantly narrow the range of machines that the game would be able to run on. As a result, we had to sacrifice a rather small amount of detail to keep everything optimized and potentially expand the targeted demographic.

Favorite Level

I guess if I had to choose a favorite it would be Clava Tombs, just because it took them the longest to design, optimize, and balance. From what I recall during the prototyping phase, we were considering to scrap Clava Tombs entirely and replace it with an entirely different map. Initially, the level seemed way too complicated flow-wise and structurally. However, I am definitely glad that it has come out the way it is now.


We feel that we have worked hard on Crash Force and we have managed to produce something that we can be really proud of. Nothing beats the feeling of observing people playing Crash Force and being enthusiastic about it. In addition, we are glad that the game was able to start forming a community that keeps growing every day.


With the game being officially released, surely, we cannot go back and change major elements in its key functionality. However, nothing stops us from keep improving the game and keep making changes while always considering our users’ feedback.


We like to believe that the thing that makes Crash Force fun is its fast pace and its competitive spirit. In addition, since each hovercraft has a unique skill set, choosing a hovercraft and exploring its capabilities can be a very exciting experience. What we have found out by observing players playing the game is that when people are playing with their friends and forming teams, they are enjoying it more and it is definitely one of the best ways to get the most out of Crash Force and everything it has to offer. Thus, we are proud to have been able to create a game that promotes the team spirit and urges people to join in with their friends in order to play and enjoy the game at its fullest.




We thank Demetris Markitanis, George Neokleous, and George Tziazas for talking about the development process on Crash Force.