Working on a chingu (github.com/ippa/chingu) trait called automatic_assets:

Thinking something along the lines of:

class Spaceship < GameObject
   has_trait :automatic_assets
end

This would automatically load and display media\spaceship.png if available. Or media\spaceship_animation.png tileset.

I've always used tilebased animations, made in graphicsgale or tilestudio. You usually want to have different animations which you display at different times, for example:

spaceship_default_animation.png        # flying tileset
spaceship_exploding_animation.png   # dying/exploding tileset

automatic_assets would detect those and then in the code you could do something like switch_animation(:exploding) or simular.

Anyhuuu... how do you ppl do your animations? what programs .. and how do you save them? is it all tilebased or maybe one image per frame?

I'm working with single-frame PNGs for animations, naming them in a batchy way (character_attack_01.png, character_attack_02.png, ...) and calling them by a script that basically looks like this (obviously heavily shortened, as I have to write it from my mind and don't feel like create a whole character class just to show animating XD ):

class Character

  attr_accessor :state

  def initialize(name)
    @name, @state, @frame, @delay = name, 'idle', 1, 0
  end

  def draw
    # these lines check for the filename, and if there's a file with @frame+1 in it - if yes, @frame get's incremeted by 1, if not, set to 1
    Engine.draw_sprite(@name + '_' + @state + '_' + @frame) #my own method, basically just a handler for the default method with advanced call options
  end

end

The stage itself (that checks for key input) handles the state setting, based on the @delay variable. This variable basically gets decreased by 1 each tick, unless it's already at 0. This ensures that no action is executed while another is (just included as it might be interesting... doesn't really have to do anything with animation ^^" ).

The reason why I'm doing single frames is that I like to work resource-efficient and like to cut off boarder pixels with no color. The base pixel to draw sprites from is the solid foot (manually set coordinates, unfortunately), making for a believeable, non-skipping animation for cartooney sprites. I think this method of drawing sprites is easier, as you can, for example, include large effects directly into the frame without worrying of bloating a whole file up because you have to adjust the raster. It's also easier to adjust if you realize your spriting needs some final improvement and you avoid having to edit the whole set because you need to fit a single additional pixel in.

As a side note, for fixed-size objects like cursors and the like, I use tiled images as well ^^

Thanks for your detailed answer! Indeed there's some upsides to single-frame animations. I've just grown custom to working with tile-sets in graphics gale which is very quick 'n easy.
I'll add support for single-frame-support to Chingu if someone requests it :).

Another downside to tile-animations is that you have to provide the frame-size somehow, I'm thinking including it directly into the filename for autodetection like this:

  spaceship-10x10.png

That could be automatically picked up and used by a Spaceship-class. If a state is required it could be baked into the filename as well: spaceship-10x10-flying.png

May I ask what program you use to draw animations?

As for autodetection of frame size, there's a couple of ways I can think of without actually messing with the filename at all (which you want to avoid as well, admit it ;) )... let's see:

- autodetection by taking the smaller side as seperator, assuming square frames only (as in having a 50x10 image would result in five seperate images, as the "longer side will be devided by the shorter side")
- autodetection using certain folders for certain purposes, RPG Maker style... if something is in folder "graphics/animations" you know it's frame size is 128x128px
- autodetection using some kind of alpha checking to actually determine how many seperated images there are (checking in a first step which side's the longer one, and then checking line-wise in the opposite direction how many completely blank line blocks there are (for an image with 4 frames, this should return 5 - 3 inbetween the frames, two at the sides), so simply do blank_line_amount-1 and you have your frame number)

None of these methods is perfect, as you can tell... #1's assuming square frames is not problematic when working with PNGs, as completely transparent pixels don't take up any filesize... however, forcing that upon users of a meant-to-be-variable engine like Chingu is would be substandart. #2 even forces you to use certain folders, however, you can define your folders yourself. It gets problematic when you want to work efficient and yet use different sizes. #3 is basically good, however you restrict the designer heavily in how he can layout sprites, as a single completely transparent line within two objects of the same sprite will break it (being a spriter as well occasionally, I know that doesn't happen too often... but it's those few times that make the difference ^^ )

I think to solve this completely automatic, you'd have to use an algorythm that doesn't only check if there are break blocks, but if they're having roughly the same distance, and simply ignore everything not fitting the checkup. The problem is that you'll never get it 100% secure, so even if you make it, it probably won't make people happy...
I think I'd personally recommend #1 from all of these... you're variable in spriteset size, get automatic clipping and all of that for the price of not having multi-line spritesets... (which noone wants anyway?)

--

As for the animation drawing, what I have up there is basically all I have... I'm not using any additional modules or anything to draw them, just Gosu. Here's the complete method for you though, if you'Re interested:

  def draw(screen_x)
    if @current_graphic == @state
      frame_count <= @frame ? @frame = 1 : @frame += 1
    else
      @current_graphic = @state
      #@frame = 1 unless @state.inherit # take over frame number from one animation to another for smooth transitions
      @frame = 1 if frame_count <= @frame ? @frame = 1 : @frame += 1
    end
    filename = 'graphics/' + @referer + '/' + @state + '_' + @frame.to_s + '.png'
    @direction == 0 ? fx = -1 : fx = 1
    Engine.draw_sprite(@x - screen_x, @y, filename, 1, 2, @z, fx)
  end

The escaped line is what I still have to work on, however, I'm fiddling with my interface at the moment and put this game on halt ^^

damn, BlueScope, you could write a book on the subject ;-D

You have some good ideas:

#1 - easy and robust, though I've often found myself doing odd sizes like 11 x 16 that fits the sprite "perfectly" and then using the very same size for rectangle collision detection. doing 16 x 16 there would fuck up the collision detection. Though it shouldn't be so hard "trimming" off the transparent extra space with TexPlay. Trimming could also be cool for sprites which vary a lot in size between frames.. the collision rectangle could adapt to each frame.

#2 - as #1 but with special directories.

#3 Now this is interesting.. I've thought about simular things. A "blank transparent line" is probably the best separator there is.

Hm.. I think I'll look into trimming, could be usefull in a lot of conditions.

Oh I was wondering what program you used to paint sprites with, not rubycode to animate.

As far as the book part goes, I don't really think I could... I just have some interest in interface design in general, and this topic is very loosely related, so yeah... I like to come up with solutions to problems, and I guess working with RPG MAker makes you come up with solutions for problems, so... XD

And well, same sizes for #1 would only occur for a) multiple lines, or b) single frame. As I excluded multiple lines in the definition (as you'd need a way to autodetect these as well, which isn't possible by just deciding on dimensions), it'd mean it's a single frame ^^

For drawing sprites, I actually use Photoshop... which for some reason is totally hated upon the spriters in general. I like how a few people told me it didn't have swatches XD As a I-guess-professional graphic artist, I'm very familiar with the program, and I really like to work with it, so yeah... it may be overloaded, it may not be the perfect program for spriting, but I still like it XD
I think a save plugin I use is worth mentioning, being PNGOUT. It's the best PNG save algorythm I know, and as it's based on a quality-first idea, it really manages to output awesomely small files with completely lossless rewriting. I've managed to get down to 10% of filesize compared to a Photoshop-default saved image. It's really worth taking a look at!

BlueScope:

> I think a save plugin I use is worth mentioning,
> being PNGOUT. It's the best PNG save algorythm I
> know, and as it's based on a quality-first idea, it
> really manages to output awesomely small files with
> completely lossless rewriting. I've managed to get
> down to 10% of filesize compared to a
> Photoshop-default saved image. It's really worth
> taking a look at!

My favorite graphics viewer/converter, IrfanView, also has the PNGOUT plugin, though I rarely use it. The standard PNG export in either IrfanView or my favorite editor (Jasc Paint Shop Pro 8.1) is usually sufficient.

Also, about method #1 not working for multiple lines: one way would be to set maximum dimensions for a single frame. If the result of the division is greater than this, increase the number of rows and try again. Just an idea, though; I've never actually implemented such a thing...

I use IrfanView myself; the problem with that is transparency color conversion, as it's got it's problems detecting alpha transparency (which is a huge strong point of PNGs really). As for regular images without transparency, IrfanView's plugin will be exactly as sufficient as the PNGOUT program.
Personally, I run every image through PNGOUT that I process for a game. Having a 5000b file lossless compressed into 500b is great and I don't see a reason why you wouldn't want to do that if it takes not too long while getting you a huge saving in filesize (even in whatever-speed internet ages, I don't think that I as a game designer should slack... o something like that ^^ ).

As for the vertical splitting: The problem is variable frame sizes: Let's say your maximum height is 64 pixels, then it'd work on an image that's 1024x128 perfectly, however, a 1024x32 image would be processed as a single line. If you set 32 as your limit, assuming noone uses smaller-in-height images, you'll have problems using your 64-high images. ^^

BlueScope wrote:

> I use IrfanView myself; the problem with that is
> transparency color conversion, as it's got it's
> problems detecting alpha transparency (which is a
> huge strong point of PNGs really).

That's true, I forgot about IV not handling alpha very well... The batch converter preserves alpha (except in obvious circumstances) but when you open a transparent image in the viewer, alpha is lost.

> Personally, I run every image through PNGOUT that I
> process for a game. Having a 5000b file lossless
> compressed into 500b is great and I don't see a
> reason why you wouldn't want to do that if it takes
> not too long while getting you a huge saving in
> filesize (even in whatever-speed internet ages, I
> don't think that I as a game designer should
> slack... o something like that ^^ ).

I totally agree. I also do Flash games and I always try to keep the assets as small as possible. Of course, the largest part of the majority of Flash games is the MP3 music most developers and sponsors insist on :P

On the same subject, it would be nice if Gosu supported JNG (PNGs with JPEG compressed image chunks) for when a little lossiness is acceptable to get /really/ small images, but an alpha channel is still needed. Maybe DevIL has support?

> As for the vertical splitting: The problem is
> variable frame sizes: Let's say your maximum height
> is 64 pixels, then it'd work on an image that's
> 1024x128 perfectly, however, a 1024x32 image would
> be processed as a single line. If you set 32 as
> your limit, assuming noone uses smaller-in-height
> images, you'll have problems using your 64-high
> images. ^^

Well, I meant that the maximum height would be chosen for each given project, not as something hard-coded into a library or toolkit...

I never noticed PNGOUT doesn't do alpha transparency... to be honest, I apparently never tried it XD
I'll definately have a look into that in the future.

As for accepting lossy picture compression, that's something about NO game out there does really... regardless of it's for small sprites or large pictures, going for anything but perfect quality in your graphics will immediately be noticed. Too bad the opposite isn'T gonna happen and people be like "Dude, I totally love your lossless image compression! :D" (except for Odin Sphere maybe... at least I said that)

And I think it'd also be problematic project-wide. It'd even be problematic spritesheet-wide, as for me personnally, cutting frames larger so that they all fit into a tileable sheet isn't too appealing. Therefore, my sprites are all kinds of sizes and shapes, so defining a global value for the sheet height.

BlueScope:

> As for accepting lossy picture compression, that's
> something about NO game out there does really...

Maybe not in mainstream PC games, but I've seen plenty of PS3 and NDS games (and maybe other systems... PS2?) containing images that exhibit the tell-tale "fuzzy squares" of JPEG. Not for sprites, necessarily, but things like title screens, "loading" screens, etc.

Of course, it may just be sloppy asset handling that allowed an image to be JPEG'ed somewhere in the work-flow, but not in the actual game medium (which would make the file harder to losslessly compress).

Also, I've used JPEGs in Flash games for large background images and the like. As long as it's not being scaled up, rotated, etc., it works fine and really saves a lot of space for images with lots of fine details, anti-aliasing, gradients, etc. (i.e. no large blocks of solid color).

(BTW, apologies to the O.P. for this slightly O.T. discussion...)

By "fuzzy squares", I assume you're talking about artifacts (compression-originated). If so, I've never seen them in a game ever, may it be because of I own neither of the mentioned consoles or just my lack of ability to spot stuf like that... it's interesting though, as I figure especially on the DS, you'd have to have your own display module for that filetype, as I don't really see a reason why it'd be included from the begin with... As for PS2, I've played it a long time and own quite a bunch of games, however never noticed any... (not meaning they're not there, of course, just saying).
With that in the way, I have to redo my statement earlier made: No gam out there should accept lossy image compression. ;)

