Sign in to follow this  
zuhane

Managing multiple complex sprite sheet animations

Recommended Posts

Hello again. If I could get some help regarding the following, that would be awesome! I'm most familiar with C# and XNA just for

the record, but a pseudo-explanation/pseudo-code example would also be really helpful.

 

So I'm basically working on a simple 2D platformer, but the player has a huge arsenal of poses and actions that he can perform.

I've been using a workaround sprite sheet animation class at the moment which essentially cycles through different strips of

the main sprite sheet. The problem is that some of the poses are different widths and heights, animation speeds, lengths, etc,

and managing the whole thing is becoming a bit of a mess.

 

I recently switched to Aseprite studio, which is absolutely incredible btw, and it makes it unbelievably easy to generate tightly packed

animation strips with the smallest margins possible, obviously resulting in less memory requirement from the game at run time. I'd essentially

be like to create a simple game that prides itself on smooth animation (as I'm more of an artist/animator than a programmer), but the way

they're currently managed is just this awful nest of ifs and switches.

 

Are there industry standard practices in approaching sprite sheet animation? I'm currently looking at using state machines to avoid nasty

overlaps of animation and to also allow transitions between them.

 

There's also the issue of storing animations. Is it standard practice to make animations become instantiated objects in some way, so that they can be played and changed seamlessly, or would coders conventionally just alter the X and Y positions and frame numbers manually?

 

Help would be super appreciated!

Share this post


Link to post
Share on other sites

From your description, I'd say you need a table with offset and sizes (known as 'data driven' coding iirc).

 

Pick a convenient point of your hero, for example, center of his body (hips), vertically down until you hit the floor.

That's where the character "is". Let's call it (cx, cy). Other points will work too, but at the ground is probably useful (easy for positioning).

 

Now, the starting point of drawing (normally the (top,left)) is often not at (cx, cy) :p

To solve that, you have an (x_offset, y_offset) pair for each sprite. You should define what sign it has, I see mostly

left = cx + x_offset
top = cy + y_offset

So you take the center point at the floor, add, the x and y offset, and you arrive at the pixel to start drawing.

 

Now if you obtain the (x_offset, y_offset) for each sprite, and you animate the images after each other, the character moon shuffles perfectly. To move forward (or backward, or up or down), each new sprite adds (mx, my) to (cx, cy) for the next image. In other words, with a sprite you move the center point for the next sprite by (mx, my), which means you draw the character at a different spot. If you set (mx, my) correctly, the character will move naturally.

 

you can add other fields too, eg display time of an image, x/y/width/height at the sprite sheet, other images you can draw next, and so on.

 

You end up with a table with numbers, one line for each sprite.

The code will simplify a lot, since the numbers tell the code what to do. You don't have to hardcode everything in C# statements (just insert the table into it :p ).

 

There's also the issue of storing animations. Is it standard practice to make animations become instantiated objects in some way, so that they can be played and changed seamlessly, or would coders conventionally just alter the X and Y positions and frame numbers manually?
I don't know how you made the sprites, but what I found very convenient as programmer is to have that special (cx, cy) point at exactly the same pixel in each sprite. If you have that, you can write a program to clip away the excess rows and columns of pixels, while tracking the changes to (x_offset, y_offset). For example, if I clip a columns at the left side of the character, decrease x_offset by one.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this