DashNVibe was a project started by Étienne Francoeur and Alec Ménard during our first development course on Unreal 4, in parallel with my Totally Innocent Virtual Frisbee project done for a specialization class. This project was part of an exercise where I had to develop a character controller in the form of a competition. Following the cancellation of several projects, including mine, the two initial members of the project decided to choose me to join them for the rest. This project was our first project of this magnitude where the design profile of our bachelor's degree was combined with the artists profile, and therefore we worked together

The game consists of going through a series of three rooms and corridors in order to reach the end and defeat the Boss. The two original members chose me to design and program the Boss fight for the end of the game. The game is designed with two main mechanics, which is to be able, on one hand, to Dash in all directions and, on the other hand, to be able to slow down the time to succeed in certain sections.

In the first idea, the Boss had to look like Moldorm from The Legend of Zelda: Link's Awakening, where the player had to attack the tail to cut it off with his Dash, until only the head remained, which then made it possible to eliminate the Boss. After discussing this with the team, it was clear that we would have neither the time nor the know-how on Unreal to make this idea a reality. This was our introductory course on the game engine and our first Boss fight after all.

That's why we finally chose for a simpler Boss that we could make sure to succeed. So I designed a static Boss, which would send its attacks to the player, who would be able to counter-attack between the different waves of attacks. The Boss has three phases. The first is two fists that track the player and try to crush him once from above, the second is a classic bubble-hell, and the last phase is a combination of the previous ones. The player can fight the Boss by performing a Dash on the enemy's weak spot when it appears between two attack phases.

In the first iteration of the Boss balancing, my goal was that the player can finish the fight in 3 phases if he has enough mastery of the fight or more if he has more difficulty. To do this, I arbitrarily chose a short duration where the player can attack the Boss. This duration had to be short enough to encourage the player to use the time delay, while leaving the player the possibility to react and attack his enemy. After a few trials and adjustments to arrive at a duration that seemed good, I was able to determine that the player had time to attack the Boss more or less seven times per phase. Therefore, it seemed good to me to put 21 hit points on The Boss. This way, the player could see all three phases, with some phases repeating themselves if the player couldn't do enough damage when possible.

During the development of the project, we were fortunate enough to have one of our teachers test our game to give us his impressions. The comments he shared with us were very interesting and showed us several shortcomings that the game had, especially in the boss fight. At the time, the battle had no animation or models from our artists, as they had focused on other elements, such as the scenery. So the Boss was just white cubes or spheres, with some moving for the spheres attacking the player or the Boss's weak point. So there was little feedback still built into the game. The main problem noted by our teacher's actions in the game was a lack of understanding of the Boss's life points. Our teacher believed that it was only possible to inflict one hit point per period when the weak spot was available. He therefore experienced a 21 phase fight spread over 3 different attack paterns, which confused him about his progress and whether he was actually inflicting damage to his enemy.

Finally, with the team, we decided to make up for the flaw discovered during the test with our teacher by reducing the number of health points to 3 and imposing the end of the Boss's vulnerability period after a delay or when the player inflicted a damage point to it. This second iteration of the Boss phases and the implementation of its components by the artists resulted in the first Boss fight of our academic cohort.

In addition, in order to facilitate the understanding of the Boss's condition, the first and obvious feedback to be implemented is a life bar for the Boss to communicate the progress of the fight. Then, we added the ascetics of the artists we missed, as well as sounds, and the game became clearer. By the time our teacher came back for the second time after testing the game the first time, he found the game more readable and we had fixed the problems he had found in the first iteration of the boss fight. 

The Team :

Pierre-Antoine Carrière
Mathieu Clerveau
Philippe Desormiers
Étienne Francoeur
Alec Ménard
Julie Nguyen
Samuel Perrier
Christophe Pesant