search

bitDecayGames / haxeflixel-template

Basic game template with FMOD and Bitlytics tie-ins ready to build from
3 stars 1 forks source link

Figure out the best workflow for sprite packing #64

Open MondayHopscotch opened 11 months ago

MondayHopscotch commented 11 months ago

The current iteration packs all the sprite when changes to any Aseprite files are committed. This works fine as long as the artist is the only one changing the files (and isn't expected to run the game).

But if any devs have to make edits, or the artist wants to try their changes in the game, they will have to manually run the bin/export_ase.sh script.

Ideally, this would auto-detect when it needs to run and repack the sprite files automatically. This could be done a couple of ways (off the top of my head):

  1. commit a hidden file into either the assets/aseprite/ directory called .lastBuilt (or something), that contains information on what files were last generated from. If it detects a mismatch, it regenerates the images and updates the file with a receipt of having done so.
  2. Always regen the art when running the game. This may become cumbersome for larger projects that have many art files
  3. Always regen the art, but only for files that have changed (could consult git to figure out which ones have changed, same as how export_ase.sh currently runs

Notes: How did the libgdx texture packer detect when there were changes to the underling art files?

MondayHopscotch commented 10 months ago

The project now has launch task that runs the generation. The newly added run_debug.sh script also now runs export prior to running the game. So anyone editing the art has a mostly-automatic workflow to make sure the atlases are regenerated.

The potential next step for this is to no longer commit the atlases, and have the build generate them. The only problem here is that aseprite CLI is needed to do the export, which may prove problematic with github actions.

MondayHopscotch commented 10 months ago

The script is smart enough now to only regen for aseprite files that have changed. Output files are still committed as doing this at build-time only would require aseprite CLI access in the build action, which sounds potentially complex.