The Spell-Zerker: Part 2
With the melee attack animation logic for the Weapon Mode implemented, things looked good to go for implementing the Combat Mode switching. But first, I took a couple days to go back and address some of the feedback I’d received.
The Curse of the Static Left Hand
One of the issues with my implementation of the weapon attacks and the animation slots was that the animation I’d done for the off-hand during the attacks wasn’t being used. To attempt to address this, I exported the off-hand animation as a separate FBX, then plugged it into the Left Hand slot on the attack animation montages.
This solved the problem, but now the animation plays in conjunction with the Time Slow animation, which also occurs on the off-hand in the Left Hand animation slot. I’ll look into ways to solve this in the future, but that’s for another time.
The Weapon Attacks
To put it bluntly, the weapon attacks looked like arse. I’d tried to take them down the route of the Halo weapon bashes with impact in the middle of the screen, but this clearly wasn’t the way to go for a sword-slash vibe. I went back into Maya and quickly redid all animations for each attack, bringing each of them all across the screen in a quick slash. Of course, things can’t be too easy – I’d forgotten that I’d set the animation layer for the attacks in Maya to 50%, and had to manually tweak the keyframes in the graph editor to work again after resetting the layer to 100%. Still, it’s all (almost) as good as new.
Switching Modes
Turns out that swapping between different anim blueprints is super-easy, at least on the technical side of things. I did a quick Google search and found a very simple layout in Blueprint that worked exactly as needed, and from there I tied it to button presses. Spawning and removing the sword was a bit trickier, but a simple Youtube tutorial later, and I’d gotten the idea.
The next step was tying the animation-blueprint-switching into the animations, and this took a wee bit more work. Getting the controls together was its own task, and even after that, I had to do a couple iterations for setting up the anim montages correctly, to flow into each other correctly as the modes switched. One thing I was constantly keeping in mind was, “if the animation was interrupted, which mode would the player expect to be in? At which point will the player expect the mode to have switched?” This would dictate the exact point when the blueprints would switch from weapon mode and mage mode, and vice versa – and because the animation blueprints were changing at that point, the animations would have to end and start at those points as well. Put all together, this meant that certain sections that had been animated as one continuous performance would have to be split up between two montages.
Still, it paid off! It’s rough, but the Sword Summon to return to Weapon Mode (and, to a lesser extent, the Sword Throw to enter Mage Mode) are not just functional, but displaying the first signs of being genuinely rad! These two paired events have been hovering in my mind as the “moments of awesome” in the gameplay, and it looks like I’m barking up the right tree here. It’s always a huge relief when all the work pays off, and lets you know via a jolt of pure, distilled “fun”.
Next Steps
Over the next two weeks, I’ve got two goals: get the Sword Throw action to actually throw the Sword, and begin to refine the animations to sand down the roughest edges.
The first is key – learning how to cast a ray, get the impact point, and send a projectile or other effect towards that specific point is core to setting up a lot of gameplay across any genre, and will have a lot of applications with the lightning bolts in Mage Mode.
The second is where the point of this whole project will come into focus – to show not just that I can implement animation into gameplay, but that the animation I can make for gameplay implementation is good. After all what’s the point in a gameplay animator that can’t make quality gameplay animation?
Comments