Optimising my (simple) graphics assets pipeline

I recently optimised my games graphics asset pipeline as it's in-efficiency had been bugging me for ages.

The original process for updating/adding graphics to my games was:

1. Open the graphic .psd file in Photoshop and do required edits
2. Run a Photoshop action that exports the graphic into a retina and a normal sized .png
3. Open up my retina Zwoptex file and export a new retina sized spritesheet
4. Open up my regular Zwoptex file and export a regular sized spritesheet
5. Build the game in Xcode.

This was pretty crappy and full of repetitive manual steps. Everytime I went through this process, I would think "this should really be scripted"... Finally I've gotten around to it!

Basically, the desired outcome would be to take a retina sized .png file, drop it (or export to) my assets directory and then that's it, everything else would be automated during the build.

The first step was to write a simple script to do all the spritesheet stuff, which would be called by Xcode when doing a build. Unfortunately, Zwoptex didn't have command line support so I went searching for an alternative. I eventually settled on TexturePacker which looking from the documentary, was very programmer friendly and had full command line support. After using it for a while, I'm very happy with it, it offers a few helpful features missing from Zwoptex such as dithering.

So I whipped up a Perl script which would call TexturePacker with the required arguments to suck in all the .pngs from a specified directory and spit out spritesheets. Also keeping in mind I would be calling this from an Xcode build target, so included handling of the appropriate parameters.

Here is the script if you are interested in taking a look.

The script usage is as follows:

buildspritesheet.pl <clean> <inputdir> <outputdir> <sd_out> <hd_out>

With <clean> being either set or not set (Xcode either passes in "clean" or nothing). The script when run, will spit out a normal sized sprite sheet <sd_out>, and a retina sized sprite sheet <hd_out>. Or, if "clean" has been passed in will delete the current sprite sheets.

Okay, so now that the script was done, I simply needed to get Xcode to call it when doing a build. This was done by creating a new "External Build System" target in Xcode:

If the game uses more than 1 spritesheet, I simply create multiple "External Build System" targets.

Once the target was created, I set "Build Tool" to "/usr/bin/perl", to be able to run my script, and then in "Arguments" passed in the script and appropriate arguments:

I then did a test of running and cleaning the target in Xcode to make sure everthing was cool, and then set this new target to be a dependancy of the game target:

And then I was done!

My new, more efficient process to update/add graphics is:

1. Open the graphic .psd file in Photoshop and do required edits
2. Export to .png
3. Build the game in Xcode

With this new process, I can simply just drop or export new .pngs into my game's asset folder and be done. Converting to spritesheets is now a fully automated process that is part of building the game.

Tools Tools Tools

One of the objectives of Shuriken Chicken, was to use its development to nut out my tools and workflow. You need tools to create software, especially games when there are so many different types of assets coming together. Some are essential, and some save you a lot of time. These were the tools used in the development of Shuriken Chicken, and most, if not all will be used in future projects. 

Xcode

https://developer.apple.com/xcode/

There are very few choices when it comes to developing for iOS, Xcode is pretty much *the* IDE you have to use, and what I am using. There are a few other alternatives, but you will still need to fire up Xcode at one stage or another.

Having used Microsoft Visual Studio my whole career, I initially toyed with the idea of just developing in Windows and switching over to Mac whenever I need to do on device testing and deployment. This was very tempting but I talked myself out of it as I would have needed to buy myself a Windows machine, as well as a copy of Visual Studio. I decided the money would have been better spent elsewhere, and since I am now developing primarily for iOS, it was worth taking the time to get familiar with XCode. I still changed as many of the XCode hotkeys as I could to match those of Visual Studio, typing some code, then hitting F5 is so ingrained in my muscle memory that it would have been futile to fight it.

I do find myself missing Visual Studio a lot whenever I jump into the XCode debugger though, it just pales in comparison. Simple things like checking the value of globals is so convoluted, and even having a custom watch list isn’t possible.

Instruments however, is very cool. It has been invaluable to me in finding memory leaks and profiling memory usage.

Perforce

http://www.perforce.com/

Perforce is a great version control system. I chose to use it out of familiarity, it was what was used at my previous job and is one of the industry standards in the games industry.

Version control is very important, even if you are a solo programmer. It gives you a history of every single change you’ve made before (provided you commit regularly) and can be invaluable for backtracking to see where you may have introduced bugs.

I also find it an advantage psychologically. Having it as part of my workflow gives a nice feeling when I finish off a task. Finish a task, and you know it’s well and truly done when you check it in.

TestFlight

 

http://www.testflightapp.com/

TestFlight is a system used to distribute your app binaries to testers. It is insanely helpful, and your testers do not need any technical knowledge to use. You basically invite testers to be part of your project, when they accept you are given their device ID. You then build a binary with their device ID in a distribution provisioning profile and upload your build. Then the testers will receive a link to download your app binary, they click on it, your app installs on their phone and that's it. It also includes an SDK which allows you to track how your app is being used by the testers. Best of all, it is free to use!

Todoist

http://todoist.com/

For task management, I use Todoist. It is simple and has a very minimalist design. Being web based I am able to access my task list from my iPhone anywhere, which is good when you need to add a task when you aren’t at your computer.

Zwoptex

 

http://zwopple.com/zwoptex/

Shuriken Chicken was a 2D game, which meant sprite sheets. Zwoptex was awesome, I literally just dropped all my sprites in a few clicks it spat out a sprite sheet as well as a coordinates file. At only $15 it was worth every cent and more. 

Particle Designer 

 

http://particledesigner.71squared.com/

This is a simple tool used to design particles for cocos2d. It basically lets you tweak and preview all the particle system parameters available in cocos2d, and spits out a file which can be loaded and used by cocos2d. This makes designer particle effects a trillion times easier than tweaking the code by hand.

Glyph Designer

http://glyphdesigner.71squared.com/

A simple tool to generate font bitmaps. Made by the same guys as Particle Designer.

Audacity

http://audacity.sourceforge.net/

Audacity is a simple, open source wave editor. All of the audio in Shuriken Chicken was purchased from stock websites, so I didn't really need a hardcore wave editor. Audacity was very useful for trimming silence off the start and end of stock audio files and as well as downmixing certain sound effects and resampling all my audio to appropriate rates.

Adobe Photoshop

http://www.adobe.com/products/photoshop.html

The graphics for Shuriken Chicken were photographs, so I used Photoshop to edit and prepare them for use in game. I also used Photoshop to create icons and other graphics.

Adobe Lightroom

http://www.adobe.com/products/photoshop-lightroom.html

I used Lightroom for asset management, which I guess might be a little controversial. The main reason I used Lightroom was because the graphics for Shuriken Chicken were photographs, and Lightroom was part of my photography workflow so it made sense for it to be incorporated into my game dev workflow as well.

For future projects where graphics don’t come from photos I see myself using something much lighter weight like Adobe Bridge for asset management.

--

So that about covers the tools that that I am currently using, I’m sure there are a lot of alternatives to the above tools I’ve mentioned, and they are probably all very good as well.