The Spritesheet Process Bible

[ToonTrout]

Okay so I'm posting to hopefully for myself and new people registered around here get some clarity on how to edit and deal with spritesheets in an efficient manner.

Working and playing around with making games, art and sprites it's beneficial to streamline the process imo for effective work.


Firstly it's just kind of beyond me as to why theres not a system in place that lets you upload ripped sprites on-to this site and input the pixel size of tiles, spacing between sprites and rows etc. As far as I've seen people are just supposed to guess their way through finding this information which does take way too much time. Maybe there's a software that analyzes sprite and tile-sheets(the solution to this somewhat is to open ShoeBox and extract sprites and then check the size in the property of each individual tile) but I havent found that stickied here. And it works way better than spriteSheeter.


That said let's take a look at common processes game makers and game-dev students could use. There's probably many more but I'm not so knowledgable within this field so I do hope you can bear with me.

Levels

• Now I belive a lot of people will want to use a level creation software with tiles that they can export to the game engines (game maker, construct 2, clickteam fusion or you name it). I personally am using a super cool software called Tiled.
  
• 
  
• Look at how beautiful it is when it is actually working. It's basically the same as game makers level editor for people who use that.
  
• I use ShoeBox to extract a spritesheet into separate images and then re-stitch them but for me it doesnt seem to work with the editors afterward cause of slightly off spacing or margins. And I havent seen ShoeBox showing the user the data either for how many pixels will be spaced in between tiles. Its a headache currently and I hope someone more seasoned have some tips for creating usable tile-sets for use with Level editors.
  

Characters

• So characters is a bit easier to deal with and I will share my process with you guys!
  
  
• 1. Download the spritesheet of your choice.
  
• 2.  Remove backgrounds. (I reccommend asprite for this and click edit replace colour. Or Background remover which you can download from google, its great because you can remove the bg of many images at the same time) Alternatively you will have to do this afterwards in some cases as its more effective to get the right rip-size of the image with ShoeBox.
  
• 3. Boot up that beautiful software of ShoeBox and drag your nice sheet into the extractor, looks somewhat like this. https://youtu.be/GWMwBCLEcoM?t=32 4. Now you can find each separate image used in the sequence you want and put it into a new folder. Ready for import in your game-maker,after effect or other video software of choice voila.
  

So I hope that you have found some of this process information useful and that you can add to it in the comments and state your process regarding spritesheets!

[puggsoy]

Firstly it's just kind of beyond me as to why theres not a system in place that lets you upload ripped sprites on-to this site and input the pixel size of tiles, spacing between sprites and rows etc. As far as I've seen people are just supposed to guess their way through finding this information which does take way too much time. Maybe there's a software that analyzes sprite and tile-sheets(the solution to this somewhat is to open ShoeBox and extract sprites and then check the size in the property of each individual tile) but I havent found that stickied here. And it works way better than spriteSheeter.

The reason there's no standard layout for submitted sprites is, well... there's no standard way of ripping sprites. Many sprites, especially from on games, are hard-ripped and as such there's no proper way to figure out things like bounding boxes and so forth. In any case, a lot of work already goes into ripping sprites. While we do have quality standards, requiring people to have to figure out all of these specifics to make them super-convenient to use is a bit much.

In addition, the main intention of TSR is to act as an archive and gallery. Usage of the sprites in animations and games is a lower priority and a relatively smaller proportion of people use it for that. Not to mention, they're all proprietary sprites anyway; they'll only ever be used for fangames or as placeholders, two uses which again, aren't extremely high priority. Sure, the people using them will have to figure it out themselves, but at least the sprites are already ripped, right?

I agree it'd be great if all sprite sheets on the site were like this, but requiring everything to be so consistent is just not beneficial to the site. We try to encourage it, but forcing it just isn't practical.

All that being said: thanks for this tutorial! It's definitely a good starting point for people wanting to use sprites.

[Firejoker54]

In addition to what puggsoy said, if we had some kind of crazy "quality standard" like you propose, many people would get turned off submitiing for the site. I do try to make my sheets nice to look at and organized(using the same spacing between sprites, etc) but sheeting this way takes a long-ass amount of time, more often than not, even LONGER than ripping the actual sprites.

I do get where you're coming from but ripping takes enough time and effort as is, asking rippers to follow strict rules just isn't viable.

[ToonTrout]

Thanks for the replies guys, I totally know where you're coming from as well. If one where to think out of the box I think the submission form a spritesheet is in, in this case an image is also responsible for the fact the quality is very up and down! I'm at least haappy to provide what I can to make it easier for people! To use the art even if its for fangames. I think a lot of beautiful visions start out as fan stuff!!

