One of the mechanics that ended up becoming prominent in our game was the combat system. Initially, our game wasn't supposed to feature heavy combat but would instead have a more puzzle focused style of game play. Mid production however, we ended up focusing on combat too. This ended with the combat evolving from a simple three combo system to including systems like dodge rolling, guarding and the Outburst skill. This also had the side effect of making the AI much more complex on my side, which I'll cover in a different post.
Batter up!
One of the first things I worked on for the combat system was the bat itself, which served as the game's main weapon. The bat's code itself was fairly simple. All it had was code on how to handle hits when it detected any with its hitbox. One of the snags I hit however was that the bat had the tendency to hit the same object multiple times causing a lot of problems. My solution to this was adding an array which would detect the entities it has already hit, and check if the bat has already hit that entity or not. If it has, it will not do the damage and knockback calculations anymore. Else, it will do so. This array is cleared whenever a combo is finished or cancelled.
When a hit is successful, add that entity to the already hit entities.
The next problem that I encountered with the bat was that since by default the hitbox was always active, even when not doing a combo the hitbox could still "hit" other things. The solution came when it was time to actually make the combo system itself. Initially, I was actually not the one working on this as I was prototyping the enemy AI. However mid production around the time we decided to push combat further, Alson had to move to other features so I took over for him.
One of the things that I did to make the combat smoother was to fix the tracking of what part of the combo the player is in, when the the bat's hitbox should be inactive or active and when a combo resets. This required somewhat of an overhaul of the existing system.
Among these tasks, the first thing I fixed was both the tracking of what part of the combo and the conditions for a combo reset. I tracked the combo chain with the use of an integer that would be incremented whenever a player completes a part of the combo. This value would always have a default value of 1, and a max value of 3.
This is then followed by the Animation Blueprint, or ABP, checking which part of the combo the player is in and playing the corresponding animation.
The next thing I addressed was the hitbox problem. I solved this rather handily by using Unreal Engine 4's animation notifications. Animation notifications are events that you can place on specific parts of an animation and is called when the animation time passes through it.
Above is an example of the many animation notifies that I used when polishing the player's main combo. The notify, Start Strike and End Strike serves as what activates and deactivates the bat's hitbox respectively. The notifies were also used to detect when a combo resets, when the player lets the animation hit the end of the full animation the combo is reset. The player is allowed to move to the next part of the animation before it hits that time frame, so pressing the button too late would reset the combo. The lunge notifies simply served to notify when the player should be moving forward during animations and when he should stop.
No comments:
Post a Comment