top of page
Search

Log 29: More Legwork on the Mounts

  • Writer: Kassandra McCormack
    Kassandra McCormack
  • Apr 29
  • 6 min read

For this past stretch of my game I decided to work on the mounts and mount system; It wasn't nearly as complete as I would have liked, and there were some bugs that came up in other testing.


That being said, the first thing I worked on was a bit of UI user experience: Updating the Empower Menu for when the mount is summoned. I found out that when I set it up the first time, I forgot to hook up the UI call with the character's mounted state so this was easy.

Just crossed out to show cancelling the summon.
Just crossed out to show cancelling the summon.

The next thing I did was get rid of the Rideable interface and use soft references between the player character and the mount. I did this because at no time would they not be held in memory at the same time, so the interfaces aren't really saving me any memory space, and in fact may be adding to it (if only marginally). Plus there were still a few points where I had to cast between the two anyway so now I could get rid of that all together. On the player character's side I added a Summon Mount Component that I could add all the code dealing with the mount to, and for the mount...it honestly doesn't have components and everything is in the main blueprint. I know that's not exactly best practice, but most of the function calls from the mount were just immediately passing them on to the character anyway so there wasn't much for components to do.


After that I was playing around with the collision code between the character and the mount. Originally I was using [Set Actor Enable Collision] set to false to turn off all collision on the character, this came with the downside that now the character couldn't collide with things like pickups or bases. Then I found [Ignore Actor When Moving] which would accomplish more or less the same thing (no collision between the character and the mount), but leave the character's collisions enabled so they could pick stuff up or enter bases. This...created an interesting problem: For some reason the character could be pushed out of alignment from the mount.

The character is attached, but still being pushed around out of alignment.
The character is attached, but still being pushed around out of alignment.

Obviously I couldn't use this then, since keeping the character aligned properly is paramount and I couldn't find a way to force it. But I could get around its collisions being disabled. All I would have to do is put the same kind of colliders on the mount and when those get overlapped or otherwise collided with, pass the reference on to the character and the code I had already written would take care of it.


For the mount summoning VFX I moved the materials and particles over to Parameter Collections, mostly so I wouldn't have to keep as many material instances in memory at the same time. I'll have to create a new set of parameters for each mount, but there are only going to be six at most, I can handle that.


I had to fiddle with the unsummoning of the mount a little bit. I found that if the character's collision gets enabled before disabling the mount's collision it can mess with the Enter/Exit functions on the bases. The character gets removed when the mount's collision gets disabled and then gets added back in when the character's collision gets enabled. Because I use [Add Unique] for the array tracking characters in the bases if I do it the opposite way the character will not get a duplicate added and then just get entirely removed.


A fun little bug that I found during testing was that if the player summons the mount while in the air, it just straight up deletes the character.

ree

It took far more testing, but I discovered that what was happening was the character was falling through the floor and almost immediately being deleted. It took quite a bit of fiddling with gravity controls to find the correct setting, but I found that setting the character's gravity scale to zero stopped them from falling through the floor (of course I then had to remember to reset it from zero when they dismounted).


Setting up the animations for the character while mounted took some creative work on my end. The first thing I needed to do was change how the AnimBlueprint gets the character's velocity, because while mounted I want to use the mount's velocity instead of the characters (which would read as zero). Really, when I lay it out like that it sounds easy and obvious, but it took me a bit to get my head around it. Of course doing this was just setting up for possible future needs because the motorcycle riding animation pack I bought only had an idle animation to play for actual riding. But, in future both when I make animations for the motorcycle riding characters and use other animation packs for the horse riding characters I'll be glad I set this up.


Of course, Synty has some weird proportions on some of their assets, so I had to learn to do IK corrections on the animation so the characters feet and hands, mostly, line up with the footrests and handlebars.

Feet and hands are out of position in the vanilla animation.
Feet and hands are out of position in the vanilla animation.
Using IK correction to mostly fix the positions.
Using IK correction to mostly fix the positions.

The next thing I tackled was setting up the Animation Blueprint so that the character could hold their weapon (and attack with it) while riding their mount. Unfortunately, because of the way blending per bone doesn't have easing, it was causing snapping between holding the weapon and holding the handlebars.

ree

Eventually I figured out I could set up the IK for the right arm in a different state inside the same state machine and get much smoother transitions.

ree

For attacking while on the mount I decided to leave it open ended. For empowered attacks, I built it so the character attacks with their weapon, but for un-empowered attacks it will depend on if they are on a motorcycle or a horse. On a motorcycle I'm thinking giving them a weak gun for their X-attack and make a fancy attack WITH the motorcycle for the Y-attack, while both attacks will be from the horse for those mounts. In order to facilitate these in the future I made overridable functions that, at present, are empty but can be filled in when I make the actual usable mounts instead of what will become an abstract class.


I did have a fun bug, because the mount didn't have a faction controller on it, when the character swung their weapon they would damage themselves, so I had to put one on the mount.


Instead of an Ultimate Attack, when on a mount I want the character to do a high speed dash. The why is mostly that that's what happens in Warriors games with mounts, and I didn't have anything else to do with the button combination. I used a Niagara system that I purchased from the Fab asset store (Sci-fi and magic FX pack vol. 2 by Grimza). Then I made a macro to hold the dash functionality since I would need to use the [Add Force] node over a set amount of time. It was a good time to re-use my [Fake Timeline] macro since actual Timelines can't be used outside of the Event Graph. It wound up being fairly easy. Eventually when I start making mount animations I want to add a wheely/rev-up animation for when the dash is used from a dead stop.

ree

The last mechanic I worked on is that if the character takes too much damage in too short of a time they are forcibly dismounted. In order to do this I went into the damage algorithm and created an On Stagger and an On Guard Break dispatcher, then I bound the dismount event to those dispatchers.


With all this work on the mount, one would expect several bugs to appear, but I only found one during playtesting: Every time the player dismounted they left behind an extra POI icon on the minimap. It turns out that because of the way mounting works I possess the mount and then possess the player character when dismounting, and every time the character gets possessed they re-add the HUD to the viewport and that also calls a dispatcher that adds a new POI icon. In order to prevent this from happening, not only did I do a check for if the HUD is already in the viewport, but I also check the minimaps: If they already have a reference to the POI Component on the player then they don't spawn a new icon. I did redundant checks because eventually I'm going to have character switching between playable characters and I don't want that creating extra icons either.


Next post will start with some other, non-mount related bug fixes and then I'm getting started on building the enemy AI.

 
 
 

תגובות


bottom of page