Log 31: Adding New Characters and Swapping Between Them

I'm now more or less done on things that don't require multiple characters, so it's time to create some new ones. Or at least one extra.

The first thing I did was purchase a couple of extra animation packs, one for the character's own weapon, and one for unarmed attacks and movements. Then I made a couple of new characters as children of the Playable Character Blueprint: one, the Red Knight, was basically the same as the Playable Character base class with a different Material Parameter Collection, and animations, while the other, the Blue Knight required those new animation packs, new materials, a new MPC, and even additions to its weapon summoning to include its shield.

And then...I deleted them both. I wasn't just deleting my art, but I had realized I missed multiple materials, animation montages, and various other variables that needed changing and thus: nothing worked. I realized that there were too many points of potential failure and when I, eventually, make more Knights I would just have all the same problems. So I decided to simplify things. Specifically, I did some research on some material optimization techniques and found out about Custom Primitive Data. Custom Primitive Data allows different models to use the same materials but provide different render data, such as colors. I figured I could use this for, not only, colors but also the different pieces of data necessary for my dissolve/appear effects. With this I was able to delete several, now unnecessary, variables.

Even after all this, and double checking that I hadn't missed anything, morphing still wasn't working. The different planes and the camera were all moving correctly, without pausing like they should, and the character got stuck in a waiting animation. Eventually I discovered that on creating child blueprints event calls in actor sequences get completely unbound and have to be redone. Which is MUCH better than having to completely redo the actor sequences from the ground up for each character, which is what I was originally afraid of.

Finally, I got two fully functional and independent characters: the Red and Blue Knights.

Here they are...again. Only this time everything works and they don't only look it.

Now, with two playable characters in the game, I needed some way for the player to switch control between them. I needed some kind of manager singleton outside of the characters that could keep track of them all, as well as what character is currently being controlled. I chose my custom Game State Blueprint for the task. While I could have also chosen the Game Instance Blueprint, I don't need the currently controlled character to be known between level changes. It was actually fairly easy: Create a component on the playable characters that gets in contact with the Game State and registers the character. Then, when the player presses one of the cycle character buttons the Player Controller contacts the Game State and gets the new character to posses. The only hard part was how to switch the control if the character is mounted. I just had to create an ISwitchable interface that returns the "Active Pawn" for a given character (the mount blueprint if mounted and the actual character blueprint if not).

Switching control like it's nobody's business

The final thing I had to do was create HUD elements for the potentially-controllable-but-not-currently-controlled characters. It needed to consist of three (or five, depending on how one counts them) elements: A health bar, Power bar(s), and some quick visual way to tell what character the bars represented. So I roughly mocked this up:

I figured putting everything into a single circle would keep the information compact enough that I could fit multiple of them on screen at a time but still be readable, especially with the character portraits in the center. That, of course, led me back down the rabbit hole of "differently shaped progress bars" that I had gone on to create the Kingdom Hearts style health bar used for the controlled character. I eventually re-found the video I had been looking for: Unreal Concepts - Dynamic Circular Progress Bars ( UE4 ) by Mathew Wadstein Tutorials. Thankfully, the video lays out all the basics necessary to easily create the health bar, and then I just had to do a bit of math to break up the Power bar into segments. For the character portraits, I created a Screen Capture 2D camera in the Playable Character Blueprint that I could angle how I wanted it to get a picture of each character in their idle poses (I would eventually have to delete the screen capture as it causes massive slow down when running the game as an executable). I then brought a screen capture of the texture into an art processing program (GIMP) and used a layer mask to "fit" the character into the circle (you see what I mean):

I discovered one bug and another "bug" while testing: The first is animation snapping on the Blue Knight's dodge animation montage (a simple root motion check box fixed that), the second is that the player can dodge even when holding down the guard button.

I decided to keep the "dodge-while-guarding" in as a feature instead of a bug (hence the previous quotation marks). The only problem was that while guarding the character strafes in their movement direction so only having a forward dodge roll didn't look great. In order to keep things organized I created a Dodge Component that keeps track of the player's velocity and movement direction and based on that returns a specific directional animation montage. Whilst I was testing this I found that if the player dodges before an attack finishes all the way they can get locked out of being able to attack again. To fix this I added a simple check on the Attack Controller's [Is Attacking] variable before allowing the character to dodge. While dodge cancelling is a useful mechanic, figuring it out was out of scope and I needed to draw a line somewhere.

Next time I'll write about how I fixed up Group Morphing, it is becoming much more involved than I had originally thought it would.