next »

[Eniko]

So, here's the issue. I finished the animation for my sprite, and for the time being I've kept the torso at the (0,0) point, so the character's hitbox will always line up where where the torso is, visually. The problem is, the animation involves a staggered set of steps forward:



So the feet are now doing a slip and slide. My initial idea was that I would just move all characters using game logic, never anything controlled by animation, but it seemed like that would be very difficult here. Certainly a fixed forward momentum during the animation looks all sorts of wrong here.

I do have a sprite renderer utility I use to get my 2D sprite sheets, so what I could do is add code to track the topmost parent bone which moves the entire rig around. That way I can figure out velocities to set frame-by-frame. Part of me is loathe to do this, letting the animation dictate logic rather than the other way around just seems... wrong, to me.

Not sure how to proceed here. Has anyone dealt with this issue before?

[moi]

what language/engine are you using?
If you're doing your own engine, it would be a good idea to include callbacks at frame changes (like when a sprite reaches a new frame it can call a function passing the sprite ref and frame number as argument, that function will if necessary do stuff like movements or particles or hit detection or whatever)
Or more simple you could add timed movement using some sort of timer

[Eniko]

C#, completely custom engine. So yeah, I can definitely do callbacks on certain frames. I can even have the frames hold information about how far to move the character. I'm just not sure if I really should.

I suppose it would work well for attacking. But I'd have to skip it on something like a jumping animation, because you want to control the height and arc of the jump yourself. And then you have two separate systems of animating and logic and that just seems... unclean to me.

[Raptor85]

you could also just make the "image" bigger (blank space around the sprite) and when you're animating actually move the frames to where they should be within the image

[BorisTheBrave]

I gather the common way to handle this is store per-frame info about where the zero-point is, and then you draw each sprite such that the zero-point is always in the same place, the actual game logic position of the character (this is similar to storing per-frame movements, but simpler in a lot of ways). So for animations like your slash one, the zero-point can jump around, while the game engine does nothing with the "real position". But for jumping and walking animations, you might chose to keep the zero-point fixed on the torso, but and have the game engine move the real position.

I have heard though, for people who are truly keen to make sure that feet stay put on the ground, that they don't move the real position for walking, preferring to handle all tracking in the animation and zero-point. Only when the animation loops to the beginning do they apply any change to the real position.

[ThemsAllTook]

My initial idea was that I would just move all characters using game logic, never anything controlled by animation, but it seemed like that would be very difficult here.

I'd think of it like this: Your animation contains data that relates to both visuals and game logic. Your renderer would deal with switching between sprite frames, but not do anything with logical movement; your game logic would do the movement, and not worry about sprite frames. So, in addition to the sequence of images, your animation would have a list of per-frame offsets that would get applied to the character's position by your simulation code. Assuming both the simulation and the visuals have a consistent concept of fixed-length frames, you can run the two independently using their respective data sets and everything will line up appropriately.

Edit: Exactly what BorisTheBrave said while I was typing!

[Ludophonic]

I do have a sprite renderer utility I use to get my 2D sprite sheets, so what I could do is add code to track the topmost parent bone which moves the entire rig around. That way I can figure out velocities to set frame-by-frame. Part of me is loathe to do this, letting the animation dictate logic rather than the other way around just seems... wrong, to me.

Not sure how to proceed here. Has anyone dealt with this issue before?

I've done this before although in full 3D. What you describe - keeping per-frame displacements - is the way to do it. Make sure your topmost bone isn't something like the pelvis otherwise you'll have your character changing position when shifting it's weight during an idle. We usually put the root bone at the characters feet. This also allows you to keep the translation at a constant velocity while the rest of the skeleton can move back and forth. Good for keeping camera tracking smooth if you're focused on the character.

Don't try and do it with the zero-point method Boris describes, it's extremely fragile. To see why try and imagine what happens when you walk into a wall half way through your cycle.