Overview

The completion of the data persistence system meant that I could begin work on the game's dodging system alongside player death and victory. This entry goes into detail about how I made the turns work, how the game handles the enemy attacking the player (and vice versa), the transition towards the end game screen when one of two conditions are met (player health <= 0 or enemy health <= 0), and issues that I encountered along the way.

Technical Description / Explanation 

The very first thing I thought to do before working on anything else was the round system, as this will transition the player between the combat and dodging segments. The round system is fairly simple - when the player takes an action (e.g. attacking the enemy), they're transitioned to the next stage (in my example, dodging). If it's part of the enemy's turn, the player avoids getting hit or is talked to by the enemy (dialogue has yet to be implemented however). Enemy stages progress using delays on the Event BeginPlay that prevent the player's turn from immediately starting. For example, during the dodging segment the enemy attacks for a random amount of time before transitioning back into combat.

With the round system implemented, I began working on the player's dodging and conductor attacks. It's important to note that this will be reworked at the end of Alpha or very beginning of Beta, as I later learned that I had interpreted the game incorrectly - it was to be a 2.5D game and not a 3D game. It wasn't that big of a change mechanically - just changing the camera and reworking the conductor's attacks to work in 2.5D - but it means that the dodging segment in specific is not an accurate representation of the final product.

It wasn't too difficult to implement the system either way, the Conductor spawns in one of an array of attacks using a random integer in range, for example a spin attack (which at the moment is just the conductor spinning a white block around). This attack happens for the remainder of the round. A collision box around the attack detects when the player has overlapped and uses the damage function within the player pawn blueprint to deal damage to it. I only ended up implementing one attack before finding out about the issues with my current system.

As for the player, they (currently) have a third person movement system without a jump (as I didn't implement it in time before finding out that the system is wrong). There's nothing else special about the player's dodging pawn.

The final segment of gameplay that needed implementation was the game over and victory screens. These don't have much functionality at the moment, simply being adapted copies of the main menu level, but the victory screen will display the player's rank once a point-based ranking system has been implemented in early beta. 

Reflection

My biggest hiccup for this segment of alpha was definitely the misinterpitation of Archie and Luke's playboards and concept art for the dodging system. Having to swap over from 3D to 2.5D, while not complex, did eat into a bit of time I could've spent on implementing some of the features that I have had to leave until beta. As for the quality of the programming in this section, I think it's a fairly robust and expandable way of dealing with the conductor (and, if this were a full game, other enemies / bosses) and his cycle of attacks. To improve, I plan to work on implementing the full set of moves that we as a team have discussed, alongside test how the attacks feel for players using playtesting at the start of beta before moving on to implementing the mirror transition and point system.