next »

[Noogai03]

Hi there, I'm trying to make a little zelda-style game using sprites from Minish Cap (cos theyre absolutely gorgeous :D) but I've run into a problem with sprite animation.

I found a bunch of sprite rips, for example here, and I've tried to extract the relevant strips of animations. For example, the walk animations are 10 frames long and it's relatively easy to piece them together into a chain and have the source frame loop over them - I wrote a little program to generate lists of frames for each frame and store them in a JSON file, which is then loaded by my program. I'm having an absolute nightmare getting the animations so they don't jerk around but I'm not really sure how to fix this. It's bad enough with the forwards walking sprites because all I have to worry about is getting the up and down motion correct, but I'm totally hamstrung on the sideways sprites because of one thing: the sprites don't all have the same width. Because of Link's hat bouncing up and down, some of his sprites are quite a bit wider than other ones.

I've tried to think about this in terms of giving each frame an offset, but that seems like a nightmare without any kind of editor...

Any help?

EDIT: I'm also worried about how I'm going to find tilesets, because spriters-resource only gives pictures of a whole area like this instead of tilesets I can actually use...

[BorisTheBrave]

Because of Link's hat bouncing up and down

Generally, it's easier if you draw a slightly larger rectangle around each sprite, so you can keep the rectangle the same each frame and not worry about offsets. Not all spritesheets are designed with this in mind, but your example one is - notice how each of the sprites is in a grid and lines up with the ones on each 4 sides (in many places, at least). That's because they are each being given the same amount of transparent padding.

That said, you can find many tilesheet editors on the web. They let you deal with per-frame offests (which are often necessary due to walk cycles anyway). There are also tools that will extract tilesets from area shots.

[Noogai03]

Because of Link's hat bouncing up and down

Generally, it's easier if you draw a slightly larger rectangle around each sprite, so you can keep the rectangle the same each frame and not worry about offsets. Not all spritesheets are designed with this in mind, but your example one is - notice how each of the sprites is in a grid and lines up with the ones on each 4 sides (in many places, at least). That's because they are each being given the same amount of transparent padding.

That said, you can find many tilesheet editors on the web. They let you deal with per-frame offests (which are often necessary due to walk cycles anyway). There are also tools that will extract tilesets from area shots.

The problem I'm having is that the sprites aren't arranged in a proper layout - they're just positioned roughly on a blank canvas. Having quite a lot of trouble really arranging them. I'm thinking that probably the best thing to think about is to get a point on the sprite (eye, for example) and keep that the same distance from the left edge of the canvas each time.

[oahda]

Use something like GIMP, put them all on layers on top of each other and align them perfectly, cutting the layers to image size. Then put them on a grid with each tile the size of one of these layers. Trying to place them side by side directly isn't likely to work out that well.

Lots of work, yes, but it will turn out nicely. :3

[Noogai03]

Use something like GIMP, put them all on layers on top of each other and align them perfectly, cutting the layers to image size. Then put them on a grid with each tile the size of one of these layers. Trying to place them side by side directly isn't likely to work out that well.

Lots of work, yes, but it will turn out nicely. :3

That's a really good idea, thanks hadn't thought of something that simple...

[Sqorgar]

The problem I'm having is that the sprites aren't arranged in a proper layout - they're just positioned roughly on a blank canvas. Having quite a lot of trouble really arranging them. I'm thinking that probably the best thing to think about is to get a point on the sprite (eye, for example) and keep that the same distance from the left edge of the canvas each time.

Anchor points are how I've always done it, but you can't use something like an eye, because that moves around. Being an overhead game, I'd use the center point of where you would draw the shadow underneath (I also use that center point as the character's world position). Keep the points relative to each sprite's boundaries. When you draw just subtract the anchor point from the image's anchor point (usually the top left) and every sprite will now be anchored at that point and sprite size won't matter.

[baconman]

Lots of spritesheets/rips are notorious for having this kind of issue.

[Chekr]

On the above notes of re-positioning the sprites into a uniform grid, and defining a "central point for the sprites:

Keep in mind that once you start adding game logic you will probably want to do this anyway. When moving the character, you typically want to reference everything the character does from a fixed position, even if the sprite is technically bobbing up and down slightly with each step. Likewise, you will likely want a uniform collision box on all the sprites (at least if you plan on keeping things simple. The collision box doesn't necessarily have to like up precisely with the boundaries of the pixel positions, but consider the following scenario:

If you bounding box walking forward is a different width between sprites in the animation and some come to a wall. You collide with the wall, but then the sprite changes to the next frame, which can either be larger or smaller. A smaller frame means you can now move even closer to the wall, a larger frame pushed you back. This gets worse is, say, you're "walking north" collision box is wider than your "walking right" box. You come to a wall, collide, and stop. Then you walk up, which now has a wider collision box that does collide with the wall, and now you must handle that scenario (stay stuck in the wall, slide away from the wall, etc).

Sprite-based game tend to use uniform grid sizes not simply because of the art tilesets, but also because it make the game logic vastly more simple.

Likewise, this may not be a concern to you, but animated sprites are usually taken from one file not only because of simplicity, but for speed reasons. Loading a texture then shifting and clipping its position tends to be much faster than loading individual images, and the same applies to resizing the clipping size between frames.

There's a lot of really good reasons to having a uniform grid-size, even if you have to play with your sprite-spacing a bit. Not just for art assets, but for your core-gameplay.