Maybe it would be an awesome idea to create and code a spritesheet submission creater software! It's equally time consuming to arrange sprites in a photoshop file as it could be to build a "standardized" format spritesheet. Of course it would vary from game to game but if you'd be able to define size and such it could be a better tool than say ShoeBox currently is! Just hope to see the forum and community grow and level up is all so I hope it will continue to develop! Its easy for me to say thats not that well taught yet to code but I do at least think its good to make our voices heard!

[puggsoy]

Daxar's Sprite Sheeter actually does such a thing (the sheet I linked was made with that). It definitely helps a lot but still, not everybody uses it (for various reasons).

I do have an idea for a very cool file format to accommodate both sheet viewing and use in games/animations/whatever. It's still a long way from anything (I only have ideas and haven't done any solid planning) but I think it's something that could potentially become the preferred format for the site at some point, provided it actually becomes a reliable format and the admins agree.

The idea is essentially that it stores things like animation frames, names, framerates, and so forth. You could have one program that views them in a spritesheet form (where you can choose background colour, spacing, etc), and possibly a script that does the same online. Other things such as game engines could actually read in the file and use the animations in-game. In essence, it's not much different to how a lot of PC games store their sprites. The difference would be that it's standard, and so you could view them on a single program or, indeed, a website.

There would still be the problem of hard-ripping and figuring out bounding boxes (and I doubt all sheets could be converted to it) but for sprites that do have that information (such as Nuclear Throne), it could be very handy. At the very least it's something I want to experiment with.

[ToonTrout]

"Daxar's Sprite Sheeter actually does such a thing (the sheet I linked was made with that). It definitely helps a lot but still, not everybody uses it (for various reasons).

I do have an idea for a very cool file format to accommodate both sheet viewing and use in games/animations/whatever. It's still a long way from anything (I only have ideas and haven't done any solid planning) but I think it's something that could potentially become the preferred format for the site at some point, provided it actually becomes a reliable format and the admins agree.

The idea is essentially that it stores things like animation frames, names, framerates, and so forth. You could have one program that views them in a spritesheet form (where you can choose background colour, spacing, etc), and possibly a script that does the same online. Other things such as game engines could actually read in the file and use the animations in-game. In essence, it's not much different to how a lot of PC games store their sprites. The difference would be that it's standard, and so you could view them on a single program or, indeed, a website.

There would still be the problem of hard-ripping and figuring out bounding boxes (and I doubt all sheets could be converted to it) but for sprites that do have that information (such as Nuclear Throne), it could be very handy. At the very least it's something I want to experiment with."



I think you're definitaly on the right track, I fully support your idea! Make the dream come to life!! 

[Davy Jones]

Here is also a tool called Sheet Maker:
https://mega.nz/#!QYBy3aiJ!4U0KF7NDIFv7G...C5xe5Ob4KM

SheetMaker needs Java to work, click on the .jar file to start the tool.

What to do with it:
- If you have single pictures with transparency and want to make a sprite sheet with them, this is your tool.
- Sort your pictures and put them in different folders, like Folder 1, Folder 2, Folder 3.
- Put these folders in a root folder.
- Drag the root folder into the SheetMaker window.
- Click on the "Make Sheet" button.
- The pictures in Folder 1 are in the first row, the pictures of Folder 2 in the second row, etc.
- Order of pictures and folder is determined by their names.

Also works with every other pictures, they don't neccessarily need transparency.

Interface meanings:
- Name Tags:        Never used it, so I don't know.
- Max Width:        Determines the maximum width. Example: If you put 10 in it, your resulting sheet will always have a width of 10 pixels.
                    The contents get squished to match this width, so it's pretty much useless. Leave it at 0 and you're fine.
- X Pad:            Very useful, it determines the space in pixels between each frame on the x axis. Use the value 2 and you're fine.
- Y Pad:            Same as X Pad, just for the y axis. The value 2 should deliver enough space between the frames.
- Fill Background:  Very useful, fills the background outside the frames with a certain colour.
- Fill Frames:      Fills the frames with a certain colour, but I don't know if it swallows transparent pixels. I wouldn't check it.
- Alignment:        Had no effect, at least not on my sheets.
- Even Spacing:     Same as Alignment.
- Make Sheet:       Creates a sprite sheet of the content of your folders, it shows up in the same directory as the .jar file.

I got it from Ploaj, who also made the Pocket Mortys sheets with it:
https://www.spriters-resource.com/mobile/pocketmortys/