Spending Time to Save Time: Automating My Builds

As a one man developer it’s very easy to fall into patterns of bad habits with the development process.  I don’t have a team to worry about, I’m not beholden to any code reviews or quality metrics and it’s just me and my PC, so why go the extra mile to do things right?  Some things have clear benefits and such a small up-front effort requirement that they’re a no brainer.  I have a svn repo running on my NAS and this has saved me many a time – do not underestimate the sinking feeling you will get when you realise the drive that just failed in your PC was the one with your dev environment on it.  Even if you don’t have a seperate server for source control, it may be worth considering a local install and then regular dumps of your repository to external storage.

OK, so that was quite an easy example.  Job done, point justified right?  Well, not quite.  I’d like to share an example of another area where a little bit of upfront effort has made my life easier: automation in the build process.  Now, to be clear, I’m not talking about a full end to end build process / CI here.  At the moment I don’t see the value in that beyond providing me with an excuse to spend money on a server.  Any changes I’m making in code I’ll be immediately deploying to either a simulator or device depending on my current requirement.  There is, however, one key part of my build process that needed some automation and that’s creating art resources.

I’ve written before about the tools I use to create sprites: Inkscape, Blender and TexturePacker Pro (with a splash of Paint.NET) all come together nicely as a toolbox for those who aren’t up to creating graphics by hand.  The thing is, when I want to tweak a sprite, change something completely, add something new or provide assets for multiple resolutions I have to go through a hell of a process to manually deploy this to a build.  Let’s take creating a new menu button as an example:

  1. Create the menu button in Inkscape
  2. Save this somewhere sensible that I’ll find again later
  3. Export the region I want at a scale for the app sizes I want (1080p, 720p, SD, etc.)
  4. Store these exported files somewhere
  5. Open up the texture atlas definitions for each app size and add the new assets
  6. Export the new texture atlases and their indexes and save these somewhere
  7. Copy the new atlases into each project that uses them and rebuild

The process doesn’t differ much for making small changes to existing sprites.  As you can imagine, this results in me looking at to-do items demanding I perform a bit of an art clean-up, sighing and then ignoring them in favour of playing with some new code.  Not a great position to be in. Looking at the above process, there’s clearly a lot of scope for automation and process improvement.  I’ve probably made a lot of things more difficult than they need to be as this was my first project.  Luckily, all of the apps I use come with command line functionality that provides what I need to make my life easier.  By making a few design decisions I now have a three step process:

  1. Create / edit Inkscape / Blender files
  2. Run batch script
  3. Rebuild apps

Nice eh?  To do this I’ve set up my environment in the following way:

  • All projects now look for texture atlases in a root project folder called Resource[X]\textures where the [X] is a number indicating whether the resources are HD or not
  • All Inkscape / Blender files are designed with the assumption of a HD screen to display on and placed in a Textures path within the project directory
  • Sub directories within the Textures path group the texture source files together by theme (uicontrols, menus, decorations)

The batch script (Windows version attached) iterates over each sub-directory and uses Inkscape and Blender to output full resolution PNG exports of each file to a temporary directory, divided up with the same sub-folder structure.  TexturePacker Pro is then used to create an atlas from each of these sub-directories.  This is run three times as TexturePacker Pro will handle reducing the size of the atlases for the different resource sets (I use three multipliers – 1, 0.7 and 0.5).  All that is then left in code is to import the atlases and refer to the textures within by name.  While the process could certainly be made more efficient (by not re-working items with no changes), this isn’t necessary for my personal needs.

If you want to look at the details of the arguments I use on the command line, grab the batch script and take a read.  It’s not amazingly complicated but the effort required to create it more than pays for itself.

The script: generate_svg_to_png

Leave a Reply

Your email address will not be published. Required fields are marked *