So I am working on some of the art for my game and in particular I am working on the terrain tiles. My workflow is a bit screwy and was wondering if anyone had ideas on what I can do to stay better organized and not lose my mind.
Here is my current workflow
- Aseprite file 32x32 and all permutations of that terrain in a multiple frames.
- Export that into files
wall-0001.png, wall-0002.png, etc…
- Open texture packer and import these files and output the atlas with all my UI components and what not packed in.
The biggest issue I am going to run in to soon is animated tiles. My current workflow will not work well with that.
I author my tiles in a single non-animated file containing a grid of tiles, i.e. an already-packed texture that can be packed into a larger texture atlas without messing up the arrangement of tiles. This makes the tileset easier to use in Tiled Editor (and probably other tile-based level editors as well), and I can arrange the tiles in a way that’s convenient for me.
Animation is just a sequence of tiles, they can be saved as any other tile (in my case, just another slot in the tileset image). The animation data can be defined in accompanying data (e.g. Tiled includes animation info in the tileset *.tsx file) or in your engine via the tile’s name (if importing as a bunch of images) or position in the tileset (if using a tileset image instead).
Is your asset pipeline set up so that you have to generate all these files at the time you author them?
Sorry, I’m not sure I understand your question, or perhaps you didn’t understand my post. There’s only one file, the tile sheet.
Here’s an example of a tile sheet (scaled to 50%, and with the transparency grid visible behind the tiles, this one is for a side-scrolling game so there are a lot of transparent tiles):
Well, technically there are two files: there’s the exported PNG that goes into the game (either directly or as part of a larger atlas), and the layered source file (e.g. *.aseprite or *.psd) that has some additional guide layers such as templates.
Tiles are identified simply by their coordinate in the tile sheet.
As you can see, this particular tile sheet has a big gap in the lower left, this is space for future tiles. If that space isn’t enough, I could expand the image to add more space. If I end up with left-over space, I can stick non-tile stuff in there such as UI elements, and simply not use those “tiles” in the game’s maps. The tile sheet is just a single, simple texture and is used as such.
If your engine and level editor support it, you can have several tile sheets, you don’t have to pack everything into one. If you have some mutually exclusive tiles (e.g. tiles for a snow area, and tiles for a desert area), then you could have them in separate sheets and only have one loaded at a time.
you can have several tile sheets
Yea I think this is more a premature optimization on my part. I just wanted to pack everything into as tight of a file as possible to mitigate texture swapping in the GPU. But for 2d games it’s not a huge deal.
Thanks for talking this through with me. I think I understand your work flow now and may just go that route
If you’re going to texture-pack everything (tiles, UI, sprites, etc) in the end anyway, it doesn’t matter how many tilesheets you use to make your levels, since they’ll all end up on a single texture anyway 
And if you use the space in each tilesheet well, you shouldn’t end up with any significant gaps. I think a few potential gaps (=some wasted memory) are a cheap price to pay for avoiding additional metadata like filename references and for being able to view and work on your tiles together easily.