With progress steady on the introductory segment, I decided it would be smart to get to work on creating the RPG combat system that will be integral to the project as a whole. While I tried my best to maintain the same focus on modularity that I have earlier in the project, I ran into some unqiue issues (discussed below and in part 2) that meant I had to use less modular systems as placeholders until I came back around to make a reworked system.
The first blueprint that I worked on was the new player pawn that the controller will change to when loading into the combat level. It's mechanically simple - there's no need for movement mechanics yet as I have yet to implement dodging (or even round combat). The pawn loads in, is swapped to, and then executes everything within BeginPlay. This includes setting totalhealth to the player's current health as it will always be at its max at the start of a battle, although in a full game where the player can have multiple battles it might be smart to store the player's total health elsewhere (such as in a data table) so it can be pulled from by multiple resources without having to cast to BP_RPGCamera, along with having permeance throughout multiple levels (as the player's health is effectively reset upon reload). I may implement this smarter method later on if I find the time or especially the need (such as if I implement the dodging segment of combat in a different level). The pawn then creates the battle UI widget and transition widget (creating variables of them too for reuse throughout the blueprint). The player's transition widget plays its animation to transition the player into the scene before hiding itself. The player's mouse is then unlocked for interaction with the UI.
With the player pawn set up, I worked on the battle UI. I created a progress bar for the player's health that is changed within the player's damage function. I originally tried to make it progress smoothly, but decided to work on this later (perhaps in beta) to give myself time to implement more core features. I also added the buttons and animations for the player's attacks (along with some of the code), but it is not complete yet.
To damage the player, I (as previously stated) use a damage function that takes in a float value and applies that to the player's health. I divide health by the player's total health to get the percentage and apply that to the health bar.
The player can only lose at the moment. To lose, they must simply lose all their health. Upon doing so (triggered by each damage event checking if the player has died and calling the custom event Event GameOver), the game checks if the GameOver event has been called because the player died or killed the Conductor / enemy. At the moment, this simply resets the scene (for testing purposes), but this will eventually lead the player onto the death or victory scenes accordingly.
The enemy has little functionality to it at the moment. It is a placeholder model with a red texture to distinguish it from the player. It, like the player, has both a health function and damage function for applying damage. Unlike the player, I don't need to apply the damage done to a health bar, and thus don't need to work with assigning the conductor's totalhealth for percentage calculations.
Open images in a new tab in order to view the full image
I ran into issues both of my own doing and of unfortunate circumstance. The biggest issue came from committing and pushing to GitHub. In most circumstances, this is thanks to OneDrive syncing at the same time as me trying to commit and push to the repository. However, in one funny circumstance it was caused by issues with GitHub itself. In the future, I'll aim to try and wait for OneDrive to sync before trying to pull / push.
As for the code itself, my biggest issue with it is the technical debt I am putting myself in with all of the workarounds I am using to get it to work. Going forward, I'm going to try my best to make code that I am (to my knowledge) aware will work with other planned features. This has already been happening with my use of functions and custom events to clean up the code and make it more reusable.
Overall, I am happy to move onto the latter half of RPG combat (coding the enemy, round mechanics, dodging, and victory screen) and come back to the less efficient parts of this code later in development, likely towards the end of alpha or start of beta as part of a round of debugging / code refactoring.