koobas.hobune.stream
Animation Lag when Changing Movement Direction 2D (4.3)
I'm currently trying to build a script to handle the players movement for a 2d top-down rpg. The animation is fine for all directions, as well as moving idle.
The problem I'm having is when holding the left arrow to move left, then switching to down, the character will start to move down, but the animation is still running to the left for half a second to a second. This only happens generally when moving left or right, and attempting to then go north and south.
For a simplified script :
public class playerController : MonoBehaviour
{
private Animator animator;
// Use this for initialization
void Start()
{
animator = this.GetComponent<Animator>();
}
// Update is called once per frame
void Update()
{
var vertical = Input.GetAxis("Vertical");
var horizontal = Input.GetAxis("Horizontal");
if (vertical > 0)
{
animator.SetInteger("Direction", 2);
}
else if (vertical < 0)
{
animator.SetInteger("Direction", 0);
}
else if (horizontal > 0)
{
animator.SetInteger("Direction", 1);
}
else if (horizontal < 0)
{
animator.SetInteger("Direction", 3);
}
}
}
Basically, is there any way to force an animation switch? I tried speeding up the animation, which did not correct the issue. Also, I tried to lower the time in the transition, which had no effect. To give an overall idea, if I hold up for a second, then left for a second, and keep going back and forth, the player will never face left, but will continue to move up then left, etc. Thanks!
Note: This is for a Unity 2D project from 4.3, with a Fire Emblem, GBA Zelda type view.
To anyone that has this trouble themselves, the problem is the "input gravity" for 2d characters, which is defined as "Speed (in units/second) that the output value falls towards neutral when device at rest". The character is still walking ever so slightly in the previous direction, forcing them not to change animations until the other direction eventually comes to a complete stop.
To solve this, go to the edit -> project settings -> input, and adjust the horizontal and vertical axes gravity values. By having a higher input gravity, the time between letting the button go and coming to a complete stop will decrease.
Note this is not the same as a physics gravity, and is intended in decreasing the time between key release of a direction, and the stopping of your character.
Why just the down vote with no explanation of why? Would it have been better if I didn't post the answer to my problem?
I think the answer you've posted, while it may work, isn't a "Best Practice" solution. If it's just a switch, I'd suggest always having the character moving "forward", and simply change the rotation in code.
Interesting, I've read your answer but cant see why using hard code switches is better then the animator? Whats the problem with one vs the other. And why is code switches best practice? The 2d example by unity uses the animator approach albeit without the need of vertical movement, thus avoiding gravity. Thanks! :D
Personally, having to adjust the gravity for this seems to be a difficult way to solve the problem.
I'm imaging the original zelda, top-down, but that you're doing it in a 3d world, correct? I suppose that's what i got from "Top Down 2D", since Unity's 2D stuff is made for side-scrolling.
If I'm wrong, then I guess adjusting gravity would be your solution.
But if it's top-down (like literally camera is pointing down) in a 3D world, then just adjusting the direction the character is facing and always moving "forward" seems far more elegant.
No, I am not building it in a 3D world. Its just using simple 2D sprites. You can still use the 2D part of Unity for RPG-esq games, I'm unsure why it would only be for side-scrolling. The character is made from a spritesheet, thus making "always" forward, much more difficult, since he can not properly turn. I can update my question with that
Sorry I should have noted that I'm not talking about gravity as physical gravity, but rather your "input gravity," which handles you input variables decent from moving to stop.
The exact definition being: "Speed (in units/second)that the output value falls towards neutral when device is at rest." Output being the speed value in my specified direction. Since this is a 2d style re$$anonymous$$iscent of gba zelda, or fire emblem, my vertical input is movement directions (a and s), and not "jumping", which unity has already mapped to, and assigned an "input gravity" to. So when my device is at rest (ie : the key press) the character will come to a complete stop sooner.
I'll correct that in my answer. But these variables are meant for this specific reason, and is not "gravity" as in falling speed from a jump.
Thanks sfbaystudios! :)
Have you thought about simply changing the "forward" direction of the player? Instead of using the directions in the Animator, simply have the player move "Forward" if any button is pressed, and change the direction the player if facing when the button pressed is different than their current rotation.
From the script it looks like there's no smooth turn, just an old-school zelda-style "switch" to the new direction. If so, then using code to change the rotation, and having the player move forward regardless of where they're facing, would be easier, I'd bet.
