Games Practical Project Development Blog - Week #3
This weeks main focus was implementing and understanding animation blending, and starting my combat system.
My first task was to get a basic sword swing animation from Mixamo, and apply that to my UE4 Mannequin.
After getting this base animation implemented, I needed to blend the animation with whatever other animations are happening at the time, from the bottom spine up. That way the players can attack while walking or jumping, and uses the players idle animation while swinging and standing still.
With this, I have the players attack swing as a montage in a "RootMotion" group I created, to separate the attacks from the other animation. This layered blend per bone uses the "Spine_01" bone in the Mannequin, and combines it with the other animations that run all the time.
With this knowledge on how to blend animations, and call them when needed, and with the RootMotion group already setup, I can add more animations to make combos or combo modifiers and have them already ready to work with the players movement. This was all the animation work I did this week, but this will speed up animation work in the future.
After this I reorganised my folder hierarchy to make it much more organised going forward, and will allow for a clean, efficient workflow going forward.
Next was to set up the actual functionality of the attack. Starting with a hitbox for the players sword, which took a lot of tweaking before the players range/accuracy felt reasonable, and is ready to be tested.
Now that that is in place, I was ready to set up a quick attacking event, locking the players rotation until the attack was complete. In theory this was to allow the player to be more mobile during combat without losing their ability to attack in any direction. This basic system sets the "Attacking" Bool to be true for the duration of the attack, then calls the attack call event. This worked, however was very easy to miss, as the attack event is only called at a specific frame of the attack animation, and if any point before this or after this the player hits an enemy, but missed that specific frame, the attack will not go through.
This was very troubling, and needed to be fixed quickly, but first I needed to test the attack event in general, so I set up the Master Enemy.
After the Attack event is called, and an enemy is in range, they then take damage based off the players attack stat, and the enemies defence stat. This then finds the difference, and subtracts it from the enemies health, before running another check for if the enemy has 0 or less health.
After this was set up and running, I went back to find ways to make the attacks more dependable. To do this I did two things, firstly I revamped the attack event in the player, calling the attack event multiple times during the animation rather than just the once, then I also hooked up a Do Once to the enemy, and run multiple checks before allowing it to happen again. This ensures the enemy isn't hit multiple times in a single attack, futureproofing myself for player combos, while keeping the damage from getting out of hand.
Finally, I spent a lot of time looking into ways to run dynamic lighting without going overboard on processing. This is vital for the game to look anyway decent inside the randomly generated levels, and as such spent a lot of time researching the topic. I decided to follow the steps provided in an old UE4 Forums post with a similar problem to solve, which can be found here: https://forums.unrealengine.com/development-discussion/rendering/17926-lighting-options-for-procedural-generation?fbclid=IwAR0OLsmlzDMHp-DrBeLqGNqUyltyjgaCZgDeciwdluYH-4G_Ah06dFKzNiw
With these settings in place, the game no longer needs to rebuild lighting at any point, and will allow the levels that are generated on the fly to be lit accurately.
Comments