We create 3D models in Maya2011 and create PNGs and import the bunch into Adobe Flash CS5 to create a sprite.

I read somewhere that sprite-sheets can save space over making the sprite in Flash. How big of a difference does it make? None of our art team has experience in creating sprite-sheets. Is it worth learning it and adopt that workflow? How difficult is it? How much of a difference in file-size can we achieve?

Keeping size constraints apart, I see a draw back using sprite-sheets: I wont be able to create multiple combinations of loop animations using the same set of images. I can even create multiple sprites within the same SWF with our current workflow.


You can save some memory by using sprite-sheets, because a good packer will ignore transparent pixels around a sprite and place the sprites as close together as possible. The benefit in file size is really marginal though.

The main reason why sprite-sheets are being used is to make the best use of power-of-two textures and to reduce draw-calls. Both things that are relevant if you use a 3D API like OpenGL or the new 3D API for flash. If you're planning to port the game to another platform (eg. iOS, Android or similar), then having sprite-sheets might come in handy, because these systems will benefit from the sprite-sheet approach.

In case of MovieClips, your approach of single images is going to be simpler, because there's no way to directly use sprite-sheets in flash, unless you create your game with an engine like flixel which directly supports sprite-sheets.

So in short: If you're sticking with flash and would like to animate your sprites using the flash timeline, then single images is the way to go. Using sprite-sheets would mean a paradigm change in how you animate things and you would have to write some code to parse the sprite-sheet information and for animation. It's up to you to decide if that's worth it. If it's for the file-size saving alone, I would certainly not do it.


The sprite sheet concept is to have a single image loaded into memory and then blit (copy) smaller portions of the image. Implementation is application dependent, but one would typically load a script file of some sort which lists the tile sprite size and offset for each "frame" of animation, and that list order can be arbitrary. So you don't create loops of animation frames, you create scripts of pixel offsets.

One possible way to do this is: sprite specification is 10px square, you have 100 frames, then you might create a 10 x 1000 px image, and reference the frames by the y-offset.

Frame 0 : x=1, y=(0 * 10) + 1 Frame 1 : x=1, y=(1 * 10) + 1 etc. (if I messed up the math a little, the concept is still sound)

You can reuse the single image to form arbitrary animations by feeding a script to a function which copies the sprites:

animation 1( 1,2,3,4,5,6,7,8) animation 2(2,4,6,8,1,3,5,7)

Is this a WIN over flash sprites? No idea. But you certainly can have multiple sets of animations with a single sprite sheet.

There is a game development stack exchange where you might get a true hacker's opinion.

  • \$\begingroup\$ I know it's not quite the same, but in web design, putting all your icons, say, in a single image, saves http requests, which is the real bottleneck. I assume there would be a similar benefit in memory calls. Game dev or SO could give you the particulars. \$\endgroup\$ – Sam Feb 9 '12 at 15:01
  • \$\begingroup\$ @Sam sprite/movieclip is also a single hit, infact it is possible to pack multiple sprites (like multiple sprite-sheets) within a flash swf file. so I dont see any advantage gain in terms of number of HTTP requests \$\endgroup\$ – Noob Game Developer Feb 11 '12 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.