Fixed a Snapping bug with First person camera. Because we were switching from using the Controller and driving the camera by animations, this caused a weird snapping issue right when you switch from a cool jump animation to running on the ground. This fix was very tricky and I finally figured out to lerp from a snapped value to the center of the screen very quickly after a land.
One of request we had from the player community was to add FOV slider. I created the internal logic with tunable values and Abhishek hooked up the new UI for it. Soon to be released in Patch 2.
This is probably my last blog post here. I really enjoyed working on our game. We were a great team and our professors always supported us in our decisions and a great program. During the course of these 4 semesters I have developed a great portfolio, built great relationships, developed a great game, published it on steam that had several newspaper mentions in my home country, got an internship at Sony Playstation, then got another internship at Disney Interactive and finally got a full time job at Apple, my university program had everything to do with every great thing that has happened to me.
Going further I will certainly miss working with my amazing team and on Games!
Prediction in the Animation system helped a lot to realize the implementation of the Roll Animation. Most of the logic from MyCharacter made by Tony had to be moved to Animation System. There were a couple of challenges that I ran into while implementing it but eventually it worked and looks great!
Roll also gave the player a small boost and increased the Bandwidth meter.
Next task was to give the ability for our Designers to be able to specify which jump animation the player character plays after being launched from the Jump Area. An obvious choice was to make the Jump decals as triggers that specify which jump animation to be used in animation system.
Created a list of Enums that named the animations.
Hooked up the Animation name list into the Launch decals so that each instance of the decal could specify the animation.
Hooked up the Launch to Player Character to store the next Launch Animation.
Animation system now read this variable and decides which animation to play during run time. Used blend by ENUM to achieve this functionality.
As you can see above there were several animations that could be switched based on the run-time variable Animation Selector. Animation selector was indirectly driven by the Launch Decal instance. If no animation enum is specified, default jump start is played.
FP Camera, up until now, has no intelligence. There are a couple of limitations as to what it can do and certain animations still clips through the camera when playing. If the player looks up in TP and switches to FP the rotation gets messy and does not allow the player to look around. The reason being that the FP camera is not driven by the Player Controller rather driver by the player rotation.
Why did we make the FP camera to not derive its rotation from the Player Controller?
Because some of the cool jump animations that we had planned to bring to the game had BackFlips and FrontRolls in the air and the camera had to be driven by the animations in these cases. Because of the lack of support from UE4 I had to take away the FP camera controlled by the controller.
How is this solved now?
One of the ideas me and Kyle had was to create a separate blend space for the First person with a different set of animations that didn’t have the head bobbing and rotation which clipped through the camera in first place. For this, I have created a blend between blend spaces!
I have also turned back the ability for the camera to be driven by the controller on and made the FP camera playable when the player is moving on the ground. While jumping the Camera is still made to be driven by animation.
There were still problems with this (Where a regular jump locks the camera to the animation head). I had a discussion with Ryan the other day which motivated me further to look into making FP camera better. One of the things that I tried and worked great was to not drive the camera based on the animation when playing a regular jump. All other times the camera is driven by the animations, example during the roll and when the player is launched into the air for parkour animations.
This fix looks very simple, but this was made possible by some of the blueprint decisions that I had taken earlier which gave me the flexibility now to use the readily available data at hand to decide the fix. Look at how the camera is driven by the Animations! I am so glad I got this done before the release…
I have always wanted to improve the animation system that we have currently. It has some logic currently to handle the Long and Short fall and uses blend spaces to smoothly lerp between different set of locomotion states. This First thing necessary is the ability to predict next player state by raycasting towards the ground. This solved the player looks like sliding for a short frame when falls to the ground and made it a seamless transition.
There is a Max offset for the ray cast and a min threshold. As soon as the ray cast distance is longer than the threshold and the player Y velocity is greater, the player is in air and vice versa. This helps the animation system know when the player is closer to the ground and start playing the landing animation mid air.
I have prototyped charged shot. It currently does not have any visual feedback except for the fact that all the Inhibitors that fall inside its radius are destroyed and the slow lanes that these inhibitors once projected are now converted to fast lanes.
We did hook up the particle burst that we had from previous Ping. It works nice, but certainly needs playtesting to be able to decide how we should fit this in our current game.
Player Decal State Stack:
There was another interesting challenge that we worked together and fixed. Since we have decals now, we wanted the designers to give the ability to overlap the decals and have the priority set that defines which decal must be visible when overlapped and affect the player. Let’s say there was a fast lane (decal) and a slow lane on top of it, the player is currently is on the fast lane and enters the slow lane. The speed of the player should be reduced and the pixelization had to kick in. The problem was that the decals are volumes and existence of both in the same space had to be handled differently so that the Fast and Slow aren’t conflicting with each other. I came up with the proposal to using Stack to store the OnEnterDecal type and OnExitDecal type. Every time the state changes the top of the stack is set to the player and the player speed is determined by this state.
We have decided to modify the Field of View of the player with the player speed. This gives our runner game the sense of the race games where the FOV increases with the speed. I coded a tunable Lerp for FOV with a Min and Max that adjusted its value based on Player speed.
Finally, we are at a point where we want to majorly shift towards the third person camera. The animations are currently only dependent on the Player speed and not the direction. Look at the blend space below.
Now we want to consider the direction that player is trying to move when on the ground and create a 2D blend space instead of 1D. Kyle, as always, gave me some more neat animations that I used to hook up the Blend space based on direction and Speed of the player. Below is how the blend space looks and you can see the resulting animation that is played,
The X axis represents the direction that lerps from -180 to 180 degrees and The Y axis represents the speed. Both of these determines the animation that plays.