Continued fixing and improving the things I learned from the play test, starting off with the heal today. I figured out awhile back that it should be important that inputs/actions should not be spammable unless you need or want them to be. Spamming an action can cause a lot of bugs especially with unexpected behavior from being cut off in a specific flow. Anyway I had forgotten to spam-proof the heal so I made sure that it is blocked from being used until the heal is done or interrupted.
Adjusted the damage dealt to objects when they are moved about, making sure that it breaks eventually but not too fast. Updated the logic on the characters so that when they are stunned they stay stunned for the duration, previously the hit montages would interrupt it since the nature of montages is to play over anything that is on the mesh. It is basically an animation that always takes top priority unless you change any logic to make it think differently. Montages are my best friend. Simple and easy to use. Just add notify markers on the animations to make it do what you want at the right time.
There was a problem with the whip hanging about in the air for too long when attached to nothing, changed the delay so it would detach quicker without looking weird. It is probably a forgivable thing even if I left it in-game, but it bothered me so voila. While playing it seemed that the state of the level didn’t consistently save, doors that were supposed to be open were closed, torches that were meant to be lit were dead, etc. I bound an event to saving game and dying so that the state of the level also gets saved. This seemed to work as previously I only had the level save its data when torches were lit, objects destroyed, etc. But due to that logic it didn’t always carry over. I’m hoping this will fix the issue, and so far it works perfectly.
When changing directions while sprinting the sprint would end because the logic I had would stop a sprint whenever there was no movement, but to change directions while sprinting would cause the character to stop because of the turning. To remedy this I put another check for movement in between a delay node to give time to the player to turn, works as intended.
Onto the animations I noticed that it was harder to hit with one of the attacks because it didn’t move the character forward like the other three attacks. This was because I had an issue moving the root forward because I had turned it for the animation. Anyway, I replaced the attack with a much better looking animation and made sure to change a few of the rotations of the bones so that it could hit consistently. It fits well with the other attacks and I added a bit more speed as well to the animations. It’s a sword made of light after all, it shouldn’t be particularly heavy.
Updated the healing animation so it made more sense and it healed at the right time. I went back and forth with the animation of few times. Couldn’t decide where I wanted the arms to be, but eventually I found the right place. Added a notify to the animation so that the heal takes place while the hand is in the air instead of when the montage ends.
The highlighting of certain items was too strict sometimes so I added a delay to give leniency to the players looking away. And then I encountered the hardest issue of the day which was the rotation of the camera. Whenever the player was right beside the target they had locked-on to, the camera would spin wildly if the target was stationary. Can’t say for sure exactly why, even up to now. I tried many solutions from stopping the rotations at certain distances, clamping the rates of rotation, checking the rotation of the controller and matching it to the camera to try and stop it. The best solution I came up with so far was to slow down the rate at which the camera turned. The issue only pops up with stationary characters, and if the target is rather small too I believe. I will try and find a better solution eventually if I can.
Changed the material of the dummy to make it appear as if it was made of light. Did a few test runs of the level and no big glitches so far, and added an extra effect to the boss when he is defeated. I do really want to continue working on the next level, and expand it as much as possible, but I want to continue building on the skeleton/foundation of the game. This includes mapping the inputs to images, so that later on the controls can be changed to whatever the player wants. And then adding more options as well such as audio, graphics, etc. Developing the rest of the levels can wait for now.
GoldenGratus Games 