Blugh, I'm having a hard time figuring out how to coordinate sprite and position animations in #unity.
If I want my character to move forward a step on a certain keyframe, is there an easy way to animate that?
You'd think animate properties could do it, but it just sets the sprite's absolute position, which doesn't work for things like characters which need to move a relative position.
I think Sprites still use the animation system in unity, right?
If so, you should be able to add animation events:
The only concern I have is it might occasionally be off by a frame, depending on how it's implemented.
(Although even if you can't get it to be perfect in the animation side, you would still have a few other options.)
Also, now that I think about it, couldn't you make a animation property for "speed" and just have the character controller read that somehow?
@SciFiGameDev Good suggestions!
I'm familiar with animation properties for my hit detection colliders, but they're absolute values. Animating transform.position snaps back to the starting position of the next animation, but I want my character to retain the change additively with their starting position. Am I missing another way to use them?
@SciFiGameDev For a speed property, that certainly fits Unity better, but it's harder to visualize for the designer. E.g., if we determine that for gameplay balance an attack should reach 2 units by frame 18, speed doesn't show exactly where a character will be in a given frame.
Your suggestion will definitely get the job done if I iterate on speed by feel, but I'm lazy and bad! Is there a way of implementing that can map directly to design values?
I think the most intuitive way is going to be to map to transform.position for the convenience of the designer and make it so the end of the animation clip has an animation event that adds the total distance moved (i.e. keyframe[size-1].transform_position - keyframe.transform_position).
The combination solution could be a little tough to implement, but it's probably convenient enough to be worth it (I'd hope).
@SciFiGameDev What happens if the character gets hit in the middle of moving and interrupts that animation to play the hurt animation? Will the animator controller skip over the event at the end that would have added the position displacement to the transform?
@SciFiGameDev Wait, I just unchecked and rechecked "Apply Root Motion", and now it's fine???
Unity is such a mystery sometimes.
That's a first XD
Usually the Unity bugs I deal with are less confusing than that.
Might've had to do with hot reloading / the importer or something.
(Hot reloading has been glitchy for me while coding in Visual Studio, of late.)
It might be a problem depending on the specifics.
I guess my main concern about using transform.position is the animation properties is that I've seldom heard of animations controlling the position of the root GameObject (usually it's a child GameObject); also, scripts and physics are often supposed to control positions.
Another aspect: generally sprites are supposed to be fixed at a center-of-mass location and not drift over time (which might be relevant with e.g. a jump sprite).
@SciFiGameDev Wouldn't the center of mass position remain unchanged with changing the root transform?
Or am I misunderstanding?
The center-of-mass issue would be from the art assets themselves.
E.g. An animator gives you a jump animation and the code just blindly assumes the center of mass is the same as the idle animation. (Which might create a weird transition between the two.)
Generally all of the sprite sheets should have a consistent center of mass unless there's a good reason not to do so (disclaimer: not a technical artist or even an artist).
Upon thinking about it further, it seems like one of these could be the underlying problem that makes it feel like bad practice:
1) either you need to create a sub-object that is controlled instead of changing the main GameObject
2) a looping animation asset (or animation transition) has a sudden shift in the center-of-mass, creating a jarring effect.
@SciFiGameDev For 1, I didn't like the idea of an empty parent either. Luckily, I'm able to change the transform of the parent now, though I'm not sure why it spontaneously started working.
For 2, even if you controlled movement strictly by script, that would still be a problem either way, right?
Usually for case 1 it would look like this:
Core physics of player on root game object
Childed GameObject that has a relative position; is more than an empty object
Has most of the attached renderers (notable exceptions: blob shadow projectors, etc)
Likely has attached hitboxes and hurtboxes (but not physics-related colliders).
You're spot on for case 2: it's always a problem regardless of your code (unless you really go out of your way).
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!