And well, the problem with JPG files in non-professional use aren't that they're bad in general, but that 95% of all people use them wrong: Some low-class programs on't even support quality adjustments, so if someone only works with Paint because they prioritize programming or something, they probably never heard of a quality option. IrfanView uses weird steps (1 to 12), which, while thoughtful as you rarely need 100 seperate steps, is confusing and not directly translateable well. Photoshop's JPG output module isn't any bad (compared to the PNG module, it lights your room), however that is a professional program and unless people are shamelessly stealing it, amateurs would less likely have access to it.
The quality itself, if adjustable, is the next trap: Setting the slider to 95% can cut the filesize in half, while looking perfectly fine even on closer looks. However, it might still change colors of some pixels here and there, up to bigger areas that just become brighter or darker.
Las but not least, there is to know that JPG is meant for photos. I've seen it being used for sprites, tilesets, pixelled avatars, the like... people just go "JPG is cool, so just use it", and at least judging from the RPG Maker communities I've been in over the last couple of years, I've seen a never-fading group of people totally resistent to help on the topic.
On the other hand, using them as backgrounds can be alright, as depending on the picture, as you said, it'll sometimes be radically smaller in filesize. However, you will always have that small imperfectism in your images that who-knows-who might be able to spot on their screens (like you did for the PS3/DS games).