$12256 / $11500
I would like to incorporate some of the animated sprites that I've found on this site into a game that I'm building. In the past, I've used animated sprites built either from multiple frames stored as single images, or from sprite sheets in which the frames are regularly spaced across the sheet (e.g. each frame is a 32x32-pixel square). Many of the sprite sheets here, however, have their frames spaced irregularly on the sheet: the frames seem to have been squashed together as closely as possible in order to produce the smallest possible sprite sheet. E.g.:
http://opengameart.org/content/the-blob-ultimate-smash-friends
In order to chop that sprite sheet up into a number of animations, I need to know the dimensions of each frame. Presumably the artist had specific dimensions in mind for each frame when creating the animations -- so has that information just been lost? I would have expected either the dimensions of each frame to be marked in a different colour (with the borders being discarded after splicing), or for some frame information to be provided along with the sprite sheet, e.g. a text file saying that for animation 1, frame 1 begins at position x,y and has a width of w pixels and a height of h pixels, and so on.
Of course, I could open up the sprite sheet in a bitmap editor, then splice it manually by guesswork, using a fixed point of reference (such as the eye in the above example), but, especially when the animation is associated with locomotion through a scene, that point of reference might be intended to move within the frame during the animation (i.e. the blob's eye moving up and down, and side to side, as the blob squishes itself about to propel itself forward).
Am I missing some hidden information contained in the sprite sheet, or are we expected to work out the splicing points manually in order to make use of sprite sheets like this?
I'm sorry if this has been asked before elsewhere (I couldn't find anything in the FAQ or through searches), or if I've asked the question in the wrong forum (it's kind of on the boundary between art and programming).
This website's content is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Good question. Your understanding of the problem is correct. Unfortunately I can't think of an elegant solution. It usually boils down to an oversight by the artist, not understanding the process that programmers use to make assets "do stuff".
Ideally, artists making these kind of assets with variable dimensions should pack all of the individual parts using a texture packer, which can store the dimensions and positions of each frame.
Stay a while and listen.
I'd like to hear the answer to this one as well -- in the past, I've just taken what I could from .gif previews and manually extracted the rest.
It's a real pain in the you-know-what, but I hate to complain about free resources.
Thank you both for your replies. I really thought that I was missing something, and that the frame information was hidden somewhere! I'm not really into game art culture, but I get the sense that lots of artists who make animations that are uploaded to this site do so just for the fun of making something that looks good -- but surely the chance of their work being used in a game is always on the cards (the site is called openGAMEart.org, after all).
In the Blob example that I used, the frames seem to be arranged in a way similar to the output from a sprite/texture packer that I used briefly a few years ago... and I'm pretty sure that that program output a sprite sheet as well as a text file with frame information. Maybe the artists are using programs that generate this frame information, but they're just not bothering to upload it, because they don't realise how useful it would be to game developers. If there's an FAQ here for uploading guidelines, maybe it would be good to add a note on this.
At the risk of being flamed for cross-posting, I might post a similar question in one of the forums frequented by wielders of the paint brush, to see if they're aware of the pain that we have reverse-engineering their animations.
Interesting post, could I ask, would you say there would need to be different set ups of Sprite sheets dependant on different softwares being used by the developer? Example I suppose would be to have a character that ran/walk as drawn by the artist, or have the same character but parts dissected, like the arms and legs so the developer can arrange them him/herself?
Chasersgaming | Support | Monstropolis |
Many engines/frameworks do have rules about how they turn a spritesheet into animation frames. Often they require the frames to be in sequence horizontally and with a fixed dimension for all frames. Each different action that a character can do would need its own strip of frames. Then the list of frames being used just changes depending on what the character is doing.
I think that good tools should allow developers the added functionality of being able to define what areas of an image they want to use explicitly, useful in your case of creating a character using different parts.
Stay a while and listen.
No. As long as spacing is consistent it will work with pretty much any software or scripting language
Parts are helpful at times (particularly for "death" actions/states), but I don't have the patience for animation -- I'd rather focus on level design and game balancing.
Somehow I guessed it would be about one of my sheets.
No, there is definitely no hidden order to how they're arranged on the sheet. The long and short of it is, it is very time-consuming to sheet a character out in a rigorous and orderly way (and that was doubly the case with my workflow five years ago). The gifs are provided in part as a guide on how the animations should look, and my reasoning at the time was that there should be enough information for the sheets to be implemented by the dev in whatever way is easiest for them--essentially, shoving that bit of work off onto the devs since I didn't particularly want to do it. That's not necessarily the best approach I will admit, but these sheets in particular have been used a number of times so I assume at least some people have worked through it.
Someday I want to go back and revamp all of these, and at that point I'll definitely have to reformat them as well. But I'm in grad school at the moment so it won't be any time soon I'm afraid.
When you have time to revamp, adding some form of markers for each frame should do the trick, e.g. like the red frames here:
https://frogatto.com/2015/11/18/progress-report/
http://opengameart.org/content/cute-platformer-sisters
Just remembered seeing this comment a while back....I always assumed graphics editors would generate the sheets/frames for you. Didn't know artists had to do it themselves.
If these were commercial assets, it would be different, but you guys are providing this all free of charge. As a hobbyist who doesn't have a lot to spend on quality assets, I'm willing to do the extra work....you guys just focus on creating.
Looking at the spritesheet, the sprites themselves are all contiguous (no gaps within a single sprite).
Given this, it shouldn't be too hard to write a little code to find the sprites on the page and either re-space them on a single sheet, or save them out as individual frames.
General idea would be scan looking for where non-transparent pixels start and stop. The stuff in between is your sprites.
@Boom Shaka: Just wanted to say kudos to you for having such a good attitude about things! :)